持续研究报告 ｜ 运行可靠性
围绕任务执行、结果交付与恢复过程，对公开个案进行比较、解释和边界审查的持续性研究笔记。
Codex 出现异常后，首要困难往往是判断任务进行到了哪里，以及下一步操作会不会重复已有工作。本轮从既有 34 项记录中选取 8 项具有可比较过程的公开个案，结合 MCP 官方文档，重新审查执行、结果传递、认证和恢复之间的关系。材料表明，“没有看到回复”既可能对应读取遗漏，也可能对应没有留存回复；任务结束也不保证输出文件已经保存。认证恢复记录若同时更换会话和认证方式，则不足以确定恢复原因。由此形成的操作建议是：围绕当前尚未确定的环节取证，分别验收执行与产物，并用控制变量的复测区分解释。现有材料不能证明共同根因、发生率或这些建议的普遍有效性。
关键词：Codex；证据分级；可复现性；故障诊断；上下文恢复；MCP；自动化安全
这是非官方观察页。GitHub issue 视为公开报告，不等于官方确认根因；只有官方文档、状态页或维护者明确说明时，才按官方信息处理。
适用范围：Codex Desktop、CLI、IDE extension、Browser/Computer Use、MCP、hooks、Windows/macOS、用量/限额、线程和上下文恢复。
本页讨论公开材料的含义，不报告当前本机故障。旧版 34 项记录保留在附录；本轮 8 项复核只涉及所引 issue 正文，未逐一复现实验，也未完整审查评论、相关补丁和版本发布。其余 26 项暂不进入本轮综合论证。
面对回复缺失、认证失败或任务中断，应依据哪些证据判断执行进度、区分可能原因，并决定是否重试？哪些处置建议已有材料支持，哪些仍只是风险控制方案？
版本、平台、日期和退出码等字段适合结构化比较；issue 中的操作过程、失败体验和原因猜测则需要保留上下文。两者不是两套平行目录：字段用于确认案例是否可比，叙述用于理解过程，正文再综合解释共同点、差异与仍未解决的问题。结构化字段也可能来自未经独立验证的报告，格式整齐不提高其可信度。
非结构化材料经审读后抽取为证据知识图谱。图谱记录来源、适用环境、报告内容、编辑推论、关系理由和不确定性；“支持”“限定”“提出待验证措施”分开处理。第 3 节各项判断后的“查看依据”提供可展开的审读记录，也可下载完整属性图 JSON。知识图谱本身是结构化表示，不能取代原文语境。未复核材料允许保留为待审节点，不强行为任何论点提供支持。
这一处理借鉴 Hogan 等对知识图谱语境的讨论：关系的解释需要交代时间、出处及成立范围。[1] 本文据此为抽取后的关系保留来源和适用条件；这些具体字段是本报告的设计选择，并非该论文验证过的 Codex 故障模型。
本轮采用目的性选样：选择能比较任务阶段、认证变量或反驳旧版总论断的 8 项个案（E01、E14、E15、E17、E21、E23、E29、E31），另核对 1 份官方认证文档。这是探索性个案综合，不是系统综述；未做穷尽检索、独立双人编码或频率估计。
Runeson 与 Höst 提出，软件工程案例研究应使读者能够从资料追溯推论，并考虑替代解释与效度威胁。[2] 本文用这一方法要求审查现有材料，不声称仅凭公开 issue 已完成其所讨论的完整案例研究。本轮另选 5 篇已发表论文作为理论和方法依据，核对书目信息与所引章节；这是针对当前论点的定向检索，不是相关研究的穷尽性综述。
表 1约束不同资料能够承担的证明任务；等级用于提示审读要求，不把来源身份直接换算成某一结论的可信概率。
| 等级 | 使用约束 |
|---|---|
| A 级 | 官方文档、OpenAI Status 事件或维护者明确说明。可用于界定已知事实，但仍不当然证明本机已复现。 |
| B 级 | 可重复的本机最小复现，或时间、日志级别、目标和用户症状同时对齐的本机证据。 |
| C 级 | 一个或多个公开 issue、用户报告或尚未发布的修复信号。可形成排查假设，不得写成已确认根因。 |
| D 级 | 单次关键词命中、聊天回声、无症状对齐的 TRACE/INFO 或无法复现的观察。仅作为待验证线索。 |
以上 A—D 是本报告用于产品事件资料的工作分级，不是学术界通用的证据等级。学术论文另列于第 6.2 节，分别注明它们提供的方法、理论或评测依据；同行评议不意味着其结论可直接移用于本页个案。
本报告把“在明确条件下发生的一段操作及其可观察结果”作为分析单位，而不直接把一个 issue 编号视为一个同质样本。报告者可能在同一页面中补充重试、更换客户端或改用认证方式后的结果；这些记录共享一个标题，却未必具有相同前提。若把它们压缩成“问题已恢复”，就会丢掉判断恢复原因所需的信息。第 3.1 节中同一报告的前后两组轮次，正需要按这种方式分别阅读。
具体审读时，首先找出操作前提与目标：使用什么环境、希望完成哪项工作、采取了什么动作。随后辨认观察的来源：是用户看到的界面、命令返回、保存记录，还是最终产物。最后才处理解释性语句，例如报告者认为某次失败与缓存或压缩有关。观察与解释可以同时保留，但不能因为出现在同一段文字中便具有相同证明力。本轮没有对所有原文逐句编码，也没有由第二位研究者独立复核；这里说明的是已采用的区分原则和后续复核应保留的记录粒度。
不同报告之间的比较还要检查条件是否相近。相同错误文字不足以消除平台、版本、认证方式或操作阶段的差异；同一平台也不代表故障相同。本文采用的比较问题是“哪些差异会改变下一步行动”，而不是“哪些记录可以归入同一个标签”。这种比较允许保留尚不能归并的材料。例如，资源异常与回复读取遗漏可以共同影响任务交付，却不能仅因结果都是“工作中断”就合并根因。
非结构化材料的价值，常常在于一个条件词或先后顺序。“重新登录后恢复”与“重新登录、切换会话并修改认证配置后恢复”，能支持的解释并不相同。抽取字段时应保留这一区别：时间用于建立先后关系，版本用于限定适用范围，原文位置用于回查被省略的语境。没有记录的字段应保持未知，不根据标题或相似案例补成看似完整的数据。
知识图谱在本报告中的用途，是把这些依赖关系显式保存。当某条证据的含义需要修订时，可以反查它影响了哪个判断和哪条操作建议；当一条建议缺少依据时，也能反向检查它究竟来自报告、论文中的一般原则，还是编辑提出的方案。一个来源经多次转述仍是同一来源，不能因建立了多个节点就算作多份独立证据。图谱的连线理由需要人工审读，节点数量与连接密度不作为可信度指标。
这也解释了为何尚未复核的 26 项材料继续留在附录：保留它们有助于后续回查，但直接让其支持正文，会把未经审查的解释混入当前结论。反过来，材料暂未归并也不表示它没有价值。后续若出现更完整的时间线、相反结果或可重复复现，应重新判断原结论的范围，而不是为了保持图谱整齐拒绝纳入差异。
图 1将这一关系展开：结构化字段与原始叙述共同接受审读，知识图谱保存推论的出处和条件。它不是从材料自动生成可信结论的流程，也不是产品内部的执行状态机。
来源：本文第 1.2—1.5 节的方法整理，参照文献 [1]、[2]。实线表示审读与应用顺序，虚线表示溯源记录关系；均不表示已验证的因果机制。未能归并的材料仍保留待审，不必进入判断。
为使材料的组织方式能够被核查，图 2将当前属性图中与个案证据有关的部分投影为实体—关系模型。来源保存公开地址，记录保存审读状态、观察及其条件；“引用”回答材料从哪里来，“论证”则说明材料为何支持、限定或提出某项判断。两种关联分开保存，因此，列出一个来源链接并不自动构成对结论的支持。
来源：当前证据图谱 JSON及其审读登记。PK 为逻辑主键，FK 为关联字段；1 表示恰好一项，1..* 表示至少一项，0..* 表示零至多项。当前实现使用属性图的节点与边，并未部署图示关系数据库：Citation 由记录指向来源的 cites 边投影，Assertion 由记录指向判断的 supports、limits、motivates 边投影，边的端点映射为外键。待审记录不进入论证，已审记录也可暂不归并；撤回判断只允许接收限定关系。本图选列主要属性，省略官方文档、学术文献与研究方法节点及其单独关系；论文提供的方法或理论背景不作为个案论证。
先确认执行到了哪一步，再决定是否重试
这些个案的共同价值，在于揭示了几个容易被合并的判断：任务是否已接收、命令是否已执行、回复是否可读取、成果是否已保存。它们需要不同的证据，也对应不同的后续行动。已有工作尚未核实就重试，可能造成重复执行；把真正的执行失败当成显示问题，又会延误处理。
这是从选定材料得到的诊断原则，并非对 Codex 所有故障的根因解释。旧版“可靠性的核心问题是状态不一致”外推过度，本版撤回该判断。资源耗尽与沙盒初始化失败提醒我们：有些异常涉及实际资源约束或明确的执行阻断，必须保留各自的机制与处置条件。
前述案例研究方法与知识图谱研究分别回答了“推论如何从材料中产生”和“推论的条件如何被保存”。二者结合后，可以检查一句判断是否有出处、出处是否真的包含相应观察，以及概括时是否省略了会改变含义的条件。本文把这种连接视为研究设计要求，而不是已经完成充分验证的证明。它能暴露证据缺口，却不会自动填补缺口。
任务交付与任务恢复还需要另一组概念。端到端论证关注由哪一层确认最终要求得到满足，回滚恢复研究关注失败后怎样保持可接受的系统状态及外部行为。[3][4] 两者在本报告中的交点，是恢复后的工作仍须接受交付验收。重新打开会话只改变了继续工作的条件；目标文件、已发生的外部操作以及剩余要求，仍需分别核查。这是本文对理论的应用解释，不是对 Codex 内部协议的描述。
因此，本文不把这些论文排列成“已有研究都证明本方案有效”的论据集合。方法文献帮助约束研究过程，系统论文提供分析概念，产品个案揭示具体观察；三者承担不同任务。若缺少实际恢复对照，即使理论来源充分，也只能提出有理由的方案。若个案具有清楚的结果记录，却缺少机制证据，也只能确认该结果，不能直接完成根因归纳。
本文将完成理解为相对于用户要求的验收结果。例如，要求生成报告时，可读且内容完整的文件是主要交付物；要求发布报告时，目标地址能够提供正确版本才是交付的一部分。相同文件在前一个任务中可能已经满足要求，在后一个任务中却仅是中间成果。因此，“完成”不能由某个统一按钮、退出码或自然语言承诺独立定义。
失败也需要指明对象。工具调用失败，不必然意味着此前的成果无效；整项工作尚未完成，也不意味着其中每一步都应重做。与完成和失败并列的“未知”，表示当前观察不足以决定结果，而不是一种隐含的失败。将未知单独保留，有助于避免把“我看不到”改写成“它不存在”，也防止以“可能已经完成”为由直接结束交付。
任务接收、实际执行、结果保存与结果可读，是供分析使用的几个核查问题，并非本文声称产品必然按顺序经过的内部状态机。有些任务会边执行边保存，有些结果可能已经保存但暂时不可读。实用的做法是指出目前哪些问题已得到证据回答、哪些仍然悬而未决，再选择能够缩小不确定性的检查。
图 3将这一原则转为推荐的交互时序。时间自上而下推进，用户、协作代理与目标端分别承担提出要求、执行与核查、提供结果证据的角色。界面没有回复时，下一条请求应是核查而非重复执行；图末两个分支分别处理“可以交付”和“存在缺口或仍未定”的结果。
来源：本文第 2.2 节及判断 C1的应用解释，参照文献 [3]。竖虚线为责任角色的生命线，时间向下；横实线为请求或原任务操作，横虚线为返回或报告。opt 框表示可选步骤：信号缺失也可直接进入核查，不必等待执行完成；alt 框内为互斥分支。目标端泛指文件、服务及相应状态记录，不代表某个固定接口；查询仅限已授权的无副作用读取。图为建议流程，不是一次实际实验记录，也不披露或推定产品内部调用协议。
本文提出，核查投入应与下一步行动的后果相称。重新读取一个已知无副作用的文件，与再次发送消息、创建记录或覆盖成果，并不具有相同风险。对前者，一次范围明确的重读可能已经足以澄清问题；对后者，应优先查明目标端是否已有对应结果。这里不设通用的等待时长或重试次数，因为现有材料不足以支持这类数字。
较深的检查也不总是更好。若已有证据足以确认产物缺少某一章节，下一步可以是补齐该章节，而不是继续收集与缺项无关的日志。只有当新增信息可能改变当前行动，或对解释重要分歧确有必要时，才继续采样。这样设计的目的，是让谨慎判断与实际推进兼容；其是否真正减少无效检查，仍需要第 5 节提出的使用验证。
表 2先并列四组会改变行动的证据差异，再由本节解释其含义。比较不以相似症状归并共同根因为目标，而是辨认哪些观察足以改变判断、哪些仍不足以排除其他解释。
| 对照问题与资料 | 可观察的差别 | 综合判断及其边界 |
|---|---|---|
| 无响应发生在哪一阶段？ | E17 的界面冻结，但任务已接收，重复提交产生重复任务；E31 在沙盒构建阶段退出，目标命令尚未运行。 | 重试前分别核查接收与执行状态。不能由界面冻结推定后台成功，也不能把执行前阻断解释成显示遗漏。 |
| 轮次结束是否等于已交付？ | E01 的后续回复已保存，但读取接口仍为空；E23 的轮次结束且退出码为 0，目标文件却写入失败。 | 回复可读、文件保存与轮次结束分别验收。E01 最初无回复仍原因未明；E23 不说明所有退出码均不可信。 |
| 恢复是否说明找到了原因？ | E14 的 bearer 失败得到 OAuth 提示；E15 同时更换进程与认证方式后恢复。 | 先辨明认证模式，再控制对照条件。多个条件同时变化，不能识别单一恢复原因，也不能确认缓存机制。 |
| 能够接续是否等于故障修复？ | E21 报告子代理结果未交接；E29 报告内存增长，重启后下降又复发。 | 可提出保存必要成果的接续方案，但效果尚未测量；没有证据证明检查点能够阻止内存增长。 |
来源：本轮 8 项已审读 issue 正文的综合，点击 E 编号可展开环境、版本、原文链接与审读边界。各组来自不同条件，是跨个案比较，不是受控实验、独立复现或故障频率统计。
两个表面相似的现象，可能意味着相反的行动方向。在 #33900 中，报告者通过远程视图等线索发现界面冻结时任务已经接收，重复提交又产生了任务。与之相比，#47345 给出了沙盒最小命令在初始化阶段退出的记录；在该复现中，目标命令尚未运行。前者提示避免重复提交，后者提示检查执行前提，两者不能由“界面没有进展”这一外观统一解释。
#44806 内部还包含两组不同结果。最初的轮次结束后未发现保存的助手回复；随后诊断轮次已有可见回复和持久化记录，但读取工具仍返回空。后者支持“读取可能遗漏已存在的回复”，却不能倒推前者也只是读取遗漏。#33898 则把边界推进到产物：特定 CLI 版本在输出目录不存在时，轮次完成、进程退出为 0，但最后消息没有写入指定文件。
因此，完成性应按实际任务分别验收：请求被接收不等于工作完成，工作结束也不等于结果已经交付。输出文件是交付物时，应检查存在性与必要内容；涉及外部写入时，应先确认目标端状态，再判断重试是否安全。这是基于个案风险提出的验收规则，并不意味着每次任务都要读取底层日志。
这一验收思路可与 Saltzer、Reed 和 Clark 的端到端论证对照：其文件传输示例说明，底层传输可靠性不能替代应用对最终文件的完整性检查。[3] 本文将该原则用于“结果是否交付”的判断属于概念迁移，不能据此确认 Codex 的内部实现或上述缺陷的原因。
把这组案例放在一起，得到的不是“无回复通常属于哪一类故障”的频率判断，而是不同证据具有不同的排除作用。目标命令执行前的明确错误，可以缩小该命令未产生结果的解释范围；读取接口为空，则不能排除结果已通过另一通道保存。前一种证据描述执行障碍，后一种证据只描述一次读取的结果。两者虽然都伴随没有看到预期输出，却不应触发同一套重试行为。
核对多个位置时，还须考虑它们是否真的提供独立信息。如果界面提示和读取接口都转述同一个状态源，两者一致可能只是重复了同一信息；直接打开目标文件或检查外部操作记录，才可能补上另一环节的观察。这是本文提出的检查选择原则，并非要求每项任务寻找固定数量的“独立通道”。对无法访问目标端的情况，应明确观察范围，而不能以本地查无记录代替目标端未发生操作的结论。
适用边界：上述依据来自报告正文及其所附记录，本轮未独立复现。#33898 限于 CLI 0.144.5 所述输出路径情形；#47345 限于所报 Linux 与 bundled CLI 组合。不能据此认定当前安装版本仍有同一问题。
以下为 2026-09-25 审读记录的转述，非逐字引文，未独立复现。链接可回查原文；关系理由是本文的编辑判断。
报告环境：ChatGPT desktop 26.903.71938；bundled CLI 0.153.4；macOS 26.6.1 arm64
来源观察：原始轮次结束后没有保存的助手消息；后续诊断回复已可见且持久化，但读取接口仍返回空。
关系理由：同一报告区分无保存回复与读取遗漏，要求分阶段验收。
边界：原始无回复原因未明；未独立复现，不将所有轮次归为显示错误。 原文定位：What is the issue? / follow-up diagnostic observations。
报告环境：App 1.2.35；macOS 26.5.2 arm64
来源观察：Add to task 后界面冻结，其他视图显示任务已被接收；再次提交产生重复任务。
关系理由：已接收时重复提交的个案说明重试需要任务接收证据。
边界：不能外推所有界面冻结都表示后台成功；报告未证明一般发生率。 原文定位：What is the issue? / observed behavior。
报告环境：CLI 0.144.5；Darwin 25.5.0 arm64；--output-last-message
来源观察：输出父目录不存在时，轮次完成后写文件失败，进程仍退出 0。
关系理由：轮次完成与目标文件保存结果在报告中不同。
边界：仅适用于报告中的参数与版本；不推断所有 exit 0 都不可用。 原文定位：What is the issue? / reproduction。
报告环境：Ubuntu 24.04.5；App 26.917.51856；bundled CLI 0.155.0-alpha.16；bwrap 0.9.0
来源观察：沙盒最小 /bin/true 在构建 bwrap 时退出 1；系统 bwrap 对照返回 0。
关系理由：初始化失败定位到命令执行之前，限定无输出的解释。
边界：关闭 issue 不证明当前安装包已修复；未独立复现或审查修复版本。 原文定位：What is the issue? / minimal sandbox reproduction。
MCP 认证材料说明了为什么必须区分产品规则和个案解释。官方文档的认证配置部分列出了 bearer token 与 OAuth 等认证方式。#26760 报告 bearer token 失败时却收到 OAuth 登录提示。这使“先识别实际认证模式，再解释错误提示”成为有依据的排查原则；它没有证明所有认证失败都来自提示错误。
另一份材料 #29279 报告浏览器登录成功后，已有线程仍提示需要授权，随后在新进程中使用 bearer token 得到成功结果。但这个过程同时改变了会话和认证方式。旧线程连接、OAuth 流程或两者交互，都还可能解释差异；仅凭这次恢复，不能把“旧线程缓存”写成已确认根因，也不能承诺新建线程就会修复 OAuth。
更有辨别力的复测应尽可能只改变一个变量：先在相同认证方式、相同服务器和权限范围下比较会话，再根据结果判断是否需要检查认证配置。无法控制其他条件时，应记录变化并把结果表述为“在新条件下可用”，保留原因未定。测试使用低风险请求，不为验证猜测扩大权限。
这里需要防范的是内部效度威胁：当其他因素也随之变化，结果便不能唯一归因于所考察因素。[2] 因此，对 #29279 保留竞争解释，有方法论依据；至于哪一种解释成立，仍需针对该案例的新证据。
对认证恢复的解释，还应区分工作目标与研究目标。工作目标可能是在现有授权内恢复必要读取；研究目标则是确定为什么之前失败。前者达到以后，可以在验收通过的范围内继续工作，不必等待所有原因都查明。与此同时，报告仍应保存“原因未定”的结论，避免把一次可用的替代路径记录成今后遇到同类提示就应执行的固定修复。
更强的因果解释需要有辨别力的对照。例如，若要检验会话因素，就应尽可能保留认证方式和目标操作不变，并记录前后测试的时间与条件。即使结果不同，也还要考虑服务状态随时间变化等未控制因素。重新制造高风险失败并非必要步骤；在无法安全对照时，承认解释尚未确定，比连续改变多个设置后给出确定根因更准确。第 4.2 节据此将“可继续工作”与“已定位原因”分别验收。
适用边界：文档用于解释配置选项，不替某个历史 issue 确认根因。#29279 是 Windows 环境的个案；本轮没有重做其 OAuth 流程，也未证实任何缓存机制。
以下为 2026-09-25 审读记录的转述，非逐字引文，未独立复现。链接可回查原文；关系理由是本文的编辑判断。
报告环境：CLI 0.137.0；Darwin 25.5.0 arm64；bearer-token MCP
来源观察：报告在 bearer token 无效或过期时得到 OAuth 登录提示。
关系理由：bearer 失败却提示 OAuth，要求按认证方式解释错误。
边界：只核对报告正文；提示映射的代码解释未在本轮独立验证。 原文定位：What is the issue? / reproduction。
报告环境：Windows；Desktop/CLI 所报 0.130.0；Supabase HTTP MCP
来源观察：报告浏览器 OAuth 登录成功后已有线程仍失败；改用新进程与 bearer_token_env_var 后成功。
关系理由：一次恢复同时改变两个变量，无法单独识别会话效应。
边界：旧线程连接、OAuth 路径和交互影响均未排除；不得断定重开线程即可修复。 原文定位：What is the issue? / workaround。
来源观察：文档分别列出 bearer token 与 OAuth 等认证方式及对应配置。
关系理由：官方配置区分 bearer 与 OAuth，支持先辨别认证模式。
边界：产品配置说明不是历史个案的根因证据。 原文定位：Streamable HTTP servers / Authentication / Configuration。
#26728 描述父线程压缩后未收到子代理完成结果。报告者提出消息交接方面的解释，但这些解释仍是猜测。将阶段成果、验证结果和未完成事项保存在可恢复的位置，可以作为降低交接损失的方案；原报告并未比较“有检查点”与“无检查点”的恢复效果，因此不能把该方案写成已经验证的修复。
#33582 所报的内存增长与系统冻结进一步限定了这一建议。记录中应用内存达到约 55 GB，重启后下降又再次增长；报告者并未确定具体泄漏组件。检查点可能减少中断后的重做成本，却不能据此推断其能阻止内存增长。若系统正承受资源压力，还需判断保存操作是否安全、是否应停止新增任务。
本报告因而把检查点列为待验证的恢复措施：保存必要且脱敏的阶段成果，随后用真实恢复演练检查其是否足以继续工作。评价至少区分两件事——任务能否恢复、原故障是否消失。前者成功不能代替后者的证据。
Elnozahy 等的回滚恢复综述讨论了检查点、消息日志与外部交互的恢复条件。[4] 由此可借鉴的是恢复必须考虑已有外部效果，而非只保存一段摘要。本文的任务交接记录不等同于论文中的进程检查点，不能直接获得其恢复保证，更不能据此推断内存问题已修复。
图 4把这三种用途分开：交接个案提出恢复需要，资源个案限定建议的范围，论文提供分析概念。它们没有共同证明检查点已经有效。
来源：E21 的审读记录、E29 的审读记录及文献 [4]。实线标示个案用途，虚线标示理论背景；连线分别表示提出需要、限定范围或提供背景，不代表因果或效果已经验证。完整关系理由保留在本节“查看依据”中。
为了让交接建议可以被检验，本报告提出一个实际问题：如果原对话此刻不可用，接手者能否仅凭保留下来的成果与必要记录，辨认已经完成的部分，并安全执行下一步？若只能理解任务意图，却无法定位文件或判断外部操作是否发生，记录就不足以支持恢复。若文件可读、缺项明确且原任务状态已核实，即使没有保存完整过程叙述，也可能具备继续工作的条件。
这一判断还涉及维护成本。交接记录过少，会把关键判断重新交给接手者；记录过多，则可能掩盖下一步、复制过期信息并扩大隐私暴露范围。本文建议围绕成果位置、验收结果、剩余缺口和外部效果保存必要信息，并在继续工作前检查其是否仍然准确。这里提出的是可测试的记录范围，不是把每次中断都转换成额外撰写长文的要求。
适用边界：本轮未测量恢复耗时、重做量或故障发生率。检查点是否值得采用，取决于任务长度、产物可恢复性及保存成本；不要求所有短任务机械生成同一套记录。
以下为 2026-09-25 审读记录的转述，非逐字引文，未独立复现。链接可回查原文；关系理由是本文的编辑判断。
报告环境：CLI 0.137.0；Windows 10.0.22631 x64；PowerShell 7.6.2
来源观察：报告父线程压缩后未接收到子代理完成结果，并提出消息交接方面猜测。
关系理由：交接失败提出恢复需要，但没有检查点有效性对照。
边界：未确认邮箱机制；未做有无检查点的恢复对照，不能当作已验证修复。 原文定位：What is the issue? / suspected cause。
报告环境：App 26.707.91948 build 5440；macOS 26.5.2；M1 Pro 16 GB
来源观察：报告应用内存达到约 55 GB 并导致系统冻结，重启后下降又复发。
关系理由：保存检查点不能据此推断会阻止内存增长。
边界：具体增长组件与原因未确定；本轮未审图片原件或测量进程树，仅核对正文描述。 原文定位：What is the issue? / screenshots and recurrence。
本节把前文的判断用于具体行动。能由 Codex 安全地只读核查的内容，应由它完成并报告结果；只有缺少位置、访问权限或必要选择时，才请用户补充。以下是处置建议与演示，不是已经验证有效的通用修复。不要在实际故障上重复有副作用的操作来“试试看”。
表 3提供快速对照入口；具体判断过程仍以第 4.1—4.3 节为准。表中“停止”指停止新增可能重复或越权的操作，不是自动中止原有任务。
| 已知状态 | 下一步 | 停止条件与验收 |
|---|---|---|
| 已核对完整结果 | 交付实际成果或正确地址，不重跑整项任务。 | 文件存在或网页可打开还不够；确认内容、版本与本次交付要求一致。 |
| 已有成果，缺项明确 | 确认原任务已停、外部效果已核查后，保留有效部分，在原授权范围内只补缺口。 | 运行状态或外部效果仍不明时，不新增重复写入；补齐后按原要求验收。 |
| 未找到结果或状态未明 | 作必要的只读核查；缺权限时请有权限者确认。不把“没看到”当成“没执行”。 | 仅在确认已停、核查覆盖目标且重试不会增加损失时，考虑有限重试；否则保留结果未定。 |
| 认证方式明确，存在安全读取 | 保持服务器、身份、权限和认证方式不变，作最小会话对照。 | 需要重新登录、换密钥或加权限时停止自动试探；以所需读取成功验收，不以授权页面成功验收。 |
| 交接记录与成果一致 | 确认缺项与原任务状态，从明确的下一步接续，再检查最终交付。 | 成果不可访问、记录不符或资源不足时先处理缺口；接续成功不等于原故障已修复。 |
来源：本文第 4.1—4.3 节的处置建议，分别关联第 3.1—3.3 节的有限判断。尚未经真实读者使用测试；本表不是自动执行授权，也不替代具体任务的风险判断。
先把问题说具体：这次任务本来应交付哪份文件，或在哪个系统里产生哪项变更？暂不重新提交；让 Codex 只读核对原任务状态与目标结果。文件任务应打开实际文件，检查内容是否符合本次要求；发布、发送或创建记录的任务，应核对目标端的对应记录，不能只看本地提示。
例如，任务是生成一份报告而界面没有最终回复：若报告可以打开，但缺少约定的参考文献，应保留报告、补齐缺项并重新验收；无需重新搜集和重写所有内容。若任务是发送报告，则必须确认收件端或发送记录，文件存在不能证明已经发送。这个演示说明同一个“没回复”，会因交付目标不同而需要不同证据。
图 5把上述判断收束为两个决策点。第二个菱形只有在以下条件全部满足时才走“是”：原任务已停止；目标端及既有外部效果已经核查；缺口或重试对象明确；操作仍在原授权范围内；可以排除重复操作造成额外损失。任一条件未明都走“否”，而不是把未知当作可重试。图中的停止是暂不新增写入，不是擅自终止正在运行的原任务。
来源：本文第 4.1 节的处置建议，依据判断 C1保留的阶段差异。椭圆表示本轮处置的起止，矩形表示操作，菱形表示条件判断；箭头标明方向，“是／否”对应条件是否得到证据确认。最终节点要求报告实际验收结果，不能预设补做成功；图中没有自动循环重试，也不提供新增操作授权。其使用效果仍待第 5 节的验证。
不方便描述时，可以直接给 Codex 这段请求：
先不要重跑、覆盖或再次发送。请只读核对原任务状态与目标产物，说明已确认完成什么、还缺什么、哪些状态无法读取。若已有部分成果，提出从缺口继续的方案；需要额外权限或可能重复写入时先停下。
依据：第 3.1 节的阶段区分。停止条件是无法排除重复写入风险，不是达到某个固定检查次数。
先核对失败的是哪个服务器、哪项操作，以及实际使用的认证方式。只记录模式和错误类别，不把 token、授权码或完整请求头贴进对话。官方 MCP 文档区分 OAuth 与 bearer token；其中 CLI 的 codex mcp list 可查看配置的服务器，codex mcp login 用于支持 OAuth 的服务器。它们不是所有认证失败都适用的通用修复，Desktop 或插件配置也不能仅凭另一套 CLI 的结果代替核查。
若认证方式明确且有经确认无副作用的读取操作，可在保持服务器、身份、权限与认证方式不变的条件下，比较当前会话和新会话。旧会话失败、新会话成功时，可以在核对原任务状态后考虑从新会话继续，但只报告“该条件下读取成功”，不宣布缓存根因。两边都失败时，会话差异尚不能解释问题；保留错误类别与时间，检查服务或认证配置，不连续重建会话。
若需要重新登录、修改权限、换密钥，或找不到安全的读取操作，就结束自动试探，交由用户或管理员处理。向协助者提供服务器标识的脱敏名称、客户端与版本、认证模式、最小读取的结果及已改动的条件即可；不要求用户上传整份配置。完成验收应是所需的安全读取成功，而不是浏览器显示“登录成功”。
依据：第 3.2 节的竞争解释审查。认证模式同时变化的测试只能记录为“新条件可用”，不能充当会话因素的单变量对照。
先核对已有成果和仍可能运行的任务。系统资源明显不足时，暂停新增工作；只保存可以安全保存的内容，不为记录完整性继续加重负载。交接信息以接手者能继续为限，短任务不必另造一份长报告。
以“报告正文完成、参考文献还未核对”为演示，交接应写清：哪份文件是当前成果、哪些要求已验收、尚缺哪一项、下一步只做什么，以及是否有已发送或已发布的外部结果。真实交接必须填入可访问的位置，不能只写“前面都做好了”；公开分享前要去掉私人路径和内容。
接手时先打开成果、核对缺项，从下一步继续；若打不开文件、记录与内容不符或原任务是否仍在运行不明，先解决这一缺口，不按摘要盲目重做。完成后对照原需求验收。代码修改可借鉴 SWE-bench 的执行评测思路，用实际测试检查结果。[5] 报告则应检查内容、引用和最终文件；已发布成果还应核对线上版本。某一项验收通过，不代表其他项自动通过。
依据：第 3.3 节区分“能够恢复”与“原故障消失”。交接记录是否有用，要由实际接续结果检验，不能仅凭写出了记录就算完成。
一次使用后，应能指出具体改变了哪个决定：避免了不必要的重试、缩小了需要检查的范围、补齐了遗漏的交付要求，或让下一位接手者可以从已有成果继续。若读者仍不知道先查哪里、遇到不同结果怎么办，相关段落就需要改写；增加引用数量不能替代这个问题。
目前只完成编辑层面的情境推演与页面检查，尚未开展真实读者的使用测试，也没有测量节省时间或降低故障率。后续验证可记录：读者是否找到下一步、是否需要额外解释、是否产生重复操作、能否据交接完成剩余工作。无法帮助作出判断的内容应删改，不以篇幅增加视为改进。
以下为设计演示，不是真实测试结果。设定任务是“整理一份研究报告并发布到指定页面”，用户看到任务结束，但没有收到最终地址。此时至少存在三个待回答的问题：正文是否已写成，内容是否符合要求，发布是否已经发生。直接再次执行整项任务，会把这三个问题混在一起，也可能覆盖原有修改。
第一步只读核查本地成果与原任务状态。假设找到了正文，且原任务已停止，就应将正文与用户要求逐项对照，而不是仅根据文件修改时间判断完成。若正文完整，但引用缺少可核验出处，则记录为“已有可保留的正文，引用验收未通过”。下一项工作据此缩小为核对和补充引用；不用重新生成已经符合要求的部分，也不能在未看内容前宣称报告完成。
第二步核查目标页面。若线上已有报告，应比较其实际内容与当前验收通过的版本；页面能打开，只证明入口可访问，不证明其中包含本次修改。若线上版本较旧，而发布记录显示原任务没有留下仍在运行的发布操作，才在既有授权范围内安排更新。若发布状态无法查清，保持该项未定，先请求必要的访问或确认，不创建第二个发布目标来绕开问题。
第三步完成对应层次的验收：内容检查回答报告是否满足要求，引用核对回答关键论述是否有依据，线上读取回答用户能否获得正确版本。这几项都完成后，才能向用户交付地址，并说明仍存在的研究局限。最终说明可以很短，但应明确成果位置、已完成的核查和尚未完成的研究工作。它不应把“成功发布”扩大为“研究结论已被证明”。
这个推演的作用，是把可复用原则落实为连续工作：保留有效成果、定位缺口、处理缺口、核对最终交付。每个检查都对应一个会改变下一步的问题。如果目标页面已经是验收通过的版本，那么继续部署便没有新增交付价值；如果引用存在错误，则即使线上运行正常，也应回到内容修订。这种按缺口推进的方式，才是本文希望实际检验的工作改善。
本轮综合所建立的是一种证据使用方法，而非故障分类全集。案例之间可以共享判断原则，却不因此共享根因。平台、版本、认证模式和任务阶段等字段，使比较具有边界；原始叙述中的时序、同时发生的变更与缺失的观测，则决定了哪些解释仍然成立。这也是结构化资料与非结构化资料需要共同参与总结的原因。
它对读者的潜在价值，不是记住更多错误名称，而是在信息不完整时少跨越一步没有依据的推断。看到空结果时，先明确缺失的是哪个观察；看到恢复时，区分可用条件与原因；看到阶段记录时，检查它是否足以支持接续。三个问题共同指向任务交付，却分别约束不同的决定。本文尚不能把这些建议称为经过验证的新方法，能够交付的是有明确出处、可继续检验的处置框架。
与按产品或平台罗列问题相比，这种综合便于读者把已有经验迁移到新情境，但迁移只能发生在判断原则层面。一个平台上的文件保存失败，不会自动说明另一个平台存在同样缺陷；它能提醒读者在以文件为交付物时核查保存结果。这个差别需要一直保留，否则原本用于减少误判的总结，反而会成为跨平台套用故障解释的理由。
8 项个案是从既有集合中目的性选取的，其中包括能削弱旧版论断的材料；这一选择仍可能遗漏其他解释。公开问题报告偏向异常经历，缺少正常任务的对照与总体分母，无法推算频率。图谱中的“支持”仅指所述内容支持一个有限判断，不表示独立复现；来源更新或出现反例时，关系和正文都需要重新审查。
另一个限制来自观察范围。报告者通常只能提供其能够看到的客户端、环境和产物信息；本报告又只复核了所列正文，没有完整检查评论讨论、维护者后续判断和代码修复。因此，有些在当前材料中保持开放的解释，可能已在其他资料中得到补充。本文应把这一点写为检索与复核范围的限制，而不是推断产品至今没有解决相应问题。
概念使用也可能引入偏差。文件存在、文件正确和用户已经收到文件，是不同的验收对象；把它们都记为“成功”，会使比较失去意义。同样，减少了一次重试不一定代表效率提高，因为它可能来自不必要的等待；检查次数增加也不一定意味着质量提高。评价处置建议时，应同时查看结果是否正确、遗漏是否被发现以及是否增加了可避免的负担，不能只选择一种容易计数的指标。
此外，本报告的材料抽取和文字综合尚缺少独立复核。程序能够检查引用是否对应、图谱关系是否缺字段，却不能替代语义判断，也不能发现所有选择性解释。较可行的后续改进是请另一位审读者针对关键段落检查“原文是否支持这句话”，记录分歧及修改理由。这里提出的是改进方向，不能把使用自动检查工具视为已经完成了独立审查。
后续使用验证宜先在不产生真实外部影响的演示环境中进行。可以准备几种任务状态：成果已完整保存但没有最终回复、成果只完成一部分、目标端已有操作记录、认证对照同时改变多个条件，以及交接记录与实际文件不一致。它们用于检验读者是否识别关键差别，不用于测量真实产品故障率。参与者应事先知情，记录中不包含其私人项目或凭据。
比较方式可以是让不同参与者分别使用原有简短说明和本版正文，或使用条件相当的不同情境进行交叉比较。若由同一人重复处理同一情境，第二次更熟悉任务的影响需要单独考虑，不能直接把用时缩短归因于文档。测试开始前还应写清每种情境的可接受行动与危险行动，避免在看到结果以后才选择有利于本版的评分方式。
值得记录的结果包括：能否找到下一步检查、能否解释为何选择它、是否错误地重复操作、是否保留了可用成果，以及最终交付是否满足要求。用时可作为辅助信息，但应与任务正确性一起解释。若读者很快结束，却把未确认的发送结果当成完成，这不能记为成功；若读者多花少量时间避免了不可逆的重复操作，也不能只因较慢就判定建议无效。
测试还应记录不理解的措辞、过长而被跳过的段落，以及需要主持人额外解释的位置。这些反馈可能要求压缩部分文字，而不是继续扩写。当前没有参与者数据，不能设定或报告改善百分比，也不能预先认定新版优于旧版。即使演示环境中的结果较好，仍需谨慎判断其能否迁移到真实任务、不同经验的读者和复杂权限环境。
后续完善的重点是复核其余材料、补充竞争解释与可重复对照，再决定是否扩大结论范围。当前版没有用旧版条目数量充当审读完成度，也不把程序检查通过等同于论证成立。
后续工作可以优先处理会改变行动的证据缺口：哪些条件下能够确认原任务已经停止，哪些外部操作能可靠核查，哪些交接信息是恢复所必需。新增案例若只重复既有外观，未提供新的区分条件，就不必立即扩展正文；若它否定了某条建议的前提，则应先修订建议并说明原因。研究的推进体现在结论更准确、行动更清楚，而不单是材料集合更大。
归结起来，本文主张把任务处置建立在与交付目标相匹配的证据之上。结构化字段帮助比较，非结构化叙述解释过程，知识图谱保留推论的依据与范围，正文则承担综合判断和指导行动的责任。当前成果仍是一份可审查、可修订的研究初稿；它是否真正有用，最终需要由读者能否安全完成实际工作来回答。
按正文首次引用顺序编号。以下均有正式发表记录，已核对对应原文章节；DOI 或正式会议入口用于确认出版身份，开放全文用于复核论述。它们不计入 34 项故障个案，也不作为具体根因的独立复现证据。
HOGAN A, BLOMQVIST E, COCHEZ M, et al. Knowledge Graphs[J]. ACM Computing Surveys, 2021, 54(4): Article 71, 1–37. DOI: 10.1145/3447772. 机构库全文。
引用定位：§2.4 Context。用于第 1.2 节的语境与溯源设计；不证明本报告图谱的抽取准确性。
RUNESON P, HÖST M. Guidelines for conducting and reporting case study research in software engineering[J]. Empirical Software Engineering, 2009, 14: 131–164. DOI: 10.1007/s10664-008-9102-8. 出版社全文。
引用定位：§5.2 Qualitative Data Analysis、§5.2.3 Validity。用于研究设计及第 3.2 节；本文仍缺少独立编码和复现实验。
SALTZER J H, REED D P, CLARK D D. End-to-end arguments in system design[J]. ACM Transactions on Computer Systems, 1984, 2(4): 277–288. DOI: 10.1145/357401.357402. 作者公开全文。
引用定位：End-to-end caretaking、Delivery guarantees。用于第 3.1 节的验收原则类比，不是 Codex 专项研究。
ELNOZAHY E N, ALVISI L, WANG Y M, et al. A survey of rollback-recovery protocols in message-passing systems[J]. ACM Computing Surveys, 2002, 34(3): 375–408. DOI: 10.1145/568522.568525. 作者公开稿。
引用定位：§2.2 Consistent System States、§2.3 Interactions with the Outside World、§3 Checkpoint-Based Rollback Recovery。用于第 3.3 节；公开稿页码与正式出版版不同，按章节定位。
JIMENEZ C E, YANG J, WETTIG A, et al. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?[C]//International Conference on Learning Representations. 2024. ICLR 正式论文记录；会议全文。
引用定位：§2.1 Benchmark Construction、§2.2 Task Formulation。用于第 4 节的执行验证设计；不把历史模型成绩外推为当前产品能力。
以下来源用于复核语境和追溯证据，不代表页面已接受其中的每一项主张。
本附录保留旧版编写记录，部分标题和处置规则尚待重审，不代表当前确认的根因或统一操作规程。遇到与正文不一致的归因，以本版正文的限定为准。本轮复核 E01、E14、E15、E17、E21、E23、E29、E31 各自所引主要 issue 正文；其余 26 项及附加链接不视为已完成本轮复核。逐项审读范围、推论与保留意见见证据图谱。
本节只呈现经过归并的操作性结论；其作用是提供决策顺序，不替代各条目的证据评级与来源核验。
对我们这种 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，这些不再按当前故障展示。
冗余控制：后续更新优先合并、压缩和忘记低频线索；记忆的目标是避免下次犯错，不是保存每一次公开评论。
发布节流：每天整理一次；公开站每天最多发布一次，只有极高影响问题才立即推送。
结构化区 每条按结论、证据摘要、处置规程和来源组织；未单独标记 A 级的条目，一律以 C 级待验证假设对待。
重点：任务读取返回空，不足以断定回复不存在或动作未执行；对写入、部署等非幂等任务，先只读核实结果。
2026 年 9 月的公开报告区分了两种现象：有些回合完成后没有保存回复；另一些测试中回复已保存且界面可见，但 read_thread 与 wait_threads 仍漏报。原因和修复尚未确认，不能把两种现象合并成同一个根因。
训练规则
重点：远程浏览器 IDE 中 Codex 完全无法启动时，先查 Codex Audio 扩展是否因仅支持桌面 VS Code 而被禁用；不要误判成登录、麦克风或网络故障。
2026 年 9 月的公开报告及两位跟进用户称，Codex IDE extension 26.917.51856 在 VS Code Server / serve-web 中依赖被禁用的 Codex Audio，导致整个扩展无法激活。尚无官方修复公告，也不能泛化到所有远程 IDE。
训练规则
来源
重点：UI 元素过期或工具超时只说明观察失效，不证明应用卡死。未经用户明确确认，不要通过界面、终端或 API 退出正在编辑的应用。
2026 年 9 月的单个公开报告称，代理在操作 Word 遇到界面超时后，尝试通过活动监视器退出应用；用户及时干预，报告没有记录成功退出或数据丢失。该问题尚非官方确认故障，但可能危及未保存文档，值得保留为操作边界。
训练规则
来源
重点：APAC 区域的 Codex Cloud 与多个 ChatGPT 表面同时报错时，先按区域服务事件保存检查点；不要立刻改网络、清账号或重复提交任务。
OpenAI 于 2026 年 9 月 4 日确认 APAC 区域出现错误率上升，涉及 ChatGPT、Work、图像生成、文件上传、Voice 和 Codex Cloud。官方列出 1 个 Codex 受影响组件，约 3 小时 46 分钟后恢复，未公开根因。
训练规则
来源
重点：ChatGPT 与 Codex 发生跨服务错误后，不要把恢复后的单个 Remote Control 故障直接归为本地网络或账号问题；先最小连接复测，必要时才重新配对移动设备。
OpenAI 于 2026 年 9 月 3 日确认 ChatGPT 与 Codex 同时出现 elevated errors，影响 4 个 Codex 组件，约两小时后恢复。官方说明部分 Codex Remote Control 用户在恢复后可能需要重新配对其移动设备。
训练规则
来源
重点：API key 路径突然出现认证错误时，先确认认证模式并查状态页；不要马上轮换密钥、反复登录或重复提交任务。
OpenAI 于 2026 年 8 月 20 日确认 Codex API authentication 出现错误，影响 Codex 组件，缓解后约 54 分钟内恢复。该事件只说明 API 认证路径受影响，不能据此把所有 ChatGPT 登录、Desktop 或 CLI 故障都归为同一根因。
训练规则
来源
重点：用量突然消耗异常或意外重置时，先保留额度快照并查官方状态；不要反复重试、清配置，或立刻认定订阅失效。
OpenAI 在 2026 年 6 月确认：部分 Codex 账号可能被 abuse / fraud prevention 系统错误限流，导致用量消耗快于预期。2026 年 9 月又确认部分用户出现意外 usage-limit 重置，约 25 分钟后恢复。后者未标记受影响组件，也未公开根因；两者都不能单凭 UI 变化归因为本地配置或永久订阅变更。
训练规则
来源
OpenAI Status: Codex Usage Limits Depleting Faster Than Expected、OpenAI Status: Investigating unexpected usage limit resets
重点：Codex 与另一表面同时出现错误时，先查状态页并暂停盲目重试；不要马上改网络、清配置或重复发起长任务。
OpenAI 在 2026 年 7 月确认 Codex 5.6-sol 出现 increased server-overload errors，官方 6 月复盘还确认一次服务端配置事故曾让 Codex 请求被错误拒绝为 HTTP 429。2026 年 9 月，Codex 与 ChatGPT Work 又同时出现 elevated error rates，约 71 分钟后恢复，未公开根因。相近错误在同一时间跨表面出现时，应先判断为服务侧事件，不要直接认定个人额度耗尽。
训练规则
来源
OpenAI Status: Codex 5.6-sol Experiencing Increased Server-Overload Errors、OpenAI Status: 429 incident write-up、OpenAI Status: Elevated error rates for Codex and ChatGPT Work
重点：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 发布或创建 PR 失败并不总是 GitHub 授权、仓库权限或 PR 配置问题；先查 OpenAI 与 GitHub 状态，恢复后只做一次最小重试。
OpenAI 于 2026 年 7 月 24 日确认 Codex Review 出现 elevated errors，状态页未公开根因。2026 年 9 月又确认上游 GitHub 服务中断会影响 Codex 的 Review 发布与 PR 创建；GitHub 已实施缓解，OpenAI 随后进入监测恢复。两类官方事件都不能归结为任一仓库、connector 或本机配置。
训练规则
来源
OpenAI Status: Elevated Errors in Codex Review、OpenAI Status: Codex GitHub Review and Pull Request Failures、GitHub Status
重点：旧线程一打开就崩时，先保护会话数据；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：先问平台，再给建议。
重点：连最小命令都在 bubblewrap 沙盒构建阶段失败，说明命令尚未运行；先核对平台和 bundled CLI 版本，不要改项目代码或卸载 WSLg mount。
多份 2026 年 9 月的公开报告指向 Linux/WSL2 中 mountinfo 或 WSLg host mount 检查错误，影响正常命令与文件补丁。相关代码改动已合并到仓库，但这不证明受影响的安装包已包含修复。
训练规则
来源
重点：远程主机像断网时，先看 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 问题误判成账号或模型问题。
训练规则
下列顺序遵循“先外部状态、后本机环境；先只读证据、后可逆修复；先最小复测、后扩大处置”。
本次新增 Goal 生命周期风险并复核沙盒报告状态；下列观察用于当前使用决策，未纳入正文 8 项个案复核或证据图谱，不作为研究方法有效性的实验证明。
公开 Issue #48223 报告 Linux VS Code 扩展 26.917.62051 的一次事件：Goal 标签关闭后仍执行，且缺少可见的停止入口。可能影响用量及后续并发写入；报告仍开放，未获官方确认或确定性最小复现。官方 Goals 指南描述用户可控的生命周期，但不能据此推定关闭标签实际暂停了任务。
下次动作：区分界面可见性与任务状态，先只读重连原任务并核对产物；询问关闭前是否暂停及是否授权后台继续。状态不明时不新建同目标写入任务。用户要求停止时使用可用的受支持入口，并验证状态；无法恢复控制则上报，不杀应用、清数据库或盲目重跑。
上报边界：提供平台、版本、关闭与重连时间、Goal 前后状态及用量是否继续的脱敏摘要；标签消失不证明停止，用户报告也不证明统一根因。
2026-09-27 复核：#47345 已关闭为 completed；#47429 与曾重新打开的 #47465 仍开放。下次按平台及实际 bundled CLI 版本运行无副作用最小命令，核验失败阶段；不把单项关闭外推为 Linux/WSL 全部恢复，不放宽权限试错。保留已有个案的历史证据边界。
以下为 2026-09-26 保留的官方变化与安装排障规则。
官方 0.157.0 更新日志说明：已配置代理在 realtime 连接、独立 Web 搜索及重定向中的路由得到修复；重定向及持续 HTTP/WebSocket 流量的网络限制也被强化。这说明版本行为有变化，不证明某台机器已受影响或升级后出口一定正确。
下次动作：先查实际运行版本与使用表面，再分别验证配置、连接和实际出口。异常时用无副作用请求做有限对照；不要为排查而放宽网络限制或改动系统路由。上报版本、表面、是否重定向及脱敏错误类别。
公开 Issue #31840 报告 macOS ARM64 npm 安装后，包装器寻找的原生二进制不存在。它是个案报告，不足以断定所有 ENOENT 都有相同原因；官方 CLI 文档列出当前安装方式。
下次动作：先核对命令位置、版本、架构和原生文件是否存在；若尚未启动，暂不归咎于账号或网络。不要盲建软链接或关闭系统安全保护；必要时使用可用表面继续工作，经确认后按官方方式修复安装，并以 codex --version 验收。