Codex桌面版更新后不能使用最新模型问题-排查修复总结

Codex 桌面版更新后没有不能选择最新模型？排查 CODEX_CLI_PATH 导致的旧执行器绑定

明明已经更新 Codex，桌面模型列表却仍停留在旧版本；终端和桌面显示的版本还不一样。这类问题不一定需要重装，可能是桌面被一个历史环境变量固定到了旧执行器。

本文记录一次 Windows 环境下的实际排查：独立后台服务已经更新到 0.159.2，桌面却仍在启动 0.149.1。最终发现，用户级 CODEX_CLI_PATH 指向了旧程序。修改绑定之前，用新版执行器查询模型列表，已经能够看到 GPT-6.1 Sol 和 GPT-6 Astra。

案例时间：2026 年 9 月 30 日。文中的版本和模型是当时的实测结果，不代表以后始终是最新版。本文已完成路径修复和新版模型目录查询，桌面完整重启后的菜单及实际推理验收仍待完成。

1. 问题表现：程序更新了，模型列表没有跟着更新

这次排查遇到了两个现象。

第一个是历史上的本地命令启动失败：

text 复制代码

orchestrator_helper_launch_failed
setup refresh failed to launch helper
helper=codex-windows-sandbox-setup.exe
error=program not found

错误发生在 PowerShell 真正启动之前，因此 Get-Date 和 codex doctor 当时都没有执行。

第二个是桌面看不到新模型。重新检查时，本地命令已经能够执行，独立后台服务也已更新，但桌面模型列表仍然只有 GPT-5.6 系列和 GPT-5.5。

两者需要分别验收：命令能够运行，只能说明当前执行链可用；它不能证明模型菜单使用的客户端、缓存和后台服务都已经更新。

2. 为什么只看 codex --version 容易误判

这台机器实际上存在多个 Codex 入口：

入口	本次版本	检查到的情况
桌面 AppX 应用包	`26.928.1915.0`	应用包状态为 `Ok`
独立 app-server daemon	`0.159.2`	已更新，后台正在运行
用户目录中的旧 codex.exe	`0.149.1`	桌面仍被环境变量强制引向这里
普通终端中的 npm CLI	`0.157.0`	终端包装脚本调用的另一份安装

终端里的 codex --version 只验证命令解析到的那个入口。AppX 版本、后台服务版本和桌面实际启动的执行器版本，必须分别检查。

3. 第一步：查命令入口和实际进程

以下命令建议在你自己的 PowerShell 中执行。若受限终端不能读取进程信息，可改用普通用户终端；必要时再以管理员身份运行。不要把"拒绝访问"误判为程序不存在。

先查看终端命令解析结果：

powershell 复制代码

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

codex --version

再检查运行中的 Codex 执行器：

powershell 复制代码

Get-CimInstance Win32_Process -Filter "Name='codex.exe'" |
    Select-Object ProcessId, ExecutablePath, CommandLine |
    Format-List

重点看 ExecutablePath，以及 CommandLine 中是否带有 app-server。

在本案例中，独立 daemon 使用新版目录，但另一个桌面 app-server 的可执行文件仍是：

text 复制代码

C:\Users\<用户名>\.codex\bin\codex.exe

对这个具体文件执行版本检查后，结果为 0.149.1。

powershell 复制代码

# 替换为上一条命令查到的实际路径
$desktopCliPath = 'C:\实际路径\codex.exe'
& $desktopCliPath --version

分享排查结果时，先隐去用户名、个人目录及启动参数中可能出现的敏感信息。

4. 第二步：检查 CODEX_CLI_PATH 是否覆盖了默认入口

分别查看进程、用户和系统级设置：

powershell 复制代码

[pscustomobject]@{
    Process = [Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'Process')
    User    = [Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'User')
    Machine = [Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'Machine')
} | Format-List

本案例用户级设置指向旧版文件，而桌面实际进程也使用同一路径。两条证据对应后，才能确认路径覆盖是本次根因。

如果这个变量为空，或指向的文件已经是新版，就不要照搬后面的修改。应继续检查应用自己的启动配置、模型缓存、登录方式和账号开放状态。

5. 第三步：读取模型缓存，确认是谁写入了旧列表

