Codex 无法加载工作空间设置？新聊天打不开时怎么排查
Codex 提示无法加载工作空间设置，不一定是 config.toml 出错。区分新聊天失败、403 验证、432 路由和 DeviceCheck 问题，按步骤定位并验收恢复结果。
Ofox 
Codex 提示“无法加载工作空间设置”时，先确认失败的是哪个请求，再决定是否改 config.toml 或重装应用。 应用能够打开，不代表工作空间初始化成功；同一个新聊天能收到模型回复，也不代表设置已经加载完成。仅凭这条提示，不能判断配置文件损坏、模型不可用或账号被限制。
本文处理的是桌面应用中新聊天或工作空间加载失败。如果是 VS Code 面板提示资源无法加载，请看扩展资源加载排错；如果后台进程根本起不来，请看 Windows app-server 启动排错。
资料核对日期为 2026 年 10 月 16 日，依据 OpenAI Codex 仓库中不同版本、不同错误表现的公开报告。我们没有在受控测试机上复现这些桌面故障。下文的对照表和恢复检查是诊断方法，不是“一招修好所有情况”的实测结论。本文由 Ofox 发布，API 服务不能代替桌面应用修复账号初始化。
先区分界面提示与真正失败的操作
重启前，记录“关于”页面中的应用版本、操作系统、带时区的发生时间，以及当时正在打开什么。先保存未完成的工作。排查需要的是第一次失败的证据，而不是连续改了十项设置之后的一份日志。
| 观察到的现象 | 能说明什么 | 下一项检查 |
|---|---|---|
| 新聊天失败，旧聊天仍能使用 | 部分已有状态仍然可用 | 对比有项目和无项目的新聊天 |
| 同一个报错新聊天仍能收到回复 | 对话与工作空间初始化的状态不同 | 分开检查设置和账号请求 |
| 同时测试时，浏览器能用而桌面端失败 | 不同客户端之间存在值得追查的差异 | 保留同时测试的结果和桌面错误 |
| 终端 CLI 能用 | 这条访问路径仍可运行 | 不要假定桌面端使用相同会话或配置 |
| 后台进程完全无法启动 | 失败早于工作空间初始化 | 转到 app-server 启动排查 |
Windows 报告 #54168 记录了一个容易误判的情况：同一个受影响的新聊天既显示设置错误，又能正常收到模型回复。日志中有工作空间路由和验证错误，同时本地配置读取成功。因此应逐项验证具体操作，不能直接认定整个客户端不可用；同样，也不能据此说所有设置报错都可以忽略。
每次只做一个小对照
可以使用不调用工具的简单提示：“只回复 OK，不读取文件，也不执行命令。”不要拿正在运行的生产任务测试恢复。某个入口没有条件测试时填“未测试”，不必为了填满表格临时安装另一个客户端。
| 测试项 | 记录内容 |
|---|---|
| 已有桌面聊天 | 能回复、输入被阻止、具体错误，或未测试 |
| 无项目的新桌面聊天 | 能否打开、提交、收到回复，分别记录 |
| 受影响项目中的新聊天 | 同样分别记录上述三项 |
| 同一预期账号和工作空间的浏览器入口 | 桌面报错期间，浏览器能否使用 |
| 已经安装的 CLI（如适用） | 能启动、认证失败，或其他错误 |
结果不同只能缩小范围，不能直接确定原因。例如，无项目聊天能用，不等于项目文件损坏；浏览器正常，也不能证明桌面应用走了同一网络路径或认证流程。
对照时保持预期账号、工作空间一致，不要同时换账号、网络和应用版本。即使错误消失，也应知道是哪一步发生了变化，否则难以判断恢复是否可重复。
把状态码、请求路径和错误码放在一起看
从应用提供的诊断信息或本地桌面日志中，找出接近测试时间的失败记录，只摘取必要字段。下述 macOS 报告使用 ~/Library/Logs/com.openai.codex/，这是报告中的路径，不是所有 Windows 或未来版本都适用的固定位置。Windows 用户应使用已安装应用支持的诊断方式，或按 OpenAI 支持人员的说明获取日志，不要猜一个包目录就删除。
下表汇总的是公开报告中的错误特征，并非我们账号的真实日志。DeviceCheck 行中的 status=500 是应用日志记录的状态，不能仅据此认定 OpenAI 服务端返回了 HTTP 500。
| 同一条请求记录中的特征 | 证据支持的解释 | 不能据此下的结论 |
|---|---|---|
/settings/user 或账号检查，403，cloudflare_challenge | 该请求遇到了验证挑战 | 账号被封，或一定是代理导致 |
账号检查，500，devicecheck_token_generation_failed | 该报告出现设备令牌生成失败 | 所有工作空间错误都是 DeviceCheck 问题 |
/settings/user，432，工作空间路由不可用信息 | 该安装环境报告工作空间路由不可用 | 所有 API 的 432 都是同一种错误 |
本地 config/read 成功，同时设置请求失败 | 本地配置读取可与该故障同时存在 | 远端初始化和所有文件操作都已成功 |
附近出现 fs/readFile requires an environmentId | 某次文件操作缺少所需环境上下文 | 已证明它就是界面提示的原因 |
不要把一行的 403、另一行的请求路径和第三行的 DeviceCheck 错误拼成一条并不存在的请求。匹配到多少行日志，也不等于多少用户或多少次独立失败操作。
日志显示 Cloudflare challenge 时
问题 #52790 记录了 Windows 上设置和账号请求遇到验证的情况。其中一次重新登录带来暂时恢复，另一些后续报告则没有恢复。因此，重新认证只适合做一次有边界的诊断尝试，不能当作长期有效的修复承诺。
保存工作、确认自己能够重新登录后，通过应用正常的退出登录和登录流程尝试一次。然后打开新聊天，重复相同的小测试，再看下一个新聊天是否仍然正常。不要把浏览器 Cookie 复制到桌面客户端，不要关闭证书验证，也不要修改验证令牌。
问题 #53994 描述了 macOS 上反复出现的故障，包括锁屏后解锁再次失败、Chrome 仍可使用等现象。后续诊断还在不同请求中发现了多类错误。切换代理模式或浏览器正常，都不足以确定唯一根因。如果锁屏和解锁确实是你的触发条件，把这个过程写进报告；不要推断其他机器也一定如此。
日志显示 DeviceCheck 时
问题 #52342 描述了特定 macOS 环境中的设备令牌错误和新聊天失败。报告者的 CLI 可用，但重启、重新认证没有解决该次故障。这支持单独排查设备验证，不支持让所有用户重置凭据。
记录准确的应用和 macOS 版本，区分令牌生成失败与注册失败，并写清失败请求。通过正常更新器检查是否有可安装的更新；如果没有，也保留这一结果。某条 issue 提到的版本号不等于要求你安装那个旧版本。不要绕过设备验证，也不要移除受管理的安全控制。
按顺序恢复，并设定停止条件
- 先保存、再记录。 保留工作、首次错误、应用版本和测试时间。不要先清空应用数据，把诊断证据一起删掉。
- 检查服务状态。 在 OpenAI Status 查看与你的产品和时间对应的事件。状态页正常，不代表你的账号访问路径一定正常。
- 检查应用更新。 记录当前版本及是否有符合条件的更新。更新后先重复相同测试，再考虑下一项变化。
- 条件允许时完整重启一次。 保存活动任务后退出并重新打开。短暂恢复、下一个新聊天又失败，仍然只能记为暂时恢复。
- 按错误证据选择分支。 请求遇到验证、设备令牌失败、本地进程无法启动，需要收集的信息不同。重新认证只通过正常入口进行，并确保之后能够恢复登录。
- 同一错误仍在，就停止反复试错。 用下方记录表向支持渠道反馈。不要无休止地重装、切换账号或重写配置。
如果浏览器或旧聊天仍可使用，可以暂时继续适合在该入口完成的工作。但要确认账号、工作空间和可用工具。能收到文本回复，不等于文件访问、浏览器自动化或原任务环境也正常。
提示消失之后，还要验收实际任务
验收应覆盖原先失败的活动。若原问题是新聊天打不开，应在相应项目中新建聊天，发送简单测试，并确认加载的是预期工作空间。如果任务需要文件访问，用一个明确授权的非敏感文件验证是否真的读到了内容，不要只听模型说“可以访问”。
若原触发条件是新窗口、锁屏或解锁，应保存工作后再重复该条件。结果只记为这次观察到的恢复，不写成长期稳定保证。能回复但设置仍报错，应标为部分恢复。
反馈时可使用这份摘要，不必附上完整私人日志：
产品：桌面应用，而不只是终端 CLI
应用版本 / 操作系统版本：
发生时间与时区：
触发条件：新聊天 / 新窗口 / 项目 / 解锁 / 其他
旧聊天 / 无项目新聊天 / 项目新聊天的结果：
同时测试的浏览器结果：
同一记录中的路径模式 + 状态码 + 错误码：
本地配置读取：成功 / 失败 / 未检查
逐项尝试过的变化及结果：
恢复情况：未恢复 / 暂时恢复 / 部分恢复 / 复测通过分享前删除令牌、Cookie、认证请求头、账号标识、私人路径和对话内容。支持人员确有需要时，再通过合适的私密渠道提供敏感材料。重点是让别人理解如何复现，而不是公开一大包日志。
如果看到的是其他错误
- CLI 提示后台服务功能设置不兼容：看客户端与 daemon 设置对照。
- 请求运行中、完成之前断流：看连接中断排查。
- 聊天正常，但无法操作桌面或浏览器：看 Computer Use 权限与连接排查。
这些故障发生在不同阶段，修好其中一项并不代表其他阶段也已通过。更换模型或 API 供应商，也不是已经证实的工作空间设置初始化修复办法。
