Codex account/read failed during TUI bootstrap：修法看后半句

敲 codex，终端界面还没画出来就退回提示符，只留下一行：

Error: account/read failed during TUI bootstrap: account/read failed: workspace routing discovery failed (code -32603)

workspace routing discovery failed 那个位置也可能是 timed out、unauthorized (401)、failed to load workspace requirements、duplicate workspace in routing discovery，或者结尾换成 (code -32600) 的 plan type is required for chatgpt authentication。这一行从 2026 年 4 月到 10 月对应过好几种原因，前半句却一直没变：它只说"TUI 启动时发出的 account/read 请求失败了"。-32603 是 JSON-RPC 的通用内部错误码，-32600 是"无效请求"，两个都不是 HTTP 状态码，也不指向任何具体原因。真正有信息量的是第二个 account/read failed: 之后、(code …) 之前的那半句，下文叫它后半句。

来源先交代清楚。机制部分来自 Codex 源码（codex-rs 仓库里的 workspace_routing.rs 与 app_server_session.rs，截至 2026 年 10 月 17 日的 main 分支）和 OpenAI 的官方文档；修法全部来自 GitHub openai/codex 仓库和 OpenAI 开发者社区里带日期的用户报告，每条都标了出处。本机实际执行过的只有 0.163.0-alpha 上 codex login status、codex doctor --summary --no-color、codex app-server daemon version 三条只读命令，用来确认输出长什么样；这个报错没有在本机复现，下面任何一条修法也没有被验证过。截至 2026 年 10 月 17 日，OpenAI 没有给出官方原因或修复说明，最新稳定版 0.163.0 上仍有新报告。

按后半句，处理方向分五类：

• timed out 和 discovery failed：多数报告指向 0.157.0 起默认开启的共享后台服务，它状态陈旧、版本落后于 CLI，或继承了旧的代理环境变量。先 codex app-server daemon restart，再用 codex --no-daemon 验证是不是只有走后台服务才失败。
• failed to load workspace requirements：有报告底下其实是被撤销的 ChatGPT 令牌，重新登录后还得把仍拿着旧令牌的进程杀掉。这是目前答得最不圆满的一类，0.163.0 上仍在复现。
• unauthorized (401)：令牌在账号侧已失效，在持有凭证的那台机器上重新登录。
• duplicate workspace 和 selected workspace missing：账号侧的工作空间列表有问题，前者目前没有用户侧修法。
• plan type is required … (code -32600)：ChatGPT 模式的凭证里没有套餐信息，多见于第三方签发或和 API Key 混在一起的凭证，codex logout 后二选一重新登录。

这行报错在说什么：前半句固定，后半句才有信息

Codex 的交互界面（TUI）启动时要向一个叫 app-server 的进程发几个 JSON-RPC 请求，account/read 是其中一步，用来取当前账号信息。请求出错时，TUI 把它包成 account/read failed during TUI bootstrap: …，里面的 JSON-RPC 错误再渲染成 account/read failed: 后半句 (code N)，于是就有了这行两段式的报错。同一个包装也用在 model/list、configRequirements/read、thread/start、thread/fork 上，所以 thread/start failed during TUI bootstrap 是启动序列里另一步出的错，各有各的 issue，不能套用下面的分类。

用 ChatGPT 账号登录时，account/read 会让 app-server 做一件事：解析"工作空间路由"（workspace routing）。这里的工作空间指你用 ChatGPT 账号登录时选的那个空间，不是项目目录。路由发现（discovery）要向 chatgpt.com 后端的 accounts/check 发请求，再拉一份云端的"工作空间要求"配置包。整个读取包在 15 秒的超时里，超时就返回 workspace routing discovery timed out；现场记录与此吻合，桌面版日志里是 durationMs=15002 errorCode=-32603 method=account/read，WSL2 的记录是 15.016 秒。路由类错误一律映射成 JSON-RPC 的 internal error，也就是 -32603；账号状态本身无效才是 invalid request，-32600。所以 -32603 只告诉你"路由那一步没过"，具体是网络、令牌还是账号列表，要看后半句。

