这里把公开资料中的 Codex 使用问题整理成训练规则：先讲重点，再判断问题在哪一层；本机已解决和低频重复的问题从当前问题区移出，只留下可复用记忆。
这是非官方观察页。GitHub issue 视为公开报告，不等于官方确认根因；只有官方文档、状态页或维护者明确说明时，才按官方信息处理。
适用范围：Codex Desktop、CLI、IDE extension、Browser/Computer Use、MCP、hooks、Windows/macOS、用量/限额、线程和上下文恢复。
本机规则：已经通过本机验证解决的问题，不再作为当前故障展示；一周内同类问题未出现三次的问题，除非官方确认或影响极高，也不占用近期高频区。
对我们这种 Mac 电脑，优先关注 Screen Recording、Accessibility、Computer Use helper、Browser/Computer Use、线程压缩和本地日志增长。
Windows-only 问题不直接套到 Mac，但它能训练 Codex 学会先分平台，避免把 sandbox、PowerShell、WSL 问题误判成全局服务故障。
hotfix、重启、重新授权后，不靠旧线程记忆下判断；先跑最小工具调用、最小浏览器控制、最小文件修改验证。
长线程压缩后是否立即恢复规则，要看 hook 是否真实在压缩边界触发；关键上下文先写检查点。
本机已经验证恢复的问题，不再占用当前问题区；下次只按触发条件重新复测，不把旧状态当成现在的事实。
看到 usage limit，不要只看一个剩余额度数字；要分开判断 UI 显示、订阅权益、真实 rate-limit 和服务状态。
线程不在列表里，不等于真的被删；先做只读备份，再查本地会话记录、附件、索引和归档状态。
旧线程打开就崩，尤其伴随 thread_tools，先备份会话和附件，再用新线程接力。
OAuth 浏览器授权成功，只说明凭据拿到了；已打开的线程仍可能持有旧的 MCP 连接状态。
同样是 Auth required，OAuth 和 bearer token 的处理完全不同；不要盲目照提示去登录。
本地记忆可以勤更新；Netlify 免费版生产发布要攒成每日汇总，除非出现真正高影响的新故障。
如果问题已经在这台 Mac 上验证解决，或一周内同类问题没有出现三次，就从“当前高影响问题”移出。
不记“它坏了”，只记“下次看到什么信号、先问什么、怎么做最小复测、失败时带什么材料上报”。同类信息只合并，不重复堆叠。
同类问题一周内达到三次，或出现官方确认、重大影响、本机复现时，才重新进入近期高频区。
公开站优先用终端发布脚本；如果 token 或权限未配置，就停在本地待发布，不改用浏览器打断用户。
本机已归档：Computer Use 屏幕录制/辅助功能授权已完成；浏览器控制与 Netlify API 发布已通过实测。发布验收必须同时检查页面内容和 Content-Type: text/html; charset=utf-8，这些不再按当前故障展示。
冗余控制：后续更新优先合并、压缩和忘记低频线索；记忆的目标是避免下次犯错，不是保存每一次公开评论。
发布节流：每天整理一次；公开站每天最多发布一次，只有极高影响问题才立即推送。
重点：用量突然消耗得异常快时，先查官方状态；不要反复重试、清配置，或立刻认定订阅失效。
OpenAI 在 2026 年 6 月确认：部分 Codex 账号可能被 abuse / fraud prevention 系统错误限流，导致用量消耗快于预期。官方称影响范围有限，事件现已恢复。
训练规则
来源
OpenAI Status: Codex Usage Limits Depleting Faster Than Expected
重点：多端同时出现 server overload 时，先查状态页并暂停盲目重试；不要马上改网络、清配置或重复发起长任务。
OpenAI 在 2026 年 7 月确认 Codex 5.6-sol 出现 increased server-overload errors，随后已恢复；官方 6 月复盘还确认一次服务端配置事故曾让 Codex 请求被错误拒绝为 HTTP 429。相近错误在同一时间跨表面出现时，应先判断为服务侧事件，不要直接认定个人额度耗尽。
训练规则
来源
OpenAI Status: Codex 5.6-sol Experiencing Increased Server-Overload Errors、OpenAI Status: 429 incident write-up
重点：Desktop 与 CLI 同时出现 access denied，先查状态页；不要立刻反复退出登录、清配置或重装。
OpenAI 在 2026 年 7 月确认，部分用户使用 Codex Desktop 与 CLI 时会收到 access-denied errors，事件现已恢复。这说明“未授权”文本也可能来自服务侧访问故障，而不必然是本地凭据失效。
训练规则
来源
重点：如果会话无法加载或继续，同时 Codex 请求失败，先留检查点并查状态页；不要先清登录态或重建配置。
OpenAI 对 2026 年 7 月 19 日事件的复盘说明，区域身份服务的数据库副本维护导致容量不足，使部分 ChatGPT 会话与部分 Codex 请求出现错误。服务已通过切走受影响区域流量恢复。
训练规则
来源
OpenAI Status: Elevated errors affecting ChatGPT (July 19 write-up)
重点：Review 错误并不总是 GitHub 授权或 PR 配置问题；先查状态页，恢复后再做一次最小重试。
OpenAI 于 2026 年 7 月 24 日确认 Codex Review 出现 elevated errors，受影响组件已恢复。状态页未公开根因，因此不能把这条服务事件归结为任一仓库、connector 或本机配置。
训练规则
来源
重点：旧线程一打开就崩时，先保护会话数据；thread_tools 不一定来自用户手写配置。
新的公开报告显示，macOS Codex Desktop 在恢复线程时可能出现 SIGKILL 和 unknown feature key in config: thread_tools，即使用户确认本地配置里没有这个 key。类似 thread_tools 问题此前也在 extension/app-server 路径中出现过。
训练规则
来源
重点：不要把压缩后的规则恢复完全托付给 SessionStart(source=compact)；长任务先写检查点。
公开报告显示，长轮次中发生 auto-compaction 后，匹配 compact 的 SessionStart hook 可能没有在压缩边界立即送达，而是排队到后续用户轮次才执行。这会造成压缩后上下文没有及时恢复，或后续普通轮次出现旧 context 重复注入。
训练规则
来源
重点：错误提示让你运行 codex mcp login，不一定代表 OAuth 未登录；先看该 server 是 OAuth 还是 bearer token。
公开报告显示，使用 bearer_token_env_var 的 MCP server 如果 token 缺失、过期或被拒绝，也可能被提示成 OAuth 登录问题。官方 MCP 文档同时支持 bearer token authentication 和 OAuth authentication；只有支持 OAuth 的 server 才应优先运行 codex mcp login <server-name>。
训练规则
Auth required，先检查配置中的认证模式。来源
重点：MCP 登录成功不等于当前已打开线程已经刷新授权；要分清浏览器授权、Codex 凭据缓存和线程内 MCP client 状态。
公开报告显示，远程 HTTP MCP server 通过 OAuth 浏览器登录成功后，原本已经打开的 Desktop 线程仍可能继续报 OAuth required。另一则尚未确认的报告称，部分服务器在 access token 过期后的 refresh 请求要求 resource 参数；缺失时，标为 required 的 MCP server 甚至可能阻止新任务初始化。官方文档说明 Streamable HTTP MCP 支持 OAuth，并通过 codex mcp login <server-name> 登录；官方认证文档也说明 Codex 会缓存登录详情。
训练规则
来源
openai/codex #29279、openai/codex #33403、Codex MCP docs、Codex Authentication docs
重点：会话列表里找不到线程时，先按索引/预览失效处理，不要立刻判定历史被删。
公开报告显示，Desktop 线程的第一条真实请求如果来自粘贴文本附件，重建本地索引后可能从项目会话列表消失，但原始 session 和附件仍在本地。另有 macOS 单例报告称，刚启动时的 runtime 同步重启可能让已经提交的首条提示没有持久化进新线程。再加上跨 Web/Desktop 后长对话不可见的未确认报告，结论仍不是“数据已删除”，而是重要内容必须有检查点。
训练规则
来源
openai/codex #29323、openai/codex #25290、openai/codex #33080、openai/codex #32944
重点：提交任务后界面冻结，先确认任务状态；不要因为看不到进度就重复提交同一任务。
一则 macOS Desktop 公开报告称，Add to task 在任务被接受后可能冻结界面，但远端任务仍继续执行；再次提交会产生重复任务、额外用量，以及同一工作区并发写入风险。该报告尚未获官方确认。
训练规则
来源
重点：看到“还有用量”但新消息立即限额，先分清 Usage UI、订阅权益和实际 rate-limit 判定，不要反复重试。
公开 issue 报告过两类相近现象：CLI/WSL 用户任意 prompt 都返回 usage limit 并给出下次可用时间；另有用户报告 Codex Usage 面板仍显示 remaining，但新 conversation 立即限额。官方定价页说明不同计划包含 Codex 且 Pro 有更高限额；官方状态页历史里也出现过 Codex rate limits 事件，但单个 issue 不能直接当作全局故障。
训练规则
/usage 或 /status、Web/Cloud 是否一致，并检查官方状态页是否有当前事件。来源
openai/codex #29228、openai/codex #29312、Codex Pricing、OpenAI Status History
重点：长线程卡住时，先保存摘要并开新线程接力，不要在旧线程里硬重试。
OpenAI 曾确认部分用户的 Codex compaction 出现服务侧延迟，且事件已恢复。另有公开报告显示，Desktop 长线程接近上下文上限后可能自动压缩未完成，继续发送消息时报 context length exceeded；大型工具/MCP 输出后漏算 token 的具体根因仍未获官方确认。
训练规则
来源
OpenAI Status: Increased latency for Codex compaction、openai/codex #29319、openai/codex #32888
重点：工具列表或新线程启动慢，先怀疑最近新增或不可达的 MCP，不要先归因到账号或模型。
有公开报告指出，配置的 MCP server 如果还在启动或不可达，聚合工具列表时可能阻塞核心 Codex 工作流，让可选扩展变成启动关键依赖。
训练规则
来源
重点：子代理长任务要落文件或写短摘要，父线程接近上限时先留检查点再等待。
父线程在子代理仍运行时发生 compaction，子代理后续完成结果可能没有送回父线程，表现为“子代理做完了但主线程没收到”。
训练规则
来源
重点：JSONL 解析失败时，先把大型 MCP 输出降成摘要或文件路径，再排查 SDK。
TypeScript SDK / codex exec --experimental-json 被报告在大型多行 MCP tool result 上抛出 Failed to parse item，应用层收不到结构化事件。另一则尚未确认的报告指出，程序化外层 exec 聚合多项命令时，即使每项申请了更大预算，外层结果仍可能先被截断，导致无效重试和额外消耗。
训练规则
来源
重点：自动化完成后，既要看命令结果，也要确认预期文件确实存在且非空。
一则 macOS CLI 公开报告称，codex exec --output-last-message 在目标父目录不存在时可能先完成任务、随后写最终消息失败，但仍返回 exit code 0。该报告尚未获官方确认。
训练规则
来源
重点：搜索项目前先排除会话、日志和缓存目录，避免把 Codex 自己的历史读回上下文。
公开报告提到，任务读取仓库或工作目录时可能误读本地会话 JSONL，导致上下文快速膨胀、隐私边界变差和总结质量下降。
训练规则
sessions、logs、备份或生成物。来源
重点：会话“不见了”时，先按 session id 和本地文件只读查找，不要只相信列表页。
codex resume --all 可能因为扫描窗口限制漏掉可按 session id 直接恢复的会话，尤其是首个用户消息出现在 JSONL 较后位置时。
训练规则
resume --all。~/.codex/sessions、本地索引、archived 状态和直接 resume。来源
重点：hook 文件存在不等于 hook 生效；在 worktree 里必须先做最小触发测试。
公开报告显示，Codex 在 Git worktree 中运行时，项目级 .codex/hooks.json 可能不加载；同样配置在普通 repo 中可触发。
训练规则
.codex/hooks.json 存在当成 hook 已生效的证据。~/.codex/hooks.json 或普通 checkout。来源
重点：关键写入保护不能只靠 PreToolUse，shell、patch、插件工具都要分别验证。
公开报告显示，部分内部编辑或 patch 路径可能没有触发预期的 PreToolUse hook，导致安全规则只覆盖了一部分工具调用。
训练规则
来源
看不见屏幕、不能点击，先查 Screen Recording 和 Accessibility；但“插件已启用”仍不代表工具真可用，也要检查新线程工具发现、原生连接和 helper。App 直接崩溃，则查 crash report 和 Computer Use capture。
磁盘突然变小，先查 Crashpad pending、code_sign_clone、SQLite WAL 和本地 logs，不要先怪项目文件。
项目 hook、插件 hook、worktree hook 的来源和执行 cwd 不总是直觉一致。关键规则上线前先用最小 hook 写临时文件验证。
长监控、长网页发布、长故障排查都应该定期写摘要。自动压缩失败时，直接开新线程接力会更稳。
重点：工具安装 toast、系统权限和当前线程可调用性是三层不同的状态。
尚未确认的 macOS 公开报告称，旧插件辅助组件或 Chrome 原生连接失败时，Computer Use/Chrome 仍可能显示已启用，却在重启后不可用，并且根本不会进入系统权限弹窗。另一则报告把故障缩小到 Desktop 新任务没有注入 Browser/Computer Use 所依赖的工具；还有 Linux CLI 报告称，模型运行时元数据变化后 MCP 已连接但 tool namespace 与工具搜索同时不可用。
训练规则
来源
重点：系统开始卡顿时先保住任务和产物，不要让自动化继续叠加内存压力。
一则尚未确认的 Apple Silicon macOS 公开报告称，更新后的 Desktop 在持续 Codex 工作中占用数十 GB 内存并冻结整机，重启仅暂时恢复。它不是本机复现，也不是已确认根因，但影响足够高，应保留为止血规则。
训练规则
来源
重点：项目配置能被 CLI 读取，不表示 Desktop 新线程一定获得同一条开发者指令。
一则尚未确认的 macOS 公开报告称，Desktop 的线程级指令可能覆盖项目 developer_instructions，使项目规则静默缺失，而同仓库 CLI 仍正常读取配置。
训练规则
AGENTS.md 或项目文档，不只依赖单一配置字段。来源
我们是 Mac，所以 Windows sandbox、PowerShell、WSL、非 ASCII 用户目录和 Windows updater 崩溃不应直接套用。但这些信息能训练 Codex：先问平台，再给建议。
重点：远程主机像断网时，先看 Codex/app-server/PowerShell 是否把系统资源吃满。
公开报告显示，Windows app-server 的 PowerShell AST parser 曾增长到约 185GB committed memory，导致 RDP/RPC/SSH exec 失败。
Codex.exe、codex.exe app-server、MCP node.exe 和异常 powershell.exe。重点：Windows 启动秒退时，先问用户目录是否含中文、韩文、日文等非 ASCII 字符。
中文、韩文、日文等 Windows 用户目录路径可能触发 updater/runtime 或 Browser Annotation 相关崩溃。
重点：更新失败要先分平台；Windows 看 updater 和用户路径，Mac 另走签名和权限路径。
有报告称 Windows 更新过程出现 “Something went wrong”。这类信息对 Mac 主要作为反例：不要把平台专属 updater 问题误判成账号或模型问题。