Codex CLI 安装后 PowerShell 找不到命令？检查 PATH 和旧版本

安装或升级 Codex CLI 后，如果 PowerShell 找不到 codex，或 codex --version 仍是旧版本，先看当前 PowerShell 实际解析到哪个入口。安装命令正常结束，不等于当前窗口已经切到新入口；在确认来源前也不要继续叠加安装。

PATH 是系统查找命令时依次检查的一组目录。这里检查 PATH，是为了确认 PowerShell 会搜索哪些目录、最终选择哪个 codex，以及它是否属于刚安装或刚更新的来源。

这篇只处理 PowerShell 中的命令解析、安装来源和版本。登录、配置或模型请求失败属于后续问题，不要通过反复修改 PATH 解决。

现象 可能卡点 要确认什么 先做什么
新旧 PowerShell 都找不到，预期入口也无法确认 没有留下可用入口 文件不存在，还是 PowerShell 找不到 回到原安装来源确认入口；仍不存在时再恢复安装，暂不查版本
新窗口能找到，旧窗口找不到 旧会话未刷新 PATH 两个窗口的解析结果是否不同 使用新窗口继续，不修改 PATH
入口存在，新窗口仍找不到 入口目录不在当前 Windows PATH PowerShell 是否会搜索该目录 只处理已确认的目录或安装来源
第一项是 Alias 或 Function Shell 定义抢占 codex 被遮住的外部入口在哪里 定位定义来源，不卸载 Codex
能运行但版本旧，或候选跨不同父目录 旧安装优先，或更新了另一来源 实际执行哪份安装、由谁管理 按当前入口来源更新或处理旧来源
PowerShell 与 WSL 结果不同 检查了两个运行环境 两个 Shell 各自选择哪个入口 在准备运行 Codex 的环境中继续

先处理表中最上游的失败；当前层未通过，不要用版本或登录结果替它验收。同一 npm 全局目录中的 .ps1、.cmd 和无扩展入口可能只是一份安装的包装文件，不等于多个版本。

用实际入口判断 PowerShell 卡在哪一层

所有命令都输入在出现问题的 PowerShell 中。

先查当前实际入口：

Get-Command codex

它返回当前 PowerShell 输入 codex 时实际会执行的入口：

  • Application 或 ExternalScript：记下 Source 或 Path，继续核对全部候选。
  • Alias 或 Function：命令名被 Shell 定义抢占；先列出全部候选，再按本节末尾的条件分支处理，暂不运行版本命令。
  • 报找不到命令：打开全新的 PowerShell 再试。新窗口仍找不到时，先确认原安装来源和预期入口；入口存在时只处理它的父目录或原来源，入口也不存在或无法确认时再按原来源恢复安装。

接着列出同名候选：

Get-Command codex -All |
  Select-Object CommandType, Name, Source

第一行应与不带 -All 的实际入口一致。其余行是 PowerShell 能发现的同名候选。候选分布在不同父目录时，才需要重点怀疑多份安装或旧 PATH 项；同一目录里的 .ps1、.cmd 和无扩展文件，可能只是一份 npm 安装生成的不同包装入口。

如果第一项是 Alias 或 Function，先跳到本节末尾处理该条件分支；其他读者继续下面两项检查。

再看 Windows 能从当前目录和 PATH 找到哪些外部文件：

where.exe codex

每一行是一个外部文件候选。没有输出且退出码非 0，表示 where.exe 没在自己的搜索范围中找到匹配项。它不是 PowerShell 的完整解析器，因此判断 PowerShell 实际执行谁，仍以 Get-Command codex 为准。

最后查看实际入口报告的版本：

codex --version

如果路径已经指向旧目录，这条命令只会再次显示旧入口的版本；必须把路径和版本放在一起判断。

仅当第一项是 Alias 或 Function

如果第一项是 Alias 或 Function，继续运行：

Get-Command codex -All |
  Select-Object CommandType, Name, Definition, Options, Source

Get-Command codex -All |
  Where-Object { $_.CommandType -in @('Application', 'ExternalScript') } |
  Select-Object CommandType, Name, Source

Alias 的 Definition 是别名目标，Function 的 Definition 是函数体；二者都不是 Codex 安装文件。第二条查询只保留外部文件候选，后续使用这些候选的 Source 判断安装来源。如果没有外部候选，当前 PATH 中还没有可供 PowerShell 直接启动的 Codex 文件。

如果确认这个 Alias 或 Function 不该继续抢占 codex，可以只在当前 PowerShell 中临时移除第一项并重新查询：

$entry = Get-Command codex

if ($entry.Options -match 'ReadOnly|Constant') {
  $entry | Select-Object CommandType, Name, Definition, Options
  throw '当前 Alias 或 Function 不能直接移除，请先确认它来自哪个 Profile 或模块。'
}

if ($entry.CommandType -eq 'Alias') {
  Remove-Item -LiteralPath 'Alias:codex'
} elseif ($entry.CommandType -eq 'Function') {
  Remove-Item -LiteralPath 'Function:codex'
}

Get-Command codex

这只改变当前 PowerShell 会话，新窗口不会继承这次移除操作。普通定义会继续执行移除；如果 Options 显示 ReadOnly 或 Constant，命令会先停止。不要盲目追加 -Force。

先用 $PROFILE | Select-Object * 列出 Profile 路径，只检查自己维护且实际存在的文件，再根据 Definition 定位并处理那一项。Profile 中没有对应定义时，再检查自己明确加载的模块；全新的 PowerShell 仍出现同一定义时，也按这条持久来源处理。实际入口变成外部文件之前，不要卸载已经找到的 Codex 安装。处理后从 Get-Command codex 重新完成本节四项检查。