还有一个要先认识的对象：共享后台服务。自 2026 年 9 月 25 日发布的 0.157.0 起，交互式 codex 默认会启动一个常驻的 codex app-server --managed-daemon 进程，官方界面文案叫 shared background server，命令里叫 app-server daemon，下文统一叫后台服务。它还带一个更新器，会把整套运行包复制到 ~/.codex/packages/app-server-daemon/releases/ 下并从那份副本运行，所以正在跑的后台服务版本可以和你刚装的 CLI 不一样；它还会保留启动它那个会话的环境变量，包括代理设置。这些行为在 openai/codex issue #48195（要求把 daemon_auto_start 改成默认关闭）里有逐条描述（2026 年 9 月 25 日，19 条评论，没有官方回复）。真正去连 chatgpt.com 做路由发现的是这个后台服务进程，TUI 只是把请求发给它，这就是为什么后面很多修法都围着它转。

两个看起来自相矛盾的现象也能解释了。codex login status 显示 Logged in using ChatGPT，是因为它只读本地存着的凭证，官方身份验证页对它的描述就是"查看当前的身份验证方式"；令牌在服务端被撤销或拒绝时，它照样显示已登录。codex exec "…" 能跑，是因为 exec 不经过 TUI 这段启动序列；它能跑只说明凭证和模型请求本身没坏，不能反过来证明 account/read 会成功，账号里出现重复工作空间时 exec 也会失败。

截至 2026 年 10 月 17 日，Codex 官方文档的身份验证页、配置参考和开发者命令页都没有出现 "workspace routing"、account/read 或 "TUI bootstrap" 这几个词，所以下面能引官方的地方只有命令和配置项本身。

先跑三条检查：登录状态、后台服务版本、doctor 汇总

动手之前先跑三条不改任何东西的命令，它们决定你该跳到哪一节：

codex login status
codex app-server daemon version
codex doctor --summary --no-color

JSON 的实际样子来自 openai/codex issue #52928 里 bboygun 2026 年 10 月 15 日的评论：{"status":"running","backend":"pid","managedCodexVersion":"0.162.1","cliVersion":"0.162.1","appServerVersion":"0.162.1"}。socket 不存在的那条报错和 doctor 的分组行是本机 0.163.0-alpha.10.2 的原样输出，当时没有后台服务在跑。codex app-server daemon 下的 start、restart、update、stop、version 等子命令来自 CLI 自带的 --help；官方开发者命令页记录了 --no-daemon、codex doctor、codex login status、codex logout 和 TUI 内的 /daemon，但没有记录这组子命令。

codex doctor 覆盖安装、配置、身份验证、运行时、Git、终端、app-server 和线程清单。要注意的是它全绿也挡不住这个报错：重复工作空间那条 issue 里，一位用户贴出的 doctor 输出 auth is configured、websocket connected (HTTP 101 Switching Protocols) 全部正常，codex 照样起不来。doctor 回答的是"本机环境有没有问题"，不是"账号侧和路由发现过不过"。

后半句对照表：每种写法指向什么、先做什么

timed out 与 discovery failed：先重启后台服务，再试 --no-daemon

这两种后半句的报告最多，有效的办法也最集中。

重启后台服务。命令是 codex app-server daemon restart。据 OpenAI 开发者社区帖"Codex CLI 0.162.0 fails during TUI bootstrap"（2026 年 10 月 9 日，Linux Mint，ChatGPT 登录，本地代理），作者自己给出并被标为接受答案的解法就是这一条，"没有删除配置、凭证或对话历史"；他同时注明重启"可能打断正在进行的 Codex 会话"，并且说不清起作用的是后台服务版本旧（CLI 0.162.0，后台 0.161.0）还是它拿着过期的代理设置。issue #52928 里 bboygun 10 月 15 日的情形更干净：0.162.1，HTTP 代理，CLI 和后台服务版本一致，用 curl 打 https://chatgpt.com/backend-api/wham/accounts/check 0.46 秒返回 401（未带凭证时的正常结果），说明网络没问题，codex --no-daemon 正常，重启后台服务后 codex 恢复；他的猜测是"陈旧的 daemon 状态、继承的代理环境变量或连接状态"。issue #17800 里 mlms13（10 月 11 日）和 itsmistermoon（10 月 15 日）也报告重启后恢复。更早的做法是直接杀进程：openai/codex issue #48894 里 Humorhunter 2026 年 9 月 29 日的评论给的是 pkill -f codex，然后 codex login status 确认还在登录，再 codex，10 月 5 日和 6 日各有一人回复有效。Windows 上没有 pkill，哪些 Codex 进程该结束、哪些该留，见Codex Windows 后台进程怎么处理：哪些该保留，哪些可以结束。