先确定 Codex 配置目录。自定义过 CODEX_HOME 的机器，不一定使用默认 .codex 目录：

powershell 复制代码

$codexDataDir = [Environment]::GetEnvironmentVariable('CODEX_HOME', 'User')
if ([string]::IsNullOrWhiteSpace($codexDataDir)) {
    $codexDataDir = Join-Path $env:USERPROFILE '.codex'
}

$modelCachePath = Join-Path $codexDataDir 'models_cache.json'
if (Test-Path -LiteralPath $modelCachePath) {
    $modelCache = Get-Content -LiteralPath $modelCachePath -Raw |
        ConvertFrom-Json

    $modelCache | Select-Object fetched_at, client_version
    $modelCache.models |
        Select-Object slug, display_name, visibility |
        Format-Table -AutoSize
}

本案例缓存的 client_version 是 0.149.1，并且还在刷新。列表中没有 GPT-6.1 Sol。

这说明"旧模型缓存"是一个有效线索，但单独看缓存仍不足以证明账号没有权限，也不能证明新版一定可以调用模型。下一步要对新版执行器单独查询。

缓存结构属于客户端实现细节，不同版本可能变化。不要手工向缓存添加模型，也不要把删除缓存作为第一步：旧进程仍在运行时，可能继续写回旧列表。

6. 第四步：用新版执行器查询可用模型

OpenAI 的 app-server 提供 model/list 接口，可在初始化连接后查询可用模型。返回列表取决于客户端和账号，应该读取实际结果。官方 App Server 文档

本案例用 0.159.2 启动临时诊断进程，完成初始化与查询后退出，得到以下结果：

模型	是否可见	是否默认
`gpt-6.1-sol`	是	是
`gpt-6-astra`	是	否
`gpt-6-sol`	是	否
`gpt-6-luna`	是	否

这把排查范围进一步缩小了：新版执行器可以获取新模型目录，桌面却还在使用旧版入口。

需要区分三个结果：

查询接口返回模型。
桌面菜单出现模型。
选中模型后完成实际请求。

本案例在修复前验证了第一项。第二、第三项要在桌面重新启动后验收。

7. 修复：备份并修改旧版路径覆盖

只有确认 CODEX_CLI_PATH 指向旧版，且已经找到可正常运行的新入口后，才执行这一节。

本案例新版安装包含以下结构：

text 复制代码

<Codex配置目录>\packages\app-server-daemon\
├── current\
│   └── bin\codex.exe
└── releases\
    └── <版本与平台>\
        ├── bin\codex.exe
        ├── codex-resources\
        └── codex-path\

这是本次观察到的目录结构，并非所有安装方式都保证存在。选择 current\bin\codex.exe 是因为本次安装的 current 指向当前发行目录，可以避免硬编码某个旧 releases 版本。

下面的脚本会验证文件和版本，保存旧设置，再写入用户级环境变量。请把第一行替换为你已核实的新执行器路径。

powershell 复制代码

$newCliPath = 'C:\实际配置目录\packages\app-server-daemon\current\bin\codex.exe'

if (-not (Test-Path -LiteralPath $newCliPath -PathType Leaf)) {
    throw '新执行器不存在，请先确认实际安装路径。'
}

& $newCliPath --version
if ($LASTEXITCODE -ne 0) {
    throw '新执行器版本检查失败，停止修改。'
}

$previousCliPath = [Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'User')
$desktopDir = [Environment]::GetFolderPath('Desktop')
$backupPath = Join-Path $desktopDir (
    'codex-cli-path-backup-' + (Get-Date -Format 'yyyyMMdd-HHmmss') + '.json'
)

if (Test-Path -LiteralPath $backupPath) {
    throw '备份文件已存在，停止修改以免覆盖。'
}

[pscustomobject]@{
    Name        = 'CODEX_CLI_PATH'
    Scope       = 'User'
    Previous    = $previousCliPath
    Replacement = $newCliPath
    Time        = (Get-Date).ToString('o')
} | ConvertTo-Json |
    Set-Content -LiteralPath $backupPath -Encoding UTF8

[Environment]::SetEnvironmentVariable('CODEX_CLI_PATH', $newCliPath, 'User')

[Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'User')
Write-Host "备份文件：$backupPath"

