2026年 Codex CLI Windows 安装后命令找不到怎么办？PATH、npm 全局目录和 PowerShell 排查
在 Windows 上安装 Codex CLI 后，终端提示“不是内部或外部命令”、Get-Command 找不到 codex，或者只有某个窗口能运行，通常不是安装包本身坏了，而是命令文件所在目录没有进入当前终端的 PATH。还有一类常见情况是 npm 装在一个 Node 环境里，PowerShell 却读取了另一个环境。把安装位置、PATH 和脚本执行方式分开检查，问题往往很快就能定位。
一、先确认是“没安装”还是“找不到命令”
不要看到报错就反复执行安装命令。先在 PowerShell 中运行 `Get-Command codex -All`。如果能返回 codex.cmd、codex.ps1 或可执行文件路径，说明命令已经存在，问题可能是当前窗口缓存、执行策略或调用顺序。如果完全没有结果，再运行 `npm list -g --depth=0`，确认全局包列表里是否有 Codex CLI。
如果全局列表也没有，才需要重新安装。安装完成后要看命令末尾是否真的显示成功，不要只看下载进度。代理中断、磁盘权限和 npm registry 异常，都可能让安装过程提前结束。此时先处理安装错误，比继续改 PATH 更有效。
二、找到 npm 的全局目录
Windows 上的 npm 全局命令通常会落在 npm 的 prefix 对应目录，但具体位置会受到 Node 安装方式、版本管理工具和用户配置影响。运行 `npm config get prefix`，记下返回路径；再用资源管理器或 `Get-ChildItem` 查看该目录附近是否存在 codex.cmd。不要照搬别人的固定路径，因为同一台电脑上也可能同时存在系统 Node、用户 Node 和版本管理工具维护的 Node。
如果 npm 能列出包，却在 prefix 目录找不到命令文件，可以再执行 `npm root -g` 检查全局模块实际目录。包目录存在而启动脚本不存在，常见于安装未完整结束、文件被安全软件隔离，或者 npm 缓存损坏。先卸载对应包，清理明确相关的缓存后再安装一次，比手工创建假的 codex.cmd 更稳妥。
三、检查当前 PowerShell 看到的 PATH
运行 `$env:Path -split ';'`，逐行查看当前会话的 PATH，确认 npm 全局命令目录是否在里面。系统设置里已经添加路径，并不代表早先打开的 PowerShell 会自动刷新。最简单的验证方式是关闭所有终端窗口，重新打开一个全新的 PowerShell，再执行 `Get-Command codex -All`。
如果新窗口仍看不到，可以在“用户环境变量”里加入 npm 全局命令目录。只添加目录，不要把 codex.cmd 文件名写进 PATH；也不要为了省事把整个磁盘根目录加入。修改后重新打开终端，再用 `$env:Path` 确认真实生效。公司电脑如果由策略统一管理环境变量，还要留意设置是否被登录脚本覆盖。
四、区分命令不存在与脚本被拦截
PowerShell 有时能找到 codex.ps1，却提示无法加载脚本或执行策略限制。这和 PATH 问题不是一回事。先运行 `Get-Command codex -All` 看同目录里是否还有 codex.cmd，然后直接调用该 cmd 文件验证。若 cmd 可以运行，说明 CLI 安装正常，只是 PowerShell 对 ps1 启动脚本的处理受限。
不要为了一个命令直接把整台电脑的执行策略改成最宽松。个人电脑可以按照组织允许的范围调整当前用户策略；企业设备应先遵守管理员规则。更保守的做法是使用可用的 cmd 启动文件，或让管理员确认签名和策略。排查的目标是找到拦截层，而不是永久关闭安全控制。
如果大家想体验一线 AI 编程模型 codex 和 claude，用它们帮助完成代码修改、测试和审查，可以参考以下教程文档进行接入配置，接入配置好后即可使用。文档教程：https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg
五、排查多个 Node 版本互相“串台”
安装过 nvm、Volta、独立 Node 安装包或开发工具自带 Node 的电脑，最容易出现“昨天能用，切换版本后消失”。运行 `where.exe node`、`where.exe npm` 和 `node -v`，确认当前终端实际调用的是哪一套 Node。随后再次查看 npm prefix，确保它与刚才的 node 来源一致。
切换 Node 版本后，全局 npm 包不一定跟着迁移。Codex CLI 可能安装在旧版本的全局目录里，而新版本的全局目录是空的。正确处理方式是在当前要长期使用的 Node 环境中重新安装 CLI，而不是把多个版本的全局目录全部塞进 PATH。后者会造成命令版本混乱，升级时也很难判断改的是哪一份。
六、Windows、WSL 和集成终端是三套环境
在 Windows PowerShell 安装的命令，不会自动出现在 WSL 的 Linux shell；反过来也一样。VS Code 集成终端还可能继承启动编辑器时的旧环境变量。先明确自己在哪个终端运行：PowerShell、cmd、Git Bash 还是 WSL，然后在同一个环境里完成安装和验证。
如果你主要在 WSL 中开发，就在 WSL 内检查 node、npm 和 PATH；如果项目在 Windows 目录并使用 PowerShell，就按 Windows 路径处理。不要把 `C:\...` 路径直接当成 Linux PATH，也不要把 `/usr/local/bin` 加到 Windows 用户变量。环境边界清楚，排查会简单很多。
七、用最小命令完成最终验证
命令恢复后，先运行版本或帮助命令，确认启动程序本身没有问题。接着进入一个临时测试目录，启动一次最小会话，验证认证、网络和文件访问。不要一上来就在重要仓库里执行大范围修改，因为“命令能启动”只证明 PATH 已恢复，不代表后续认证和项目权限都正确。
建议把最终结果记录下来：Node 版本、npm prefix、codex 命令路径、使用的终端类型和验证日期。以后升级 Node 或更换电脑时，对照这几项就能快速恢复。Windows 上 Codex CLI 命令找不到，本质上是安装位置与调用环境没有对齐；按“包是否存在、命令文件在哪、PATH 是否生效、脚本是否被拦、Node 是否切换”的顺序检查，通常不需要重装系统或反复试错。