0.163.0 给 TUI 里的 /daemon 加了确认后重启本地后台服务的动作（PR #53173），确认框会提示其他聊天里进行中或排队的工作可能被中断；官方文档对 /daemon 的说明是"打开后台服务控制"，并提醒确认更新会退出 Codex、可能打断正在进行的工作。但它要先进得了 TUI 才能用，对这个报错只能靠命令行那条。

对齐版本。上一步检查里 cliVersion 和 appServerVersion 不一致时，直接把后台服务换成当前 CLI 这份：

codex app-server daemon update --from-cli --yes

--from-cli 的帮助文字是"复制并固定这份 CLI 包"，update 本身标注"可能打断正在运行的工作"。issue #52928 里 ziheng5（10 月 15 日，Arch Linux）的 CLI 是 0.162.1、后台服务是 0.160.0，跑完这条后两边都到 0.162.1，codex 直接起来了。openai/codex issue #52775（macOS 升到 0.162.1 后启动失败）里附的 doctor JSON 也是 "app-server version": "0.161.0" 配 codexVersion 0.162.1。版本会错位是前面说的机制决定的：npm install -g @openai/codex@latest 换的是 CLI，正在跑的后台服务用的还是 ~/.codex/packages/ 下那份旧副本，直到重启或更新。配置项 tui.show_server_version_notice 默认开着，会在能进 TUI 时提示连接的 app-server 版本和 CLI 不同。

用 --no-daemon 验证。codex --no-daemon 的说明是"不使用共享后台服务运行，即使它已在运行"。它不是修复，是分流：同一个 shell、同样的代理、登录和配置，codex 失败而 codex --no-daemon 成功，就说明问题出在走后台服务的那条路上。issue #52928 的发起人 Baifeng76（10 月 10 日，Ubuntu 22.04 的 Docker 容器，0.156.1 和 0.162.1 都复现）给的时间很有用：默认启动 1.630 秒就报 discovery failed，"和耗尽 15 秒超时不符"，而 --no-daemon 直接可用。反过来，--no-daemon 也失败，就不是后台服务的事，重复工作空间那条 issue 里 Koninec（9 月 23 日）用 --no-daemon 得到一模一样的报错。内嵌模式的代价是 codex agents 和远程控制这类依赖共享服务的功能不可用，官方文档也写明它不能和 --remote 同用。

为什么 -c log_dir=… 也"有效"。从 9 月下旬起有一串报告说加 -c log_dir="$HOME/.codex/log" 就能启动：openai/codex issue #48600（Windows 与 WSL，0.157.1），issue #52775（macOS，0.162.1），以及 LanternCX 10 月 14 日的同样反馈，他的后半句是 failed to load workspace requirements。Baifeng76 在 #52928 里找到了解释：带 -c、--enable、--disable 或 --search 启动时，CLI 会打印 "Running without the shared background server: command-line configuration overrides (-c, --enable, --disable, or --search) requires embedded mode."，也就是任何命令行覆盖都会强制内嵌模式。所以 -c model_reasoning_effort="medium" 一样能进，而把 log_dir 写进 config.toml 顶层却没用。log_dir 不是原因，这些报告其实都是 --no-daemon 的变体。另有 Zefrain 10 月 15 日一条单独报告说只 touch ~/.codex/log/codex-tui.log 就能让 codex 启动，没有人解释过为什么，也没有第二个人确认。

干脆关掉自动启动。codex features disable daemon_auto_start（来自 codex features --help，写进 config.toml），或手写：

[features]
daemon_auto_start = false

issue #48195 里 tagorr（9 月 25 日，Windows 10 LTSC，0.157.0）用这一行解决了他的启动阻塞。截至 10 月 17 日，daemon_auto_start 不在官方配置参考里，这是从 CLI 帮助和用户报告得来的做法，代价和 --no-daemon 相同。

后台服务跑久了的另一类故障。openai/codex issue #37971（启动时报没有可用的文件描述符）里报错的是 configRequirements/read failed during TUI bootstrap，原因是跑了 8 天的后台服务把 1,024 个文件描述符用掉了 1,022 个。方法名不同，但同属"后台服务状态陈旧"这一类，重启即清；0.162.0 把托管后台服务的软上限提到了 4,096。

代理和公司网络：后台服务只认启动它那一刻的环境变量

