Codex 无法加载工作空间设置：新聊天发不出，按日志分两类排查

ChatGPT 桌面版里的 Codex（不少人叫它 Codex 桌面版、电脑版 Codex）新建聊天时，输入框上方出现「无法加载工作空间设置」和「请重试以继续聊天」，发送按钮是灰的。英文界面对应的是 "Couldn't load workspace settings / Retry to continue chatting"，去 GitHub 搜这句能找到更多报告。

这批报告从 2026 年 10 月 7 日前后、桌面版更新到 26.1002.52244 开始集中出现，10 月 14 日发布的 26.1007.71326 上仍有人遇到。截至 2026 年 10 月 15 日，OpenAI 没有针对这个报错的说明或修复。先抓住三点：

• 它只挡新聊天。已有聊天、chatgpt.com 网页版和 Codex CLI 通常照常能用，手上有急活先切过去。
• 日志里多半是两类失败之一。带 cloudflare_challenge 的 403 主要在 Windows 上，有用户报告换节点、新建时选项目、等一会儿后恢复；DeviceCheck 失败主要在 macOS 上，本机能做的很少。
• Retry、重装、更新到最新版、改 config.toml 都被多位用户报告无效，不用再在这些上花时间。

下面所说的"有效""无效"都来自 GitHub openai/codex 仓库和中文论坛里的用户报告，每条附了 issue 编号和日期。同一个办法经常有人成功、有人失败，所以只能当作值得花几分钟试的线索，不是保证。

无法加载工作空间设置和无法加载组织设置不是同一个错误

两个提示只差两个字，处理方向却不同。先对照表现，确认自己遇到的是哪一个：

如果你看到的是弹窗、整个应用进不去，直接看后面「无法加载组织设置」那一节。另外几个容易混在一起的报错各有处理办法：

• 登录时报 token exchange failed 403：见 Codex 令牌交换失败 403 怎么解决？按错误后缀定位登录拒绝。
• 聊天进行到一半报 429、401 或流中断：见 Codex exceeded retry limit 429、401 与 Stream Disconnected 排查。
• 用的是 VS Code 插件，面板转圈后报 could not start：见 Codex could not start 报错：VS Code 插件按环境排查，哪些已修复。

是本机问题还是 OpenAI 的问题：更新后成批出现，官方尚未回应

更像是桌面应用和 OpenAI 服务端之间的问题，而不是你的账号或电脑坏了。依据有三条：

1. 时间和版本集中。最早一批报告出现在 10 月 7 日到 8 日，报告者用的是 26.1002.52244（Windows 包版本 26.1002.7124.0；见 #51917、#51691），之后的 26.1007.21159、26.1007.21434、26.1007.30912 都有人报告；10 月 14 日更新到 26.1007.71326 的用户也说问题还在（#53609 10 月 14 日、#52342 10 月 15 日的评论）。
2. 同一账号在别处正常。多数报告者都提到：同账号在浏览器里的 chatgpt.com 能新建聊天，已有的桌面聊天能继续发，Codex CLI 也正常。一位 Windows 用户运行 codex doctor，配置解析、认证、本地状态库、WebSocket 连接全部显示正常（#52437 下 Sam9965 的评论，10 月 10 日）。
3. 失败点在服务端请求上。桌面日志里失败的是 /settings/user、/accounts/check/{version} 这类向 ChatGPT 服务端取账号和设置的请求，下一节细说。

OpenAI 状态页在 10 月 7 日记录过一次「Unable to create new ChatGPT Work threads in latest version of desktop app」，影响组件是 Codex in ChatGPT Desktop，处理结果是"已发布修复版本，受影响用户请更新到最新版"，状态为已解决（OpenAI 状态页上的这条事故记录）。这条事故没有提到 workspace settings，之后更新到更高版本的用户仍在报告，所以不能把它当作这个报错的修复。截至 10 月 15 日，相关 GitHub issue 下没有 OpenAI 成员回复，learn.chatgpt.com 的产品更新日志也没有对应条目。

也有例外：一位 Windows 用户在 26.1007.71326 上，报错横幅一直在，但新窗口里的消息照样能发出去并收到回复（#54168，10 月 15 日）。如果你点了发送其实能用，先用着就行。

先看桌面日志：搜 cloudflare_challenge 和 DeviceCheck

用户贴出的日志里，失败请求的格式大致是：

sa_server_request_failed ... routePattern=/settings/user status=403 errorCode=cloudflare_challenge

errorCode 后面的值决定了你该走哪条路。macOS 的日志在 ~/Library/Logs/com.openai.codex（来自 #52342 报告者），在终端里运行下面这行，可以按出现次数列出所有错误码：