用实际案例判断多个入口

下面是 2026-08-08 Windows PowerShell 脱敏整理案例：Get-Command 只保留指定字段并重新对齐；路径没有个人目录；where.exe 保留全部两行；版本命令保留版本行。

CommandType      Name       Source
ExternalScript  codex.ps1  C:\npm-global\codex.ps1
Application     codex.cmd  C:\npm-global\codex.cmd
Application     codex      C:\npm-global\codex

C:\npm-global\codex
C:\npm-global\codex.cmd

codex-cli 0.147.0

Get-Command 的字段可以这样读：

  • CommandType 是 PowerShell 识别到的候选类别。本例把 .ps1 识别为 ExternalScript，把另外两个入口识别为 Application。
  • Name 是候选文件名。文件名不同不等于安装了三个 Codex 版本。
  • Source 是候选入口路径。本例三项都在 C:\npm-global，属于同一个 npm 全局目录。

不带 -All 的 Get-Command codex 在本例中选择第一项 codex.ps1。where.exe 的两行分别表示它找到了无扩展的 codex 和 codex.cmd；它没有列出 .ps1，这正是不能用 where.exe 代替 PowerShell 解析结果的原因。

codex-cli 0.147.0 是当时实际优先入口报告的版本。这一行没有安装来源或其他 PATH 候选的信息，也没有检查登录、配置或请求。0.147.0 只是本文核验日期对应的参考版本，不是“永远最新版”的承诺。

先确认运行环境，再判断安装来源

PowerShell 中的结果只代表 Windows 原生环境。准备在 Windows 原生运行 Codex 时，再判断入口来自 npm 还是官方独立安装器；准备在 WSL 中运行时，要进入 WSL 的 Linux Shell 重新检查。

Windows 原生 PowerShell

npm 全局安装

在当前 PowerShell 中运行：

npm prefix -g
npm root -g

第一条给出 npm 全局前缀，第二条给出全局包目录。实际 codex 路径与 npm prefix -g 一致，并且 npm root -g 下存在 @openai/codex 时，可以确定这份入口由 npm 管理。

本例三个候选同属 C:\npm-global 这个 npm 全局目录，因此同目录包装入口不能直接算成三份安装。当前 npm 找不到，或前缀与 codex 路径完全无关时，先确认安装时是否使用了另一套 Node/npm，不要直接卸载现有 Node.js。

Windows 官方独立安装器

当前官方 Windows 安装器的默认可见入口位于：

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe

%LOCALAPPDATA% 是当前 Windows 用户的本地应用数据目录。安装器允许改变默认位置，因此路径只能作为线索；还要确认当前入口不是 npm 包装入口，且目录由独立安装器管理。

WSL 的 Linux Shell

WSL 是 Windows 提供的 Linux 子系统。PowerShell 找到 C:\... 入口，不代表 WSL 会执行同一个文件；WSL 也可能通过互操作看到 Windows PATH 中的入口。准备在 WSL 中运行 Codex 时，应进入 WSL 的 Bash 或 Zsh，再执行：

command -v codex
type -a codex
codex --version

根据 WSL 中的实际 Linux 路径，再判断入口来自 Linux 独立安装器还是该 WSL 自己的 npm。PowerShell 中的结果不能代替这一步。

按相同来源更新，不要混用安装器

确认来源后再更新。下面是截至 2026-08-08 OpenAI 官方页面提供的 Windows 独立安装器和 npm 命令；请在自己的环境执行，完成后仍要按下一节核对新 PowerShell 中的路径和版本。本文只核对了官方命令并运行 codex update --help，没有实际执行安装、更新、卸载或 PATH 修改。

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

npm 安装与更新使用：

npm install -g @openai/codex

只有 npm 路径要求 Node.js。任何安装或更新命令报错、退出非 0 时都先停止，保留错误信息和原入口，不要临时换一种包管理器叠加第二份安装。

当前 release 支持自更新时，还可以先查看：

codex update --help

Codex CLI 0.147.0 提供这个更新入口，并会根据检测到的 npm 或 Windows 独立安装器来源选择更新动作；无法识别时会要求手动更新。后续版本应以当时的帮助和官方安装页为准。

新 PowerShell 同时核对路径和版本

安装器或包管理器正常结束后，关闭旧 PowerShell，打开新窗口并执行：

Get-Command codex | Select-Object CommandType, Source
codex --version

路径指向预期安装来源，并且版本符合预期，才算当前新终端已经切到正确入口。

如果旧入口仍优先，只处理已经确认来源的对象：Alias 或 Function 按前面的分支处理；外部文件则记录旧路径和管理器，用对应的 npm 或独立安装器流程移除旧安装，或从 PATH 中移除那一个已确认的旧目录，然后再次打开新 PowerShell。不要批量删除 Node.js、配置目录或来源不明文件。

官方资料

参考文档

# 个人开发 # 编辑器
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

当 AI 修图师装上“万能插头“：MCP 如何改变修图工作流

avatar AI编程社区
cover

2026年8月开发者实战指南：ChatGPT Plus / Pro + Codex 如何协同完成需求分析、编码、测试、调试与代码审查

avatar AI编程社区
cover

Claude API + Python实战：结构化输出后，如何拦住“看起来正确”的JSON

avatar AI编程社区