这一节的几条报告都和代理、网络有关，带代理跑 Codex 的先看这里。

后台服务保留的是启动它那个会话的环境变量（issue #48195 的描述）。你后来在另一个终端改了代理端口、换了节点、或者干脆关了代理，正在跑的后台服务并不知道。按这个行为推，改完代理之后的顺序应该是：停掉旧的后台服务，在带着正确变量的 shell 里再启动 codex，让新的后台服务继承新环境。

codex app-server daemon stop
HTTP_PROXY=$PROXY_URL HTTPS_PROXY=$PROXY_URL codex

把 $PROXY_URL 换成你代理监听的地址。桌面版用户做过同一件事：openai/codex issue #49921（macOS 桌面版不显式设 HTTP_PROXY 就超时）（2026 年 10 月 1 日，桌面版 26.921）里，account/read 稳定耗时 15 秒后失败，/wham/usage、/wham/tasks/list、/settings/user 返回 HTTP 432 "Workspace routing is unavailable"；给 Electron 加 --proxy-server= 参数没用，带着 HTTP_PROXY、HTTPS_PROXY、NO_PROXY 环境变量从命令行启动应用就正常。CLI 侧，issue #52928 里 wenzhaoabc（10 月 12 日）在 ~/.codex/ 下放了一个 .env 文件，写入 http_proxy、https_proxy 和 no_proxy，重启 Codex 后恢复。这是单人报告，官方文档没有记载 .env 会被读取，但成本低，可以试。

http_proxy="http://PROXY_HOST:PROXY_PORT"
https_proxy="http://PROXY_HOST:PROXY_PORT"

两个容易踩的坑来自报告本身。一是端口填错：社区帖 1404666 的作者发现代理返回 407 Proxy Authentication Required，原因是把 SOCKS 端口 10808 当成 HTTP 代理端口填进了环境变量，而 HTTP 端口其实是 10809；改对端口后 407 消失，但 Codex 还得重启后台服务才恢复。二是分流规则没放行 chatgpt.com：openai/codex issue #50211 里 kubilen 2026 年 10 月 16 日的评论说公司网络封了 chatgpt.com 却没封 *.openai.com，于是登录能成功，之后的一切都失败。路由发现打的是 chatgpt.com/backend-api/wham/accounts/check，分流规则只写 openai.com 不够。同一条 issue 里 khughitt（10 月 11 日，Linux，0.162.1）的补充值得知道：网络抖动时 TUI 会先正常显示、接受输入，然后才突然退出并丢掉你已经敲的内容。

0.163.0 的一项改动和这里相关：PR #52702 让启动阶段的 accounts/check 和 config/bundle 请求在请求出错时经系统代理重试（前提是启用了回退），但 HTTP 401、403、407、429、503 这些响应不触发回退。也就是说，代理配置本身错了（407）不会被它救回来。企业 TLS 拦截的情形，官方文档给的是 CODEX_CA_CERTIFICATE 指向 PEM 证书包，未设时回退到 SSL_CERT_FILE；HTTP_PROXY、HTTPS_PROXY 不在官方环境变量页上。

WSL2 单独说一句。openai/codex issue #51052（WSL2 下 account/read 15 秒超时，Windows 成功）（10 月 5 日，0.160.0）用同一个账号对照：Windows 侧 account/read 0.422 秒成功，WSL2 侧 15.016 秒超时，codex exec 两边都能跑；报告者自己也说超时信息不能定位是哪一段卡住。另外 0.162.0 起，家目录挂在 Windows 盘上的 WSL（DrvFS/9p）会跳过后台服务自动启动，带着警告以内嵌模式运行，这类环境里重启后台服务不是你的杠杆，重点查 WSL 侧的网络和代理变量。

failed to load workspace requirements：先查令牌，再杀旧进程

这句的字面意思是云端那份"工作空间要求"配置包没拉下来。当前 main 分支的代码会在后面附上原因，形式有 cloud config: authentication failed (HTTP 401)、cloud config: request timed out、cloud config: request failed、cloud config: invalid bundle，或 invalid configuration at 路径:行:列；但 0.162.1 和 0.163.0 的报告里（issue #54184 10 月 15 日、issue #52928 10 月 14 日的评论、社区帖 1407111 10 月 17 日）打印的都是光秃秃的 failed to load workspace requirements (code -32603)。已发布版本上你看不到原因，只能靠下面两条报告排查。

