10/19 上午速报：换 Codex 凭证类型后旧会话报 encrypted content，维护者的定论是新建会话 (2026)

这一小时四个仓库都没有发版。

CLIProxyAPI 的发行版仍是 v8.0.33，发布于北京 10-18 21:06。

主干停在 10-18T13:05:44Z。本期覆盖北京时间 10-19 07:21 到 08:16，共 55 分钟。

sub2api 仍是 v0.2.17，codex2api 仍是 v3.1.1；codex-proxy 稳定版 v2.1.18、预发布 v2.1.19-beta.f824033 都没动。

有两件事值得现在处理。一件是 Codex 凭证类型切换的定论，它解释了有些老会话为什么突然接不下去。

另一件是一张把小机器 CPU 打满的报障，修复刚进 dev，发行版上没有。

结论先给：换凭证类型之后，旧会话只能新建

报障单是 #6749，10-18 23:26（北京）开的。

本刊 10/19 凌晨那期记过这张单，当时是已开、0 评论。今天它有了定论。

标题就是现象本身：从 codex api 换到 codex oauth 之后，ChatGPT 里之前那条会话接不下去了。

正文只有一句报错原文。它点名 rs_0db2ab95… 这个推理项验不过：

The encrypted content for item rs_0db2ab95… could not be verified. Reason: Encrypted content could not be decrypted or parsed.

今天 08:14（北京），维护者 luispater 回了定论，两秒后以 not planned 关单。原文三段：

Codex OAuth 与官方 API（codex-api-key）在 OpenAI 侧属于不同的组织（Organization），不能在同一个会话中混用。
在 OpenAI Responses 协议中，历史会话里的推理项（如 rs_...）包含 encrypted_content 字段，该字段由生成该响应时所属的 OpenAI 组织密钥进行加密。当你从 Codex API 切换到 Codex OAuth 后继续之前的会话时，客户端会将原组织生成的 encrypted_content 回传给新组织校验，上游因组织密钥不匹配无法解密，从而返回 Encrypted content could not be decrypted or parsed 错误。
切换凭证类型（或不同组织的账号）后，请新建会话继续使用。

三个条件同时成立才会撞上。同一条会话被两类凭证先后服务过；客户端把历史推理项回传；上游换到了另一个组织。

按维护者的说法，Codex CLI 与 ChatGPT 桌面版接着旧会话继续，都会回传这些项。

所以运维这边看到的现象常常是「换过供应商之后，老对话成片报错」。

为什么两类凭证是两个组织

Codex OAuth 是订阅账号，codex-api-key 是官方 API key。

维护者说这两者在 OpenAI 侧属于不同组织，两边的密文互不认。

在你的配置里，它们本来就分开放。OAuth 账号是 oauth.auth-dir 下的 auth 文件，段落是 oauth.providers.codex。

API key 则落在 api-keys.codex。

旧版顶层的 codex-api-key 由 config_v8.go 第 66 行迁到那里，样例见 config.example.yaml 第 1259 行。

分开存，选号时却汇进同一个池子。同一个模型两类凭证都能接，请求就可能落到另一边。

翻一遍 oauth.auth-dir 下的文件和 api-keys.codex 列表，就知道池里混没混。

本地那条重放缓存也没按凭证分家

如果客户端是 Claude Code 这类 Claude 格式，并且经 Codex 执行器出网，还有第二处会撞上同一堵墙。

CPA 会把上一轮的推理项存起来，下一轮再塞回请求。作用域是「模型 + 会话」，键里没有凭证。

v8.0.33 的 internal/cache/codex_reasoning_replay_cache.go 第 332–344 行：第 338–339 行写明会话键刻意不跟随上游凭证，第 340 行是最终键，只有模型与会话两段

codex_reasoning_replay_cache.go 第 338–339 行的注释写明了理由。

会话键是连续性的边界，刻意不跟选中的上游凭证绑定，好让换号时重放不丢。

换号不丢，跨组织也不丢。换到另一类凭证，重放的仍是原组织加密的那一份。

清理这条路也窄。错误被归类成 thinking_signature_invalid 时，才会删缓存。

判定在 codex_executor_reasoning.go 第 822 行。

分类只认两个字符串，见 codex_executor_terminal.go 第 367–368 行。

一个是 invalid signature in thinking block，另一个是 invalid_encrypted_content。

v8.0.33 的 internal/runtime/executor/codex_executor_terminal.go 第 354–372 行：第 367 行只匹配 invalid signature in thinking block 与 invalid_encrypted_content，其余落进第 373 行的 default

这张单报的那句原文，两个字符串都不含，所以不会触发清理。

缓存条目活一小时（CodexReasoningReplayCacheTTL），过期或重启才消失。

适用范围要说清楚。这条重放只在源格式是 Claude 时生效（codexReasoningReplayEnabledForSource）。

