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

> Codex 启动秒退看后半句：discovery failed/timed out 先重启后台服务；401、requirements 多是令牌失效；plan type 是凭证混用。

- URL: https://blog.laozhang.ai/zh/posts/codex-account-read-failed-tui-bootstrap
- Published: 2026-10-17
- Updated: 2026-10-17
- Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about)
- Topic: 开发工具与智能体
- Tags: Codex, Codex CLI, 报错排查, workspace routing, 后台服务, ChatGPT 登录

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

```text
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 改成默认关闭）](https://github.com/openai/codex/issues/48195)里有逐条描述（2026 年 9 月 25 日，19 条评论，没有官方回复）。真正去连 chatgpt.com 做路由发现的是这个后台服务进程，TUI 只是把请求发给它，这就是为什么后面很多修法都围着它转。

![Codex TUI 把 account/read 发给共享后台服务，由它连 chatgpt.com 的 accounts/check 做路由发现；codex --no-daemon 走内嵌模式绕开后台服务，后台服务保留启动时的环境变量、版本可与 CLI 不同](https://blog.laozhang.ai/posts/zh/codex-account-read-failed-tui-bootstrap/img/daemon-routing-chain.webp)

两个看起来自相矛盾的现象也能解释了。`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 汇总

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

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

| 命令 | 输出 | 说明什么 |
| --- | --- | --- |
| `codex login status` | `Logged in using ChatGPT` | 走 ChatGPT 登录，路由发现会执行，后面各节都适用 |
| `codex login status` | `Logged in using an API key` | API Key 登录不做路由发现，这行报错多半来自自定义 provider 配置，直接看 `plan type is required` 那一节的 `requires_openai_auth` 部分 |
| `codex app-server daemon version` | 一段 JSON，含 `cliVersion`、`appServerVersion`、`managedCodexVersion` | 对比 `cliVersion` 与 `appServerVersion`，不一致就是版本错位 |
| `codex app-server daemon version` | `Error: failed to connect to ~/.codex/app-server-control/app-server-control.sock`，下面一行 `No such file or directory (os error 2)` | 此刻没有后台服务在跑，重启它不是你的杠杆，先看代理、令牌和账号侧的几节 |
| `codex doctor --summary --no-color` | 分组行，含 `websocket connected (HTTP 101 Switching Protocols) · 15s timeout`、`Background Server ○ app-server not running (ephemeral mode)` 或显示 running | 看后台服务在不在、WebSocket 通不通；去掉 `--summary` 的详细报告里有 app-server 的版本号 |