openai/codex issue #54184（真正的错误是 401 token_revoked）（10 月 15 日，0.162.1，macOS arm64，ChatGPT 登录）给了唯一一个查到底的样本：每个后端请求都返回 401 token_revoked（"Encountered invalidated oauth token for user"），包括拉配置包那一次，TUI 却只报了通用的 -32603。报告者的关键发现是，重新 codex login 之后，还在跑的 TUI 和后台服务继续使用那个已被撤销的令牌，直到被杀掉。所以这条的顺序是：

codex logout
codex login
codex app-server daemon restart
codex

没有后台服务在跑的话，把第三步换成结束所有残留的 codex 进程。

另一条报告说明这类还没有收口。OpenAI 开发者社区帖"Codex CLI TUI fails during account/read workspace requirements bootstrap"发于 2026 年 10 月 17 日：codex-cli 0.163.0，macOS，Node 22，ChatGPT Plus；在任何目录执行 codex 都立刻报这句，codex login status 显示 Logged in using ChatGPT，退出再登录无效，从 0.162.1 升到 0.163.0 无效，codex exec "Reply only with READY" 正常返回 READY。帖子发出时零回复。X 上也有用户 10 月 13 日拿着 0.162.1 上的这句直接问 Codex 负责人"什么时候修"，未见回复。

如果重新登录加杀进程之后还是这句，剩下能做的只有上一节的办法：codex app-server daemon restart，以及用 --no-daemon 验证。LanternCX 10 月 14 日带着这句后半句用 -c log_dir 进去了，也就是内嵌模式对部分 requirements 失败同样有效。再往下就没有可引用的报告了。

unauthorized (401)：在持有凭证的那台机器上重新登录

后端在路由发现这一步直接拒绝了令牌。codex login status 仍显示已登录，因为它只看本地文件。

openai/codex issue #47456（远程主机保留失效的 ChatGPT 登录态，login status 仍显示已登录）（2026 年 9 月 23 日）描述的场景是 macOS 桌面版通过 SSH 连一台无界面的 Linux 主机，凭证存在远程主机的 ~/.codex/auth.json 里。账号刚获得新的权限之后，远程侧开始返回 workspace routing discovery unauthorized (401)；在远程主机上重新执行 codex login --device-auth 立刻恢复。报告者把权限变动称为"可能的触发条件而非确认的根因"。桌面版这时弹的是另一句不相干的提示 "Your access token could not be refreshed because your refresh token was revoked"，而真正过期的凭证在远程那边，所以要在凭证实际所在的机器上重登。服务器上怎么用设备码登录、什么时候该拷 auth.json，见Codex 服务器无浏览器登录：设备码、SSH 转发、auth.json 怎么选。

同一条 issue 下 2aeyes8472-ux（10 月 1 日）补了另一半：套餐变动后 --device-auth 登录成功，401 却还在，原因是一个长期运行的 codex app-server 进程仍持有旧令牌，日志里一直是 token_revoked；pkill -f 'codex app-server' 后再 codex 就正常了，~/.codex 下没删任何文件。这和上一节 issue #54184 的观察一致：重新登录只换了磁盘上的凭证，内存里的旧令牌要靠结束进程。Reddit 上也有人报告过这句后半句，细节无法核对，只能说"也有人遇到"。

duplicate workspace：账号侧有两个同名工作空间，暂无用户侧修法

openai/codex issue #47034（登录成功后报 duplicate workspace in routing discovery）2026 年 9 月 21 日开出，截至 10 月 17 日仍未关闭，9 条评论覆盖 Windows 和 macOS、CLI 0.155 到 0.160、桌面版 26.924。它和前面几类的区别在于问题不在本机：mallejsan-pixel（10 月 3 日）在 ChatGPT 手机应用里看到自己的账号下有两个一样的 "Personal account / Personal"；Sanchit-Koul（10 月 4 日）在网页登录时的工作空间选择器里同样看到两个 "Personal account"，"我没有创建第二个工作空间"。路由发现拿到两条一样的条目，就返回了这句。