写入用户环境变量不会改变已经运行的桌面进程，也不会自动更新所有父进程的环境。本案例额外向 Windows 广播了环境变化通知。

如果手工修复后重新启动应用仍继承旧值，可保存任务后注销并重新登录 Windows，确保从新的用户会话启动应用。无需为此删除配置目录。

8. 重启后怎样判断修复生效

保存其他任务，完整退出桌面应用，再重新打开。只关闭窗口可能仍保留后台进程。

重新检查：

powershell 复制代码

Get-CimInstance Win32_Process -Filter "Name='codex.exe'" |
    Select-Object ProcessId, ExecutablePath, CommandLine |
    Format-List

验收应包含：

桌面新启动的 app-server 使用已核实的新执行器。使用 current 链接启动时，进程路径也可能显示其实际 releases 目标。
桌面模型菜单或 Advanced／高级选项出现新模型。
选择模型后，完成一次简短请求。
本地工具仍能执行，例如让 Codex 运行 Get-Date。

本案例的公开记录目前止于路径修改完成、新版模型目录查询成功，不能把这几个后续步骤写成已经全部通过。

如果新版 model/list 本身也没有目标模型，应转向账号、登录方式、套餐和工作区开放状态排查。官方说明模型可用性依赖这些条件；改一个模型名不会获得额外权限。官方模型说明

9. 相关故障：找不到沙箱辅助程序，该怎么检查

遇到 codex-windows-sandbox-setup.exe 找不到时，先检查错误中的启动目录和实际执行器目录。

AppX 应用包可以这样查看：

powershell 复制代码

Get-AppxPackage |
    Where-Object { $_.Name -match 'Codex|OpenAI' } |
    Select-Object Name, Version, InstallLocation, Status

辅助程序应在已确认的执行器安装范围内查找，避免扫描整个磁盘：

powershell 复制代码

# 替换为实际执行器发行目录
$executorReleaseDir = 'C:\实际路径\执行器发行目录'

Get-ChildItem -LiteralPath $executorReleaseDir -Recurse -File `
    -Filter 'codex-windows-sandbox-setup.exe' |
    Select-Object FullName, Length

本案例辅助程序存在于独立执行器的 codex-resources 目录，当前会话命令也能正常启动。对实际执行器运行：

powershell 复制代码

& $desktopCliPath doctor --summary

诊断结果为 20 ok / 0 fail，但仍有警告，整体标记 degraded。这表示核心检查通过，不能写成"所有检查完全正常"。

历史命令故障的恢复原因没有被完整记录，不能断言后来的模型路径修改同时修复了历史沙箱故障。只有辅助程序确实缺失或损坏、正确路径无法运行，并结合安装诊断证据时，才进一步考虑应用修复或重新安装。

10. 回滚方法

如果新入口导致兼容性问题，可以用备份恢复旧用户环境变量：

powershell 复制代码

# 替换为修复时生成的备份文件
$backupPath = 'C:\实际桌面路径\codex-cli-path-backup-时间戳.json'
$backup = Get-Content -LiteralPath $backupPath -Raw | ConvertFrom-Json

if ($backup.Name -ne 'CODEX_CLI_PATH' -or $backup.Scope -ne 'User') {
    throw '备份内容不匹配，停止回滚。'
}

[Environment]::SetEnvironmentVariable(
    'CODEX_CLI_PATH',
    $backup.Previous,
    'User'
)

如果原值为空，恢复为空相当于移除这一用户级覆盖。回滚后同样需要重新启动应用，并确保它继承了恢复后的环境。

11. 本次排查留下的经验

"应用已更新""终端 CLI 已更新""后台服务已更新"和"桌面实际使用新版执行器"是四个不同的检查结果。判断是否更新成功，需要把实际进程路径与具体文件版本对应起来。

这次有效的证据链是：

text 复制代码

桌面模型缺失
→ 旧缓存标记为 0.149.1
→ 桌面进程确实运行旧版文件
→ CODEX_CLI_PATH 指向该旧文件
→ 新版独立查询能返回新模型
→ 备份并修正路径
→ 重启后验收菜单和实际请求

遇到类似情况，可以先从 CODEX_CLI_PATH 和运行中的 app-server 路径查起。确认入口混用后再修复绑定，比根据单个版本号推测原因更容易得到可验证的结果。