报障人那条是 Codex 客户端自己回传历史，与本地缓存无关，新建会话即可。

今晚的四步

新建会话。这是维护者给的处置，也是最快的一步。
别让同一个池子用两类凭证服务同一批会话。分实例跑，或者按凭证类型拆成两个入口。
已经混了的，长会话会随机坏。看到这条错就新建会话；当成封号把账号停掉，或者换号重试，都可能再撞上同一条。
Claude Code 那条路上，换了凭证但会话 id 没变，本地重放还会塞回旧组织的条目。等一小时、重启进程，或者直接换新会话 id。

次条：CPU 单修进 dev，v8.0.33 上没有

#6746 这条报障，本刊 10/18 深夜那期写过现象：Claude 格式客户端经 OpenAI 兼容上游，翻译器每块都把整份请求重解一遍。

这一小时变的是修复落地，以及作者更正了自己给的数据。

作者 pf-sjtu 在 2 vCPU、1 GB 的机器上量到进程 CPU 190%，pprof 里 gjson.parseSquash 占 56.5% 与 77.5%。

微基准那组仍成立：300 KB 请求每块 104–110 µs，修好后 5–6 µs。

作者 22:46 更正了端到端那组。原来的首 token 时间被基准客户端多算了，它给每个请求新建 SSL 上下文，约 0.8 秒乘并发。

更正后是 8 路并发、191 KB 请求体、每路约 600 输出 token，同机、同一上游、两种构建交替跑。

指标	v8.0.32	修好后
首 token（两次运行）	13.4 s / 20.0 s	5.1 s / 6.9 s
每流解码速度（中位）	70 / 95 tok/s	97 / 120 tok/s
每输出 token 的 CPU	约 7.2 ms	约 2.3 ms
整批墙钟	23.6 s / 27.5 s	13.4 s / 12.8 s

修复今天 08:11（北京）落进 dev：030d17ed，2 文件 +98/−7，提交说明末尾是 Closes: #6746。

作者是维护者 Luis Pater。改法是把 stream 与工具名映射各解析一次、存进转换状态。

社区那张 PR #6747 仍是 open，mergeable 变成 dirty，2 文件 +72/−4。

它比 dev 上这笔少了工具名映射那一处。

v8.0.33 的 internal/translator/openai/claude/openai_claude_response.go 第 134–152 行：第 143 行每个分块都从原始请求里取一次 stream，第 144–148 行两个分支都以 return 收尾

dev 分支同一文件第 140–163 行：第 142 行起改用 state，第 155–158 行只解析一次 stream，第 163 行才进流式分支

同一分钟，#6746 被打了 Fixed 标签，单子仍然 open。

升级不解决。v8.0.33 发布于北京 10-18 21:06，比这笔提交早 11 小时。

影响面只落在一条路上：Claude 格式客户端经 OpenAI 兼容上游。请求体越大、并发越高越重，这一版没有开关能关掉它。

手头能做的只有降并发，或者把这条链路拆到别的实例上，等下一版。

上游与额度这一小时

三家上游状态页全绿。status.openai.com 是 All Systems Operational，活动事件 0，没有降级组件。

status.anthropic.com 同样全绿，10-19 无事件。

status.cloud.google.com 仍是 7 条，最近一条停在 10-08 到 10-09 的 Cloud Storage。

额度侧没有新信号。codex-reset.com 记录今日 UTC 尚未重置。

最近一次已验证的全局重置是 Oct 17 20:41 UTC，北京 10-18 04:41，约 28 小时前。

累计 55 次全局重置、10 次 banked。

把 Tibo 的提示计入后，24 小时 45%、48 小时 70%；模型口径是 21% 与 37%。

opentherank.com/codex-reset/ 仍记 63 次，中位间隔 3.1 天，最长 68 天。

@thsottiaux 最新一条停在 2026-10-18T20:34:06Z，在窗口之前。

官方社区 Codex 分区最新一条是 10-18T21:27:55Z，同样在窗口前。

Reddit 三个板块窗口内共 3 条。r/OpenAI 是 GPT Work 作品展示（23:29:11Z），r/ClaudeAI 是梗图（23:40:39Z）。

r/GeminiAI 那条在讲 Universal Cart（23:55:16Z）。三条都与额度风控无关，未收。

还没落地的东西

#6746 的修复什么时候发版，发布说明会不会点明「Claude 格式经 OpenAI 兼容上游」这条路。
#6747 与 dev 上的改法撞车，作者会不会自己关掉。
「切换凭证类型必须新建会话」这条，官方会不会写进文档，今天它只出现在一条 issue 回复里。
报障人提到其它翻译器可能有同样的逐块解析，他自己没有审计完。

这一小时四个仓库都没有发版。

CLIProxyAPI 的发行版仍是 v8.0.33，发布于北京 10-18 21:06。

