Codex 更新后打不开，一直提示“无法加载组织设置”？这是我今天的排查和修复经过

10 月 24 日，Codex 更新之后突然打不开了。

程序并不是完全没反应。启动后先弹出一个窗口，标题是“无法加载组织设置”，下面提示网络连接、代理或者防火墙可能导致无法访问，让我检查网络后重试，或者退出登录。

我第一反应也是网络问题。毕竟平时用 Codex 就开着代理，看到“组织设置”“防火墙”这几个字，很容易先往这方面想。

但我的代理已经开了全局/TUN 模式，而且这个错误是更新 Codex 后才出现的。反复点重试没解决，我就没继续在代理设置上折腾。

这回我没有急着卸载重装。一方面，重装未必能解决问题；另一方面，我之前在 Codex 里积累了不少项目和对话记录，不想因为一个启动故障把数据弄丢。

索性打开 PowerShell，一项一项查。

先确认程序和数据还在不在

我先用下面的命令查看 Codex 安装状态：

Get-AppxPackage OpenAI.Codex | Select-Object Name, Version, Status

查出来的版本是 26.1021.3705.0，状态为 Ok。

至少从 Windows 的安装状态来看，主程序没有直接被标成异常。

随后又检查了用户目录下的 .codex 文件夹。

config.toml、sessions、state_5.sqlite 和 thread_history_1.sqlite 都还在，其中历史数据库大约 292 MB。

这只能说明文件存在，不能证明里面的数据一定完好，但至少没必要上来就清理用户目录。

真正有用的线索藏在日志里

接下来查启动日志，发现同一类警告出现了很多次：

Desktop startup policy read failed
attempt=1
phase=policy-read
reason=protocol
retrying=false

通俗点说，就是 Codex 在读取启动策略的时候失败了。

不过，这条日志只能告诉我失败发生在哪个阶段，还不能直接确定是代理、内部进程，还是配置出了问题。

我还查了安装包列表，发现一个看着挺吓人的结果：

CodexPrimaryRuntime 的状态居然是 NotAvailable，但 Codex 主程序仍然是 Ok。

一开始也怀疑过是不是这个运行时坏了。

好在当时没有直接去删它，因为后面事实证明，即使显示这个状态，Codex 依然能恢复打开。它未必就是这次故障的原因。

最后把注意力放到了一个环境变量上

继续检查时又发现，我的系统里设置过一个自定义环境变量：

CODEX_CLI_PATH

这个变量可以用来指定 Codex CLI 的路径。

我的检测结果是：变量确实存在，而且对应的文件路径也存在。

但路径存在，不代表旧 CLI 和刚更新的桌面版一定兼容。尤其是在更新之后，这种自定义覆盖项就值得先排除。

我决定先做一个可逆的测试：备份这个变量的原值，只移除用户级的 CODEX_CLI_PATH，暂时让桌面版使用它自己的默认配置。

没有删除 .codex 文件夹，更没有碰会话数据库。

当时处理这一步的 PowerShell 代码可以整理成下面这样：

$name = 'CODEX_CLI_PATH'
$old = [Environment]::GetEnvironmentVariable($name, 'User')

if ($old) {
    $backup = Join-Path $env:USERPROFILE (
        'CODEX_CLI_PATH-' + (Get-Date -Format 'yyyyMMdd-HHmmss') + '.txt'
    )
    Set-Content -LiteralPath $backup -Value $old -Encoding UTF8
    [Environment]::SetEnvironmentVariable($name, $null, 'User')
    Write-Host "原值已备份到：$backup"
} else {
    Write-Host '没有找到用户级 CODEX_CLI_PATH，请先继续检查其他原因。'
}

这里强调一下：这段代码只针对用户级环境变量。如果变量是系统级的，或者你本来就没设置这个变量，情况就不一样，别看到文章就不加检查地照抄。

注销 Windows 后，事情开始有了变化

执行完代码，我按提示注销了 Windows 用户，然后重新登录系统，再打开 Codex。

但奇怪的是，点击图标后并没有马上弹出桌面窗口。

我打开任务管理器，发现 Codex 其实已经在后台运行了，前台就是看不见。

当时我没有再急着结束进程，而是观察了一会儿。

过了几分钟，Codex 的桌面窗口自己出来了，而且可以正常使用，之前的报错也没再弹出。

到这里，这次问题总算解决。

这次到底是什么原因？

从整个排查过程来看，我比较怀疑的是：旧的自定义 CODEX_CLI_PATH 与更新后的 Codex 桌面版存在兼容问题。

移除用户级变量、重新登录 Windows 之后，程序恢复了正常，这个关联很明显。

但我不打算把它写成百分之百确定的“官方根因”。因为中间还发生了窗口延迟出现的情况，不能完全排除更新后首次启动初始化较慢等因素。

日志中的 reason=protocol 也不是“CLI 路径冲突”的直接证明。

如果你也遇到了这个弹窗，我建议先看三个地方：更新前后是否有变化、日志是否反复出现 policy-read、是否设置过 CODEX_CLI_PATH。

确定要修改环境变量时，记得先备份原值，再注销 Windows 重新登录测试。

最后说一句：碰到这种启动故障，别一上来就删 .codex 或者清数据库。

很多时候程序打不开，并不代表自己的项目和历史会话没了。先把数据留住，再排查，心里也踏实。

本文记录的是我在 2026 年 10 月 24 日亲自遇到和修复的问题，截图均来自当天的实际排查过程。不同版本的 Codex 可能有不同原因，本文仅供排查参考。