grep -rhoE "errorCode=[a-z_]+" ~/Library/Logs/com.openai.codex | sort | uniq -c | sort -rn

Windows 版的日志位置没有公开说明。GitHub 上的 Windows 报告者贴出的也是同样的字段，你可以在应用日志里搜 cloudflare_challenge、/settings/user 对照。找不到日志也不要紧：Windows 上的报告大多是第一类，DeviceCheck 失败只见于 macOS。

cloudflare_challenge 403：这几步有用户报告恢复过

这一类没有稳定解法，但有几步成本很低，值得按顺序各试一次。下表左栏是报告恢复的，右栏是同样做了却无效的：

建议的顺序是先做不费事的：选项目新建、Retry 时发送，再到内置浏览器过一次检查，然后换节点、重启、重新登录，最后给它半小时。中文论坛里也有人说"在网页版 chatgpt 上退出登录再重新登录即可"，这句话只见于搜索摘要，原帖读不到细节。

关于代理，有几点要知道：

• 换代理模式没用。在 Clash Verge 里切系统代理和 TUN（#53384），或在 Clash Mi 里切规则和全局（#53994），都被报告无效。值得试的是换出口，不是换模式。
• "节点不干净"是用户的推测。日志只能说明请求被 Cloudflare 挑战，不能说明是出口 IP 的信誉问题。换节点的结果时好时坏，也说明不能把原因全算在出口 IP 上。
• 关掉 CC Switch 那条只针对用了它的人。CC Switch 会改写 Codex 的供应商配置；如果你在 config.toml 里接了自定义 API，配置的写法见 Codex 自定义 API 配置：Key、Base URL 与 Provider 怎么选。没用过它的人不必去动配置文件。

macOS 上有一位用户发现，每次锁屏再解锁后报错就会复发，重启应用只能管一阵（#53994，10 月 14 日，Clash Mi TUN 模式）。如果你也是这样，与其反复重启，不如直接换入口。

macOS 上的 DeviceCheck 失败：本机能做的很少，别为它重装系统

日志里出现 devicecheck_token_generation_failed、DeviceCheck registration failed (403) 或 attestation generation request timed out 时，问题出在 Apple 的设备校验这一环。报告来自 Apple Silicon 物理机，也来自 Mac 上的虚拟机，有人没开任何代理和 VPN 也一样（#52342 下 georgesamuelson，10 月 9 日）。

这一类目前没有用户报告过可靠的本机解法：

• 升级 macOS、重启电脑、退出再登录都无效（#52342，10 月 9 日）。
• 卸载重装 Codex 无效（#53333，10 月 12 日）。
• 内置更新到 26.1007.71326 后依旧（#52342 10 月 15 日的评论）。
• 有用户找了 Apple 客服，排查半小时后对方建议重装或降级系统，他最后选择等 Codex 出新版本（X 用户 @IFITALEX 的帖子，10 月 11 日）。

不建议为这个报错重装或降级 macOS。报告者的日志分析是：设备校验在旧版 Codex 上同样失败，只是不会挡住新聊天；从 26.1002.52244 开始，校验失败会直接让账号检查报错。问题出在应用怎么处理失败，重装系统未必能让 Apple 的校验恢复，代价却大得多。

更实际的做法是先用已有聊天、网页版或 CLI 干活，并把日志里的错误码补到 #52342（devicecheck_token_generation_failed）或 #53333（DeviceCheck registration failed (403)），让 OpenAI 看到受影响的范围。

这些办法被多位用户报告无效：Retry、重装、更新、改 config.toml

下面这些做法，报告里试过的人很多，见效的极少：

• 反复点 Retry。常见描述是"点了没用"，有人说点下去不到半秒就又失败了（#52790 下的评论，10 月 12 日）。
• 重装或在 Windows 里"修复"应用。#52437 重装重启后报错仍在，#53384 用了 Windows 的应用修复也不行。
• 更新到最新版。内置更新显示已是最新，问题依旧（#51917、#53609）。
• 切代理模式、换系统代理和 TUN。见上一节。
• 改 config.toml、清本地缓存。出现这个报错时，codex doctor 显示本地配置和认证都正常（#52437），失败的是服务端请求。改配置文件对应的是「无法加载组织设置」，用在这里不对路。

英文博客 SmartScope 截至 10 月 10 日把 GitHub 上的报告做了统计：点 Retry 10 人无效、1 人恢复；退出再登录 10 人无效、1 人暂时恢复；换代理或 VPN 7 人无效；重装或重置 4 人无效（SmartScope 的 Couldn't load workspace settings 汇总）。样本不大，但方向和后来的报告一致。

试完仍不行：换用已有聊天、网页版或 CLI，并在 GitHub 补日志