主干停在 10-18T13:05:44Z。本期覆盖北京时间 10-19 07:21 到 08:16，共 55 分钟。

sub2api 仍是 v0.2.17，codex2api 仍是 v3.1.1；codex-proxy 稳定版 v2.1.18、预发布 v2.1.19-beta.f824033 都没动。

有两件事值得现在处理。一件是 Codex 凭证类型切换的定论，它解释了有些老会话为什么突然接不下去。

另一件是一张把小机器 CPU 打满的报障，修复刚进 dev，发行版上没有。

结论先给：换凭证类型之后，旧会话只能新建

报障单是 #6749，10-18 23:26（北京）开的。

本刊 10/19 凌晨那期记过这张单，当时是已开、0 评论。今天它有了定论。

标题就是现象本身：从 codex api 换到 codex oauth 之后，ChatGPT 里之前那条会话接不下去了。

正文只有一句报错原文。它点名 rs_0db2ab95… 这个推理项验不过：

The encrypted content for item rs_0db2ab95… could not be verified. Reason: Encrypted content could not be decrypted or parsed.

今天 08:14（北京），维护者 luispater 回了定论，两秒后以 not planned 关单。原文三段：

Codex OAuth 与官方 API（codex-api-key）在 OpenAI 侧属于不同的组织（Organization），不能在同一个会话中混用。
在 OpenAI Responses 协议中，历史会话里的推理项（如 rs_...）包含 encrypted_content 字段，该字段由生成该响应时所属的 OpenAI 组织密钥进行加密。当你从 Codex API 切换到 Codex OAuth 后继续之前的会话时，客户端会将原组织生成的 encrypted_content 回传给新组织校验，上游因组织密钥不匹配无法解密，从而返回 Encrypted content could not be decrypted or parsed 错误。
切换凭证类型（或不同组织的账号）后，请新建会话继续使用。

三个条件同时成立才会撞上。同一条会话被两类凭证先后服务过；客户端把历史推理项回传；上游换到了另一个组织。

按维护者的说法，Codex CLI 与 ChatGPT 桌面版接着旧会话继续，都会回传这些项。

所以运维这边看到的现象常常是「换过供应商之后，老对话成片报错」。

为什么两类凭证是两个组织

Codex OAuth 是订阅账号，codex-api-key 是官方 API key。

维护者说这两者在 OpenAI 侧属于不同组织，两边的密文互不认。

在你的配置里，它们本来就分开放。OAuth 账号是 oauth.auth-dir 下的 auth 文件，段落是 oauth.providers.codex。

API key 则落在 api-keys.codex。

旧版顶层的 codex-api-key 由 config_v8.go 第 66 行迁到那里，样例见 config.example.yaml 第 1259 行。

分开存，选号时却汇进同一个池子。同一个模型两类凭证都能接，请求就可能落到另一边。

翻一遍 oauth.auth-dir 下的文件和 api-keys.codex 列表，就知道池里混没混。

本地那条重放缓存也没按凭证分家

如果客户端是 Claude Code 这类 Claude 格式，并且经 Codex 执行器出网，还有第二处会撞上同一堵墙。

CPA 会把上一轮的推理项存起来，下一轮再塞回请求。作用域是「模型 + 会话」，键里没有凭证。

v8.0.33 的 internal/cache/codex_reasoning_replay_cache.go 第 332–344 行：第 338–339 行写明会话键刻意不跟随上游凭证，第 340 行是最终键，只有模型与会话两段

codex_reasoning_replay_cache.go 第 338–339 行的注释写明了理由。

会话键是连续性的边界，刻意不跟选中的上游凭证绑定，好让换号时重放不丢。

换号不丢，跨组织也不丢。换到另一类凭证，重放的仍是原组织加密的那一份。

清理这条路也窄。错误被归类成 thinking_signature_invalid 时，才会删缓存。

判定在 codex_executor_reasoning.go 第 822 行。

分类只认两个字符串，见 codex_executor_terminal.go 第 367–368 行。

一个是 invalid signature in thinking block，另一个是 invalid_encrypted_content。

这张单报的那句原文，两个字符串都不含，所以不会触发清理。

缓存条目活一小时（CodexReasoningReplayCacheTTL），过期或重启才消失。

适用范围要说清楚。这条重放只在源格式是 Claude 时生效（codexReasoningReplayEnabledForSource）。

报障人那条是 Codex 客户端自己回传历史，与本地缓存无关，新建会话即可。

今晚的四步

新建会话。这是维护者给的处置，也是最快的一步。
别让同一个池子用两类凭证服务同一批会话。分实例跑，或者按凭证类型拆成两个入口。
已经混了的，长会话会随机坏。看到这条错就新建会话；当成封号把账号停掉，或者换号重试，都可能再撞上同一条。
Claude Code 那条路上，换了凭证但会话 id 没变，本地重放还会塞回旧组织的条目。等一小时、重启进程，或者直接换新会话 id。