评论区列出的无效尝试很完整：codex logout 再 codex login、codex login --device-auth、全新的 CODEX_HOME、设置 forced_chatgpt_workspace_id、重装、codex --no-daemon，全部得到同一句报错；codex exec 也失败，表现为 "Reconnecting… 2/5" 一路到 5/5。能用的只有 VS Code 的 Codex 扩展（10 月 4 日仍可用）。Koninec（9 月 23 日）降到 0.154.0 后能用，Sanchit-Koul（10 月 4 日）降到同一版本没用。几位用户都开了支持工单，线程里没有官方回复。如果你的后半句是这句，先去 ChatGPT 网页或手机端的工作空间切换处看一眼是不是真有两个重复条目，是的话本机能做的就只剩开工单。

selected workspace missing from routing discovery 只在代码的错误枚举里有，没有可读的公开报告。按字面推断，它指保存的工作空间选择已不在账号当前的列表里，对应动作是重新登录并重选工作空间；config.toml 里设了 forced_chatgpt_workspace_id（官方配置参考："将 ChatGPT 登录限制在某个工作空间 ID"）的，核对这个 ID 还属于你的账号。官方身份验证页另有一句相关说明：当前凭证不符合配置限制时，Codex 会把用户登出并退出。这一段是推断，不是报告。

plan type is required：凭证里缺套餐信息，退出后二选一重新登录

这句的结尾是 (code -32600)，不是 -32603。它来自 provider.rs 里的 MissingChatgptAccountDetails：ChatGPT 模式的凭证里，令牌必须带 plan_type，email 可以没有，plan_type 不行；缺了就按"账号状态无效"返回 invalid request。也就是说这不是路由发现失败，而是凭证本身不完整。

哪种凭证会缺这个字段，代码没说，中文论坛里的场景给了方向。linux.do 上 2026 年 10 月 3 日有一帖直接以这句为题，同帖还引了 "'gpt-5.4' model is not supported when using Codex with a ChatGPT account"；更早的 2026 年 4 月 7 日 linux.do 帖"codex从公益站换回官方报错解决方法"记的是从公益站（免费中转）切回官方账号后 codex 直接报 account/read failed during TUI bootstrap；CSDN 2026 年 7 月 7 日的"本地Codex 接口登录报错account/read failed 的排查与修复记录"把原因归为登录方式混用，走的是退出当前登录状态、设置 API Key、codex login --with-api-key、codex login status 看到 Logged in using an API key、再启动。从代码路径和这些场景看，最可能的是第三方签发的、或手工拼进 auth.json 的 ChatGPT 模式令牌，它们没有 OpenAI 官方令牌里的套餐字段。这是推断，不是官方说明。

处理方式是把凭证收拾干净，二选一：

codex logout
# 要么官方 ChatGPT 登录
codex login
# 要么 API Key 登录
printenv OPENAI_API_KEY | codex login --with-api-key

codex logout 的官方描述是"清除当前凭证"，没有参数。用 API Key 登录后路由发现根本不会执行，源码测试 api_only_login_does_not_discover_chatgpt_routing 的预期就是零次 accounts/check 请求；0.163.0 起（PR #52635），没有 ChatGPT 登录时 app-server 启动和连接初始化阶段的后台路由读取也会跳过。代价是官方文档写明的那条：API Key 走标准 API 计费，不用 ChatGPT 套餐里的额度，两种方式怎么选见Codex API Key 和 ChatGPT 订阅怎么选？额度与 credits 按美元算。

自定义 provider 的用户还要检查一个配置项。官方文档：requires_openai_auth = true 表示"该 provider 使用 OpenAI 身份验证"，此时 Codex 忽略 env_key。issue #17800 里 xpfo-go（2026 年 4 月 27 日）定位到的就是这一点：给 OpenAI 兼容端点写了 env_key，又顺手加了 requires_openai_auth = true，TUI 启动时就会去读 Codex 存着的 ChatGPT 登录态而不是你的 key，那份登录态过期或不完整就报这行。处理是删掉或改成 false：

[model_providers.my-provider]
base_url = "..."
wire_api = "responses"
env_key = "MY_PROVIDER_API_KEY"
# 不要同时写 requires_openai_auth = true

[model_providers]、env_key、base_url 各写什么，见Codex 自定义 API 配置：Key、Base URL 与 Provider 怎么选。

顺带把 4 月那种没有后半句的旧写法说完。issue #17800（2026 年 4 月 14 日，0.120.0，API Key 用户）的原始修法是退出再登录；5 月 14 日 949869228 给的是 rm ~/.codex/auth.json 再重新认证，比删整个 ~/.codex 好，后者会把全部会话记录一起删掉（RayneYael 5 月 9 日）。但到了 10 月的版本上，mlms13（10 月 11 日）删 auth.json 加重新登录已经不够，起作用的是 codex app-server daemon restart。所以"删 auth.json"是 4 月那类原因的修法，不是现在的默认动作。