JSON 的实际样子来自 [openai/codex issue #52928 里 bboygun 2026 年 10 月 15 日的评论](https://github.com/openai/codex/issues/52928)：`{"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 回答的是"本机环境有没有问题"，不是"账号侧和路由发现过不过"。

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

| 后半句原文 | 代码里的含义 | 报告里的常见原因 | 先做什么 |
| --- | --- | --- | --- |
| `workspace routing discovery timed out` | 15 秒内没完成路由发现 | 后台服务状态陈旧或版本错位；代理只对启动它的那个会话生效；WSL2；网络不稳 | `codex app-server daemon restart`，再用 `--no-daemon` 验证 |
| `workspace routing discovery failed` | 路由发现请求失败，不是超时，有报告 1.63 秒就返回 | 同上；代理端口填错返回 407；公司网络封了 chatgpt.com | 同上，另查代理端口和放行规则 |
| `failed to load workspace requirements` | 云端的工作空间要求配置包没拉下来；0.162.1 与 0.163.0 不打印原因 | 有报告底下是 401 token_revoked | 重新登录，然后杀掉仍持旧令牌的进程；0.163.0 仍有复现 |
| `workspace routing discovery unauthorized (401)` | 后端拒绝了这个令牌 | 账号权限或套餐变动后旧凭证失效；远程主机上的旧 auth.json | 在持有凭证的那台机器上重新登录，再结束旧的 app-server 进程 |
| `duplicate workspace in routing discovery` | 账号的工作空间列表里出现两个一样的条目 | 账号侧数据，ChatGPT 网页和手机端也能看到两个 Personal | 用户侧没有有效修法，开支持工单；VS Code 扩展仍可用 |
| `selected workspace missing from routing discovery` | 保存的工作空间选择不在账号当前列表里 | 没有公开报告可读，只有代码枚举 | 重新登录并重选工作空间；设了 `forced_chatgpt_workspace_id` 的核对它。此条是推断 |
| `plan type is required for chatgpt authentication (code -32600)` | ChatGPT 模式凭证的令牌里没有 `plan_type` | 第三方签发或混用的凭证 | `codex logout`，然后官方 ChatGPT 登录或 API Key 登录，二选一 |
| 没有后半句（2026 年 4 月的旧写法） | 0.120 时代，内层错误不显示 | 自定义 provider 写了 `requires_openai_auth = true`，又留着过期的 ChatGPT 登录态 | 把它改成 false 或删掉；或 `codex logout` 后重新登录 |

![按后半句分流：timed out 与 discovery failed 先重启后台服务，failed to load workspace requirements 重新登录再杀旧进程，unauthorized (401) 在持有凭证的机器上重登，duplicate workspace 开支持工单，plan type is required 则 codex logout 后二选一重新登录](https://blog.laozhang.ai/posts/zh/codex-account-read-failed-tui-bootstrap/img/suffix-triage-map.webp)

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

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

**重启后台服务**。命令是 `codex app-server daemon restart`。据 [OpenAI 开发者社区帖"Codex CLI 0.162.0 fails during TUI bootstrap"](https://community.openai.com/t/1404666)（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 日的评论](https://github.com/openai/codex/issues/48894)给的是 `pkill -f codex`，然后 `codex login status` 确认还在登录，再 `codex`，10 月 5 日和 6 日各有一人回复有效。Windows 上没有 `pkill`，哪些 Codex 进程该结束、哪些该留，见[Codex Windows 后台进程怎么处理：哪些该保留，哪些可以结束](https://blog.laozhang.ai/zh/posts/codex-windows-background-processes)。

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

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

```bash
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 后启动失败）](https://github.com/openai/codex/issues/52775)里附的 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）](https://github.com/openai/codex/issues/48600)，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`），或手写：

```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（启动时报没有可用的文件描述符）](https://github.com/openai/codex/issues/37971)里报错的是 `configRequirements/read failed during TUI bootstrap`，原因是跑了 8 天的后台服务把 1,024 个文件描述符用掉了 1,022 个。方法名不同，但同属"后台服务状态陈旧"这一类，重启即清；0.162.0 把托管后台服务的软上限提到了 4,096。

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

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

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

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

把 `$PROXY_URL` 换成你代理监听的地址。桌面版用户做过同一件事：[openai/codex issue #49921（macOS 桌面版不显式设 HTTP_PROXY 就超时）](https://github.com/openai/codex/issues/49921)（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` 会被读取，但成本低，可以试。

```ini
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 日的评论](https://github.com/openai/codex/issues/50211)说公司网络封了 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 成功）](https://github.com/openai/codex/issues/51052)（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）](https://github.com/openai/codex/issues/54184)（10 月 15 日，0.162.1，macOS arm64，ChatGPT 登录）给了唯一一个查到底的样本：每个后端请求都返回 `401 token_revoked`（"Encountered invalidated oauth token for user"），包括拉配置包那一次，TUI 却只报了通用的 -32603。报告者的关键发现是，重新 `codex login` 之后，还在跑的 TUI 和后台服务继续使用那个已被撤销的令牌，直到被杀掉。所以这条的顺序是：

```bash
codex logout
codex login
codex app-server daemon restart
codex
```

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

另一条报告说明这类还没有收口。[OpenAI 开发者社区帖"Codex CLI TUI fails during account/read workspace requirements bootstrap"](https://community.openai.com/t/1407111)发于 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 仍显示已登录）](https://github.com/openai/codex/issues/47456)（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 怎么选](https://blog.laozhang.ai/zh/posts/codex-headless-login)。

同一条 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）](https://github.com/openai/codex/issues/47034)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 官方令牌里的套餐字段。这是推断，不是官方说明。

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

```bash
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 按美元算](https://blog.laozhang.ai/zh/posts/codex-api-key-vs-subscription)。

自定义 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`：

```toml
[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 怎么选](https://blog.laozhang.ai/zh/posts/codex-config-toml)。

顺带把 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 一次跑通](https://blog.laozhang.ai/zh/posts/codex-cli-install)。下一个值得回头看的节点是 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 桌面版几乎每天要求重新登录）](https://github.com/openai/codex/issues/49443)（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 上内置运行时导致超时）](https://github.com/openai/codex/issues/47145)（9 月 22 日）给的取舍是让桌面版用外部 CLI（`CODEX_CLI_PATH`），登录能保持，但 ChatGPT Memory 不可用。

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

## 容易混在一起的 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 怎么解决？按错误后缀定位登录拒绝](https://blog.laozhang.ai/zh/posts/codex-token-exchange-failed-403)。
- TUI 已经进去，发消息时报 `401 Incorrect API key provided`：是模型请求的鉴权，常见于残留的第三方配置，见[Codex 报 401 Incorrect API key provided：先看 URL 和 key 文本](https://blog.laozhang.ai/zh/posts/codex-401-incorrect-api-key)。
- 启动正常、提交时报错：看第二行，见[Codex 提交消息时出错：原因在第二行，按报错原文逐类处理](https://blog.laozhang.ai/zh/posts/codex-error-submitting-message)。

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

### 重启后台服务会不会打断我其他窗口里正在跑的 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 都还开着。

## 参考来源

本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-10-17。

- [openai/codex issue #48195（要求把 daemon_auto_start 改成默认关闭）](https://github.com/openai/codex/issues/48195) (github.com)
- [openai/codex issue #52928 里 bboygun 2026 年 10 月 15 日的评论](https://github.com/openai/codex/issues/52928) (github.com)
- [OpenAI 开发者社区帖"Codex CLI 0.162.0 fails during TUI bootstrap"](https://community.openai.com/t/1404666) (community.openai.com)
- [openai/codex issue #48894 里 Humorhunter 2026 年 9 月 29 日的评论](https://github.com/openai/codex/issues/48894) (github.com)
- [openai/codex issue #52775（macOS 升到 0.162.1 后启动失败）](https://github.com/openai/codex/issues/52775) (github.com)
- [openai/codex issue #48600（Windows 与 WSL，0.157.1）](https://github.com/openai/codex/issues/48600) (github.com)
- [openai/codex issue #37971（启动时报没有可用的文件描述符）](https://github.com/openai/codex/issues/37971) (github.com)
- [openai/codex issue #49921（macOS 桌面版不显式设 HTTP_PROXY 就超时）](https://github.com/openai/codex/issues/49921) (github.com)
- [openai/codex issue #50211 里 kubilen 2026 年 10 月 16 日的评论](https://github.com/openai/codex/issues/50211) (github.com)
- [openai/codex issue #51052（WSL2 下 account/read 15 秒超时，Windows 成功）](https://github.com/openai/codex/issues/51052) (github.com)
- [openai/codex issue #54184（真正的错误是 401 token_revoked）](https://github.com/openai/codex/issues/54184) (github.com)
- [OpenAI 开发者社区帖"Codex CLI TUI fails during account/read workspace requirements bootstrap"](https://community.openai.com/t/1407111) (community.openai.com)
- [openai/codex issue #47456（远程主机保留失效的 ChatGPT 登录态，login status 仍显示已登录）](https://github.com/openai/codex/issues/47456) (github.com)
- [openai/codex issue #47034（登录成功后报 duplicate workspace in routing discovery）](https://github.com/openai/codex/issues/47034) (github.com)
- [openai/codex issue #49443（macOS 桌面版几乎每天要求重新登录）](https://github.com/openai/codex/issues/49443) (github.com)
- [openai/codex issue #47145（Windows 上内置运行时导致超时）](https://github.com/openai/codex/issues/47145) (github.com)