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. 问题表现程序更新了模型列表没有跟着更新这次排查遇到了两个现象。第一个是历史上的本地命令启动失败orchestrator_helper_launch_failed setup refresh failed to launch helper helpercodex-windows-sandbox-setup.exe errorprogram 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 daemon0.159.2已更新后台正在运行用户目录中的旧 codex.exe0.149.1桌面仍被环境变量强制引向这里普通终端中的 npm CLI0.157.0终端包装脚本调用的另一份安装终端里的codex --version只验证命令解析到的那个入口。AppX 版本、后台服务版本和桌面实际启动的执行器版本必须分别检查。3. 第一步查命令入口和实际进程以下命令建议在你自己的 PowerShell 中执行。若受限终端不能读取进程信息可改用普通用户终端必要时再以管理员身份运行。不要把“拒绝访问”误判为程序不存在。先查看终端命令解析结果Get-Commandcodex-All|Select-ObjectCommandType,Name,Source codex--version再检查运行中的 Codex 执行器Get-CimInstanceWin32_Process-FilterNamecodex.exe|Select-ObjectProcessId,ExecutablePath,CommandLine|Format-List重点看ExecutablePath以及CommandLine中是否带有app-server。在本案例中独立 daemon 使用新版目录但另一个桌面 app-server 的可执行文件仍是C:\Users\用户名\.codex\bin\codex.exe对这个具体文件执行版本检查后结果为0.149.1。# 替换为上一条命令查到的实际路径$desktopCliPathC:\实际路径\codex.exe$desktopCliPath--version分享排查结果时先隐去用户名、个人目录及启动参数中可能出现的敏感信息。4. 第二步检查 CODEX_CLI_PATH 是否覆盖了默认入口分别查看进程、用户和系统级设置[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目录$codexDataDir[Environment]::GetEnvironmentVariable(CODEX_HOME,User)if([string]::IsNullOrWhiteSpace($codexDataDir)){$codexDataDirJoin-Path$env:USERPROFILE.codex}$modelCachePathJoin-Path$codexDataDirmodels_cache.jsonif(Test-Path-LiteralPath$modelCachePath){$modelCacheGet-Content-LiteralPath$modelCachePath-Raw|ConvertFrom-Json$modelCache|Select-Objectfetched_at,client_version$modelCache.models|Select-Objectslug,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指向旧版且已经找到可正常运行的新入口后才执行这一节。本案例新版安装包含以下结构Codex配置目录\packages\app-server-daemon\ ├── current\ │ └── bin\codex.exe └── releases\ └── 版本与平台\ ├── bin\codex.exe ├── codex-resources\ └── codex-path\这是本次观察到的目录结构并非所有安装方式都保证存在。选择current\bin\codex.exe是因为本次安装的current指向当前发行目录可以避免硬编码某个旧 releases 版本。下面的脚本会验证文件和版本保存旧设置再写入用户级环境变量。请把第一行替换为你已核实的新执行器路径。$newCliPathC:\实际配置目录\packages\app-server-daemon\current\bin\codex.exeif(-not(Test-Path-LiteralPath$newCliPath-PathType Leaf)){throw新执行器不存在请先确认实际安装路径。}$newCliPath--versionif($LASTEXITCODE-ne0){throw新执行器版本检查失败停止修改。}$previousCliPath[Environment]::GetEnvironmentVariable(CODEX_CLI_PATH,User)$desktopDir[Environment]::GetFolderPath(Desktop)$backupPathJoin-Path$desktopDir(codex-cli-path-backup-(Get-Date-FormatyyyyMMdd-HHmmss).json)if(Test-Path-LiteralPath$backupPath){throw备份文件已存在停止修改以免覆盖。}[pscustomobject]{Name CODEX_CLI_PATHScope UserPrevious $previousCliPathReplacement $newCliPathTime (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. 重启后怎样判断修复生效保存其他任务完整退出桌面应用再重新打开。只关闭窗口可能仍保留后台进程。重新检查Get-CimInstanceWin32_Process-FilterNamecodex.exe|Select-ObjectProcessId,ExecutablePath,CommandLine|Format-List验收应包含桌面新启动的 app-server 使用已核实的新执行器。使用 current 链接启动时进程路径也可能显示其实际 releases 目标。桌面模型菜单或 Advanced高级选项出现新模型。选择模型后完成一次简短请求。本地工具仍能执行例如让 Codex 运行Get-Date。本案例的公开记录目前止于路径修改完成、新版模型目录查询成功不能把这几个后续步骤写成已经全部通过。如果新版model/list本身也没有目标模型应转向账号、登录方式、套餐和工作区开放状态排查。官方说明模型可用性依赖这些条件改一个模型名不会获得额外权限。官方模型说明9. 相关故障找不到沙箱辅助程序该怎么检查遇到codex-windows-sandbox-setup.exe找不到时先检查错误中的启动目录和实际执行器目录。AppX 应用包可以这样查看Get-AppxPackage|Where-Object{$_.Name-matchCodex|OpenAI}|Select-ObjectName,Version,InstallLocation,Status辅助程序应在已确认的执行器安装范围内查找避免扫描整个磁盘# 替换为实际执行器发行目录$executorReleaseDirC:\实际路径\执行器发行目录Get-ChildItem-LiteralPath$executorReleaseDir-Recurse-File -Filtercodex-windows-sandbox-setup.exe|Select-ObjectFullName,Length本案例辅助程序存在于独立执行器的codex-resources目录当前会话命令也能正常启动。对实际执行器运行$desktopCliPathdoctor--summary诊断结果为20 ok / 0 fail但仍有警告整体标记degraded。这表示核心检查通过不能写成“所有检查完全正常”。历史命令故障的恢复原因没有被完整记录不能断言后来的模型路径修改同时修复了历史沙箱故障。只有辅助程序确实缺失或损坏、正确路径无法运行并结合安装诊断证据时才进一步考虑应用修复或重新安装。10. 回滚方法如果新入口导致兼容性问题可以用备份恢复旧用户环境变量# 替换为修复时生成的备份文件$backupPathC:\实际桌面路径\codex-cli-path-backup-时间戳.json$backupGet-Content-LiteralPath$backupPath-Raw|ConvertFrom-Jsonif($backup.Name-neCODEX_CLI_PATH-or$backup.Scope-neUser){throw备份内容不匹配停止回滚。}[Environment]::SetEnvironmentVariable(CODEX_CLI_PATH,$backup.Previous,User)如果原值为空恢复为空相当于移除这一用户级覆盖。回滚后同样需要重新启动应用并确保它继承了恢复后的环境。11. 本次排查留下的经验“应用已更新”“终端 CLI 已更新”“后台服务已更新”和“桌面实际使用新版执行器”是四个不同的检查结果。判断是否更新成功需要把实际进程路径与具体文件版本对应起来。这次有效的证据链是桌面模型缺失 → 旧缓存标记为 0.149.1 → 桌面进程确实运行旧版文件 → CODEX_CLI_PATH 指向该旧文件 → 新版独立查询能返回新模型 → 备份并修正路径 → 重启后验收菜单和实际请求遇到类似情况可以先从CODEX_CLI_PATH和运行中的 app-server 路径查起。确认入口混用后再修复绑定比根据单个版本号推测原因更容易得到可验证的结果。