不删会话历史的处理顺序：检查、重启、验证、重登、代理、配置

~/.codex 下放着配置、凭证、日志和会话记录（官方对 CODEX_HOME 的描述），下面的顺序不会碰会话记录：

1. 跑三条检查，确认登录方式、后台服务在不在、版本有没有错位。什么都不改。
2. 后台服务在跑，先 codex app-server daemon restart；版本错位则 codex app-server daemon update --from-cli --yes。两条都可能打断其他窗口里正在跑的 Codex，先把别处的活收尾。
3. 还不行，codex --no-daemon。能进，说明问题在共享后台服务那条路上，可以先这样用，或关掉 daemon_auto_start；不能进，往下。
4. 重新登录：codex logout，codex login（服务器上用 --device-auth），然后结束所有残留的 codex 进程，再 codex。只动登录态。
5. 带代理的，核对端口和放行规则（要包含 chatgpt.com），停掉后台服务，在带正确变量的 shell 里重新启动。
6. 用自定义 provider 的，检查 requires_openai_auth 和 env_key 没有同时生效。
7. 后半句是 duplicate workspace，或在 0.163.0 上重新登录加重启之后仍是 failed to load workspace requirements，目前没有可引用的用户侧修法，去对应 issue 和社区帖留下你的版本和平台，比继续折腾本机更有用。

不建议的动作只有一个：rm -rf ~/.codex。它在 4 月确实解决过问题，代价是会话记录全没，而 10 月的报告显示删凭证并不是现在起作用的那一步。

0.163.0 修了吗：三项相关改动，没有一条是修复声明

按 GitHub 发布页整理的时间线：

• 0.157.0（2026 年 9 月 25 日）：后台服务默认自动启动（#47179）；"为不兼容的后台服务提供显式恢复"（#47318）。这个版本之后 timed out 和 discovery failed 的报告开始集中。
• 0.160.0（10 月 1 日）、0.161.0（10 月 7 日）：后台服务诊断信息写进报告（#49843）。
• 0.162.0（10 月 8 日）：Windows 盘上的 WSL 家目录不再自动启动后台服务（#50555）；托管后台服务的文件描述符上限提到 4,096（#51470）；"区分 daemon 发布身份与可执行文件内容"（#50559）。0.162.1 在 10 月 9 日。
• 0.163.0（10 月 15 日，当前稳定版）：TUI 内 /daemon 可重启后台服务（#53173）；启动阶段的 GET 请求在请求出错时经系统代理重试（#52702）；没有 ChatGPT 登录时跳过后台路由读取（#52635）；"把 daemon 功能兼容性检查限制在显式 CLI 覆盖上"（#52648）。
• 0.164.0-alpha.1 到 alpha.3（10 月 16 日至 17 日）：发布说明为空。

三项 0.163.0 的改动都挨着这个报错，但没有一条写着修复 workspace routing discovery failed 或 timed out，而 10 月 17 日的社区帖就是 0.163.0 上的 failed to load workspace requirements。所以升级值得做，它至少把 /daemon 和代理重试带了进来，但不要把升级当成修法。升级和重装的具体命令见Codex CLI 安装与配置：Windows、macOS、Linux 一次跑通。下一个值得回头看的节点是 0.164 的稳定版。

桌面版和 VS Code 扩展的 workspace routing discovery timed out

同一个 15 秒的路由发现也跑在 ChatGPT 桌面版和 VS Code 扩展里，只是报错换成了登录框上的 "Sign-in failed: workspace routing discovery timed out" 或 "Login failed: …"，典型表现是每天都要重新登录。报告散在几条 issue 里：#48894（9 月 28 日，VS Code 扩展，Ubuntu，Pro）；openai/codex issue #49443（macOS 桌面版几乎每天要求重新登录）（9 月 30 日，26.924，日志里是 account/read failed: workspace routing discovery failed (error code -32603) 和 "Workspace routing is unavailable"）；#53236（10 月 12 日，Windows 26.1007，每日重登）和 #53520（10 月 13 日）；#50828（10 月 4 日，Windows 登录）。10 月 17 日还有日本用户在 X 上说桌面版突然取不到工作空间信息，向 OpenAI 反馈只收到 AI 回复。

