Codex 更新后版本号没变？先分清安装来源再动手

更新命令显示完成，重新运行 codex --version 却还是旧版本。先查清终端实际启动哪一个 Codex，以及刚才更新的是哪份安装，再决定下一步。反复运行不同安装器，可能只会增加更多入口。

本文解决 codex version not updating、codex update not working 和多版本 PATH 冲突。没有找到命令属于另一条分支；npm 权限错误、下载失败也不能直接归因为版本冲突。

先分清你遇到的现象

现象	先做什么	判断依据
命令能运行，版本仍旧	列出当前入口，分别查版本	是否更新与运行了不同副本
`codex: command not found` 或无法识别命令	查安装是否完成、入口和 PATH	没有入口，还是当前终端未发现它
安装器报告权限、下载或校验错误	保留完整安装错误与退出状态	更新未成功，先修对应阶段
终端版本变了，编辑器或桌面仍旧	区分 CLI、扩展、应用和远程端	它们可能使用各自的执行入口

先记录操作系统、终端类型、运行主机、更新方式、更新日志和更新前版本。如果是 SSH、WSL 或容器，以下检查都在实际运行 Codex 的环境执行；本机升级不会自动升级远程端。

1. 找到当前实际运行的命令

适用情况： 命令存在但版本不符，或不同终端结果不一致。

macOS / Linux 的 Bash、zsh 中运行：

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

command -v 查看当前解析结果，type -a 辅助找同名入口及 alias、function。若第一项是别名或函数，先检查其定义是否固定了旧路径；不要只看一次 which 就认定没有其他入口。

Windows PowerShell 中运行：

Get-Command codex -All |
  Format-Table CommandType, Name, Definition -AutoSize
where.exe codex
codex --version

Get-Command 官方参考说明，-All 可以列出同名命令并按解析优先级呈现。这里显式使用 where.exe，避免 PowerShell 中 where 别名的歧义；它列出匹配文件，不能替代对别名和函数的检查。

预期结果： 得到当前入口、可能的其他入口和当前版本。某些路径是软链接或包管理器 shim，不一定是最终二进制；要沿其目标或包管理器记录继续确定来源。不要因 codex.cmd 和 codex.ps1 同时出现，就断言装了两份不同版本。

对已经确认来源可信的入口，用它的实际绝对路径检查版本。下面路径仅为占位符：

"/实际安装目录/codex" --version

& "C:\实际安装目录\codex.exe" --version

如果新入口显示预期版本，裸命令仍显示旧版，就已找到命令解析差异，进入第 3 步。如果所有已确认入口都旧，进入第 2 步核对更新来源。如果根本没有命令，进入第 4 步。

2. 确认安装来源，只更新对应的那一份

适用情况： 已知道目标入口，但不确定上次更新作用在哪里。先查安装记录，不能只凭路径中出现 bin 就判断来源。

使用 npm 安装过的，先运行以下只读查询：

node --version
npm --version
npm prefix -g
npm list -g @openai/codex --depth=0

npm prefix 返回当前 npm 的全局前缀；npm list 用于核对当前全局安装记录。使用 Node 版本管理器时，不同 Node 环境可能对应不同全局目录；当前查询为空，并不能证明其他 Node 环境从未安装。

使用 Homebrew 安装过的，可查询：

brew list --cask --versions codex

对照 Homebrew 命令参考，确认 cask 的已安装版本与第 1 步入口是否对应。独立安装器则核对之前的安装输出和入口位置；Windows 的用户安装与以其他身份运行的安装器也要区分。

确认来源后，从下面选一项。这些是核验日 OpenAI CLI 安装页列出的更新方式，不需要全部执行：

已确认的安装来源	对应更新方法	更新后检查
独立安装器，macOS / Linux	重新运行官方同一安装脚本	对原目标入口查版本
独立安装器，Windows	在新的 PowerShell 窗口运行官方同一脚本	核对用户上下文与入口
npm 全局安装	更新当前目标 Node 环境下的包	对照 prefix、包版本与入口
Homebrew cask	升级已有 Codex cask	对照 cask 版本与入口

macOS / Linux 独立安装器：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Windows 独立安装器，按官方说明从新 PowerShell 窗口启动：

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

npm 全局安装：

npm install -g @openai/codex

Homebrew cask：

brew upgrade --cask codex

预期结果： 对应安装器或包管理器成功完成，目标入口能报告该来源预期的版本。若安装器已明确失败，先按错误修复下载、证书、目录访问或包管理器问题；不要默认加 sudo、关闭校验、清空缓存或切换所有安装方式。组织管理设备沿用其批准的更新渠道。