cloudflare_challenge 那几步各试一次，大约半小时内还不行；或者日志是 DeviceCheck 失败、不带 cloudflare_challenge 的 403 或 401，就别再反复重启了。这些入口在报告里基本不受影响：

• 已有的桌面聊天。能继续发消息、执行任务，可以在原来的聊天里接着干新活。
• 新建时选中项目。对一部分 Windows 用户有用，见上文。
• chatgpt.com 网页版。同一账号在浏览器里能正常新建聊天。
• Codex CLI。报告者普遍说 CLI 正常。还没装的话看 Codex CLI 安装与配置：Windows、macOS、Linux 一次跑通；想在 CLI 和桌面端之间来回用，可以参考 Codex Windows 应用变慢？先做 CLI 与桌面端路径检查。

降级到旧版本只有一例成功：Windows 上从商店包 26.1002.7124.0 退回 26.928.2636.0（应用版本 26.928.21956）后，能新建聊天并发出消息，但日志里的 403 依旧（#51917 下 CaT-Hode，10 月 9 日）。这不是官方给的办法，旧版可能带着已经修掉的其他问题，还会被自动更新覆盖回去，随时可能失效。

在 GitHub 补信息比在应用里反馈更可行：同一批故障里，应用内反馈会报「未能验证反馈权限」，/feedback 命令也提交不了（#52746、#53384）。Windows 的 cloudflare_challenge 报告集中在 #51917，macOS DeviceCheck 集中在 #52342。补充时写上：

• 「关于」里的应用版本和系统版本；
• 是否开代理、什么模式；
• 日志里的 routePattern、status、errorCode 几个字段和时间；
• 上面哪些做法试过、结果如何。

贴之前删掉账号 ID、邮箱、IP 和本地路径。

无法加载组织设置怎么办：改名 .codex、查 config.toml

「无法加载组织设置」是启动时的弹窗，2026 年 9 月 26 日起（26.924.x）在 Windows 上多见，Linux 也有报告。据中文用户贴出的内容，弹窗正文是"应用已暂停，等待安全加载组织设置后才能恢复。网络连接、代理或防火墙可能导致无法访问"。这一类与本地文件关系更大，有用户确认有效的做法：

1. 把整个 .codex 目录改名。退出应用，把 %USERPROFILE%\.codex 改名为 .codex.backup，再打开应用重新登录（#49663、#49023）。应用会重建本地状态，旧对话还在备份目录里，所以是改名而不是删除。
2. 检查 config.toml 是不是坏了。有用户查出弹窗的原因是 %USERPROFILE%\.codex\config.toml 损坏：文件有 5,702 字节，每个字节都是 0x00（#49663 下 gagophysicist，10 月 1 日）。你的 config.toml 如果打开后不是正常的配置内容，先把它备份移走再启动应用。
3. 关掉腾讯电脑管家的文件系统防护。路径是「腾讯电脑管家 → 安全配置 → 文件安全 → 文件系统防护」，关闭后 Codex 正常启动（#49663 下 xyzzhuyuxing-collab，10 月 6 日）。
4. 检查域名解析。有用户遇到这个弹窗时，desktop.chat.openai.com 的解析结果是 NXDOMAIN，而 chatgpt.com 解析正常（#49023，泰国）。

还有一种情况是应用崩溃后，本地状态库 state_5.sqlite 里的回填任务卡在 running，应用后台 30 秒超时（#52836）。修复要直接改 SQLite 数据库，属于高级操作，先备份再照 issue 里的步骤做。

关于无法加载工作空间设置的几个疑问

同时出现「无法检查锁定模式」，是账号被锁了吗？

不代表账号被锁。同一批故障里还会出现「无法检查锁定模式」(Couldn't check Lockdown mode)、Cloud 模式下的「Unable to load ChatGPT models」、Dots 的「未能加载您的 dot」，都是同类请求失败的连带表现。#52342 的报告者明确说，看到这个提示既不能说明开启了锁定模式，也不能说明账号被锁定；同账号在网页版正常就是旁证。

换节点、重新登录能解决无法加载工作空间设置吗？

有时能，多数时候不能。换节点在 #53035（10 月 14 日）和 linux.do 上有人成功，在 #52790、#53384 等报告里无效；重新登录在 #52790 里能暂时恢复但会复发。只对日志是 cloudflare_challenge 的情况值得试，DeviceCheck 失败换节点没有意义。

Codex 的无法加载工作空间设置什么时候能修好？

截至 2026 年 10 月 15 日，OpenAI 没有公布原因或修复时间，相关 GitHub issue 下也没有官方回复。10 月 14 日的 26.1007.71326 仍有报告。有新版本时先看 #51917、#52342 里有没有人确认修好，再决定要不要回到桌面版新建聊天。