被报告有效的做法同样是进程和环境那两类：#48894 的 pkill -f codex；#49921 带着 HTTP_PROXY、HTTPS_PROXY 启动桌面版；同一条 issue 里 HarmoniK-kang（10 月 15 日）发现退出 ChatGPT 应用后还有一个 Dock Extra (ChatGPT.app) 进程留着，杀掉它之后能登录了，他自己也说不清为什么。openai/codex issue #47145（Windows 上内置运行时导致超时）（9 月 22 日）给的取舍是让桌面版用外部 CLI（CODEX_CLI_PATH），登录能保持，但 ChatGPT Memory 不可用。

桌面版另一个带"工作空间"字样的报错是新聊天发不出的「无法加载工作空间设置」，那是 Cloudflare 403 或 macOS DeviceCheck 的问题，与路由发现无关，见Codex 无法加载工作空间设置：新聊天发不出，按日志分两类排查。VS Code 扩展等 30 秒后报 "could not start" 也是另一条线，见Codex could not start 报错：VS Code 插件按环境排查，哪些已修复。

容易混在一起的 Codex 报错：thread/start、403、提交消息时出错

• thread/start failed during TUI bootstrap、configRequirements/read failed during TUI bootstrap、thread/fork failed during TUI bootstrap：启动序列里的其他步骤，前半句的包装相同，原因各不相同，各有自己的 issue。configRequirements/read 那条在 #37971 里对应的是后台服务文件描述符耗尽，重启可解。
• codex login 这一步就失败、带 403：那是令牌交换被拒，见Codex 令牌交换失败 403 怎么解决？按错误后缀定位登录拒绝。
• TUI 已经进去，发消息时报 401 Incorrect API key provided：是模型请求的鉴权，常见于残留的第三方配置，见Codex 报 401 Incorrect API key provided：先看 URL 和 key 文本。
• 启动正常、提交时报错：看第二行，见Codex 提交消息时出错：原因在第二行，按报错原文逐类处理。

重启后台服务和重新登录前的几个疑问

重启后台服务会不会打断我其他窗口里正在跑的 Codex？

会有这个风险。社区帖 1404666 的作者在接受答案里专门注明"重启 daemon 可能打断正在进行的 Codex 会话"；codex app-server daemon update 的帮助文字写着"可能打断正在运行的工作"；0.163.0 给 /daemon 加重启功能的 PR #53173 也在确认框里提示其他聊天中进行或排队的工作可能被中断。先让别的窗口把当前一轮跑完再重启。

codex logout 之后，还在跑的 Codex 进程会怎样？

从两条报告看，它们会继续用内存里的旧令牌。issue #54184 的报告者重新登录后，仍在运行的 TUI 和后台服务一直拿着已撤销的令牌直到被杀掉；issue #47456 下的评论里，--device-auth 登录成功后 401 依旧，直到 pkill -f 'codex app-server'。所以退出再登录这一步要配上结束旧进程，否则等于没做。

要不要直接删掉 ~/.codex？

不要。CODEX_HOME（默认 ~/.codex）下放着配置、凭证、日志和会话记录，删掉它等于清空全部历史对话，issue #17800 里 5 月就有人指出这一点。只想重置登录态，用 codex logout；凭证存储模式是 file 时它对应的文件是 auth.json，模式是 keyring 时凭证在系统凭据库里，更应该走 codex logout 而不是删文件。而且 10 月的报告显示，重置登录态多数时候并不是起作用的那一步。

codex exec 能跑，为什么 TUI 进不去？

account/read 这一步是 TUI 启动序列里发的，codex exec 不走这段，所以它能跑只证明凭证和模型请求没问题。10 月 17 日 0.163.0 上的社区帖和 10 月 5 日 WSL2 那条 issue 都是这种组合。它也不是万能的对照：账号里有重复工作空间时 codex exec 同样失败，表现为反复 "Reconnecting"。

把后台服务关掉算修好了吗？

不算，这是绕开。--no-daemon、-c 覆盖、daemon_auto_start = false 都让 TUI 以内嵌模式运行，避开了共享后台服务那条路，失去的是 codex agents、远程控制这类依赖共享服务的功能。后台服务路径上为什么会失败，截至 2026 年 10 月 17 日没有官方说明，issue #52928 和 #48195 都还开着。