stable、alpha 和组织固定版本也要分别比较，不能拿另一个渠道的版本号当这次更新必达的结果。本文不写死“最新版”编号；记录你要更新的渠道与目标版本，再核验实际结果。

3. 新副本已更新，裸命令仍旧：修正入口选择

适用情况： 第 1 步用绝对路径已读到新版本，但日常输入 codex 仍启动旧版。

先保存工作，结束可以安全结束的旧 CLI 会话，再开一个新终端。编辑器内终端也可能继承编辑器启动时的环境；仅新建一个内部标签页仍旧时，保存工作并重新启动终端宿主，再检查。随后重复第 1 步的路径与版本查询。

证据	具体操作	如何确认
alias / function 固定旧路径	找到定义位置，记录原值，只调整这一项	新 shell 的解析结果指向预期入口
PATH 中旧安装目录优先	记录原顺序，只调整已确认的目标目录优先级	新终端裸命令与目标绝对路径版本一致
切换 Node 后才变化	回到要长期使用的 Node 环境，重新查 prefix 和包	更新与运行发生在同一环境
本机新，WSL / SSH / 容器旧	在实际执行端单独确认安装来源并更新	该执行端的入口和版本符合预期

不需要先卸载另一份安装；先让实际使用的入口明确且可验证。修改 PATH 时保留其他工具目录，避免把整条 PATH 替换为一个 Codex 目录。对于不熟悉的 shim，先确认创建它的管理器，再从管理器侧处理。

验证目标： 新终端的解析路径符合预期，裸命令与目标入口的 --version 一致。若仍不同，保留两组输出，继续查别名、函数、启动文件或远程宿主；反复重跑安装命令不能代替定位入口。

4. 更新后 `command not found`：先分辨缺安装还是缺入口

适用情况： 新终端也找不到 Codex。

先确认更新日志是否真的成功，再按第 2 步查已使用的包管理器或安装器记录。只检查该来源记录的安装位置，不必扫描整个磁盘。

如果可信的绝对路径能够运行，问题在当前终端的入口发现；按安装器说明让命令目录进入该用户的 PATH，再开新终端验证。若目标程序或必要运行文件缺失，则按已确认的原来源修复安装，并保留失败日志。

Windows 的官方企业部署说明指出，独立安装器默认针对当前用户；以 SYSTEM 身份运行不会自动变成面向所有员工的安装。也不能只复制 codex.exe 而丢掉同目录所需的运行文件。普通用户发现不了另一身份的安装时，先纠正安装上下文，不默认给整机扩大权限。

如果错误其实是“脚本执行被策略阻止”，说明找到了某个脚本入口，和没有命令不同；保留具体路径与策略错误，按组织批准的方法处理，不全局放宽执行策略。

5. 终端新版了，VS Code 或桌面应用为什么仍不同

适用情况： 全局 CLI 已更新，但另一个客户端显示不同版本或行为。

分别记录应用或扩展版本、实际执行主机，以及它是否使用自带运行时或远程服务。codex --version 只验证该终端解析到的 CLI，不能证明桌面应用、扩展或已运行的后台服务也已替换。正在运行的旧进程还需要按对应客户端说明安全重启或更新；不要一并结束其他任务。

官方 IDE 设置将自定义 CLI 执行路径设为开发用途。普通使用不要为了让版本一致，随意把全局 CLI 填进扩展设置。扩展空白、一直转圈或自定义路径异常时，继续看 VS Code 扩展排障。

6. 怎样确认这次更新真的完成

在实际使用的环境中新开终端，再次核对：当前入口是什么、对应哪种安装来源、裸命令与目标入口版本是否一致、版本是否符合所选渠道。单独的安装成功提示不够。

随后从原项目启动 CLI，确认配置可以正常加载，现有认证状态符合预期；检查到这里不必提交模型任务。如有配置解析或登录错误，保留具体错误，分别查 config.toml 不生效或登录失败排障。若需要验证服务请求，再在知晓当前账号用量的前提下发送最小只读任务。

整个更新排查无需删除配置、认证文件或历史会话目录，也无需修改 CODEX_HOME 来“刷新版本”。若真正的问题是 Git 提交被拒，可继续查 index.lock 与提交权限。

求助时附上脱敏后的入口列表、版本对比、安装来源、Node/npm 或 Homebrew 查询结果，以及一次更新的错误与退出状态。不要附带 token、完整环境变量或整个认证目录。

本文于 2026-10-17 核对官方资料，并用两份临时模拟可执行文件在 Bash、zsh 验证 PATH 优先级、绝对路径版本对比和新 shell 解析。它证明这些检查能区分入口，未执行真实更新；PowerShell 与 Windows 安装步骤以官方资料为依据，未冒充 Windows 实机测试。