次条：CPU 单修进 dev，v8.0.33 上没有

#6746 这条报障，本刊 10/18 深夜那期写过现象：Claude 格式客户端经 OpenAI 兼容上游，翻译器每块都把整份请求重解一遍。

这一小时变的是修复落地，以及作者更正了自己给的数据。

作者 pf-sjtu 在 2 vCPU、1 GB 的机器上量到进程 CPU 190%，pprof 里 gjson.parseSquash 占 56.5% 与 77.5%。

微基准那组仍成立：300 KB 请求每块 104–110 µs，修好后 5–6 µs。

作者 22:46 更正了端到端那组。原来的首 token 时间被基准客户端多算了，它给每个请求新建 SSL 上下文，约 0.8 秒乘并发。

更正后是 8 路并发、191 KB 请求体、每路约 600 输出 token，同机、同一上游、两种构建交替跑。

指标	v8.0.32	修好后
首 token（两次运行）	13.4 s / 20.0 s	5.1 s / 6.9 s
每流解码速度（中位）	70 / 95 tok/s	97 / 120 tok/s
每输出 token 的 CPU	约 7.2 ms	约 2.3 ms
整批墙钟	23.6 s / 27.5 s	13.4 s / 12.8 s

修复今天 08:11（北京）落进 dev：030d17ed，2 文件 +98/−7，提交说明末尾是 Closes: #6746。

作者是维护者 Luis Pater。改法是把 stream 与工具名映射各解析一次、存进转换状态。

社区那张 PR #6747 仍是 open，mergeable 变成 dirty，2 文件 +72/−4。

它比 dev 上这笔少了工具名映射那一处。

dev 分支同一文件第 140–163 行：第 142 行起改用 state，第 155–158 行只解析一次 stream，第 163 行才进流式分支

同一分钟，#6746 被打了 Fixed 标签，单子仍然 open。

升级不解决。v8.0.33 发布于北京 10-18 21:06，比这笔提交早 11 小时。

影响面只落在一条路上：Claude 格式客户端经 OpenAI 兼容上游。请求体越大、并发越高越重，这一版没有开关能关掉它。

手头能做的只有降并发，或者把这条链路拆到别的实例上，等下一版。

上游与额度这一小时

三家上游状态页全绿。status.openai.com 是 All Systems Operational，活动事件 0，没有降级组件。

status.anthropic.com 同样全绿，10-19 无事件。

status.cloud.google.com 仍是 7 条，最近一条停在 10-08 到 10-09 的 Cloud Storage。

额度侧没有新信号。codex-reset.com 记录今日 UTC 尚未重置。

最近一次已验证的全局重置是 Oct 17 20:41 UTC，北京 10-18 04:41，约 28 小时前。

累计 55 次全局重置、10 次 banked。

把 Tibo 的提示计入后，24 小时 45%、48 小时 70%；模型口径是 21% 与 37%。

opentherank.com/codex-reset/ 仍记 63 次，中位间隔 3.1 天，最长 68 天。

@thsottiaux 最新一条停在 2026-10-18T20:34:06Z，在窗口之前。

官方社区 Codex 分区最新一条是 10-18T21:27:55Z，同样在窗口前。

Reddit 三个板块窗口内共 3 条。r/OpenAI 是 GPT Work 作品展示（23:29:11Z），r/ClaudeAI 是梗图（23:40:39Z）。

r/GeminiAI 那条在讲 Universal Cart（23:55:16Z）。三条都与额度风控无关，未收。

还没落地的东西

#6746 的修复什么时候发版，发布说明会不会点明「Claude 格式经 OpenAI 兼容上游」这条路。
#6747 与 dev 上的改法撞车，作者会不会自己关掉。
「切换凭证类型必须新建会话」这条，官方会不会写进文档，今天它只出现在一条 issue 回复里。
报障人提到其它翻译器可能有同样的逐块解析，他自己没有审计完。

10/19 上午速报：换 Codex 凭证类型后旧会话报 encrypted content，维护者的定论是新建会话

结论先给：换凭证类型之后，旧会话只能新建

为什么两类凭证是两个组织

本地那条重放缓存也没按凭证分家

今晚的四步

次条：CPU 单修进 dev，v8.0.33 上没有

上游与额度这一小时

还没落地的东西

Related content

10/19 上午速报：换 Codex 凭证类型后旧会话报 encrypted content，维护者的定论是新建会话

结论先给：换凭证类型之后，旧会话只能新建

为什么两类凭证是两个组织

本地那条重放缓存也没按凭证分家

今晚的四步

次条：CPU 单修进 dev，v8.0.33 上没有

上游与额度这一小时

还没落地的东西

Related content