操作前，先核清恢复显示的智能体审批

重连后，一张审批卡片再次出现。你认得文件名，也记得自己曾经同意。操作前，先确定这张卡片对应哪一个原始请求，以及那个请求后来发生了什么。重复出现的卡片可能描述一项已经完成的操作、一项尚未解决的操作，也可能描述一项与当前任务关系不明的操作。

在记录中保留有效的人类授权。重连本身并不意味着用户必须再次授予相同权限。它也不能证明宿主应用已经批准某个具体工具请求，或该操作已经执行。

这份核对表帮助你在现有历史记录足以支持判断时，选择下一步。如果宿主应用无法可靠识别请求，就暂缓受影响的操作，并说明缺少哪些证据。核对表无法修复宿主应用的审批路由。

分清四件容易被当成同一次审批的事

如果原始任务历史和宿主应用支持的控件能够提供可靠的对应关系，就使用它们。相似的标题或相同的文件名可以帮助查找，但单凭这些不能确定归属。智能体的记忆或生成的摘要只是待核查的线索，不能替代原始决定记录。

如果宿主应用不提供请求标识符或回合标识符，就写明“不可获取”。不要为了填满一行而编造标识符。可靠的对应关系可能需要通过宿主应用支持的原始视图确认；如果该视图仍无法消除歧义，就明确保留这份歧义。

从两个小请求开始

以下示例中的所有内容都是虚构的：会话、文件、标识符、决定和结果。这些标签是供人使用的核对表标签，并非宿主应用的原生字段或恢复 API。引用的读取结果来自以下专门编写的样例；没有针对这些样例实际运行任何工具。

/example/alpha/alpha-note.txt
1: Header label: Open draft
2: Comment: keep the existing spacing.

/example/beta/beta-note.txt
1: Status label: Waiting for review
2: Helper text: Check the current draft.

基线包含两项操作：读取 Alpha 的第一行，以及读取 Beta 的第一行。两者都不会修改文件，也不会向虚构任务之外发送任何内容。

完整的基线历史如下：

1. 在 S-A 中，用户留下 H-A 授权记录。智能体在 T-A1 期间提交 R-A1。
2. 宿主应用的实际审批关卡记录了对 R-A1 的批准。随后读取完成，返回 Alpha 的第一行。核对表将此称为“已消耗（consumed）”：虚构历史记录的是操作完成，而不只是一次点击。
3. 在 S-B 中，用户留下 H-B 授权记录。智能体在 T-B1 期间提交 R-B1，仅请求读取 Beta 的第一行。该请求在宿主审批关卡仍处于待审批状态。
4. 连接中断。重连后出现一张卡片。此时，单凭它的显示位置已不足以确定它所属的会话。

H-B 的范围被有意设定得比已提交请求更宽：获准查看两行，不会改变 R-B1 只请求第 1 行的参数。当恢复显示的卡片出现不同参数时，这一区别很重要。

以下四个分支都是从同一基线出发的独立备选情形，并非连续发生的四个事件。

分支 1：已完成的请求再次出现

卡片描述 R-A1、S-A、T-A1 和 Alpha 第 1 行。可靠的原始记录将这些信息与断线前已经记录的批准、已完成读取及结果关联起来。

将重复卡片与已完成的历史记录核对清楚。 记录界面显示的待审批状态与已知已完成请求之间的冲突。不要为了让卡片消失而批准、拒绝或重复读取。记录中已经有标题任务所需的结果。

分支结束时，R-A1 仍被记录为已批准且已完成。没有新增第二次决定或执行。在宿主应用允许的情况下，任务可以使用已知结果，继续下一项已获授权的步骤。如果过期卡片阻碍后续工作，通过受支持的求助途径报告这一具体不一致；不要声称界面已经修复。

如果无法关联到这个确切请求，仅凭“我之前批准过”并不充分。在这里，请求身份和完成证据共同支持了这项判断。

分支 2：卡片归属未知

一张卡片出现在 S-A 下，描述读取 Beta 第 1 行。它没有提供与原始请求或回合之间的可靠关联，核查者也无法获取 Beta 的原始视图。示例作者知道 R-B1 曾经存在；看到这张卡片的人却无法确定它就是 R-B1。

暂缓处理无法建立对应关系的卡片。 记录最少必要的操作描述，以及缺失的归属证据。不要因为它出现在 S-A 下就推断它属于 S-A，也不要仅因它提到 Beta 文件就推断它属于 S-B。

H-B 仍然有效。要求用户重复 H-B 授权，无法补足缺失的请求身份。如果之后可以获取受支持的原始历史记录，就从中寻找可靠关联。在此之前，分支结束时卡片仍未解决，没有新的审批关卡决定，也没有任何执行被归到它名下。

在可行的情况下，继续其他不相关且已获授权的工作。不要创建替代请求，也不要通过操作另一张卡片来清除这张归属不明的卡片。如果始终无法建立对应关系，有用的结果就是准确说明哪些事实仍无法确定。

分支 3：参数发生变化

恢复显示的卡片声称对应 S-B / T-B1 中的 R-B1，但请求的是 Beta 第 2 行。可靠的原始 R-B1 记录请求的却是第 1 行。熟悉的请求标签无法消除这项请求载荷不一致。

暂缓受影响的操作，同时核对并厘清变化后的参数。 同时保留以下两种描述：

原始 R-B1：/example/beta/beta-note.txt，仅第 1 行
声称对应 R-B1 的恢复卡片：/example/beta/beta-note.txt，仅第 2 行
先前 H-B：允许查看两行中的任意一行或两行，只读
已知原始宿主决定：待审批
已知执行：无

第 2 行既然已在 H-B 范围内，就没有必要要求人类再次授予相同的宽范围权限。尚未解决的问题是：宿主应用正在呈现哪一个具体请求，它与原始请求是什么关系。

分支结束时，变化后的卡片被暂缓处理；在最后核实的记录中，原始 R-B1 仍处于待审批状态。没有第 2 行的读取结果。没有证据，就不要将原始请求标记为已取消、已替换或已完成。

如果宿主应用支持的控件之后能够确认一个已更正或确实新建的请求，就比较它的实际参数，并对该请求执行真实的审批关卡流程。这份核对表无法创建更正、将某个决定转移到变化后的载荷，也无法证明替换已经发生。如果变化后的操作超出了现有人类授权，还需要解决这一具体新增范围的授权问题。

分支 4：确切的原始待批请求已核实

卡片出现在 S-A 下，但可靠、受支持的原始记录确认，它对应 S-B / T-B1 中的 R-B1，请求读取 Beta 第 1 行。原始请求仍处于待审批状态，之前没有决定或执行。H-B 覆盖这项操作。

通过宿主应用支持的原始控件，继续处理已核实的原始请求。 不要操作对应关系仍不确定的控件。不要把 H-B 当作已经消失，要求用户重新陈述。任何实际存在的宿主审批关卡仍然具有约束力。

本纸面示例明确设定了分支剩余部分的过程：

1. 原始控件与 R-B1 及其第 1 行参数之间的关联已可靠确认。
2. 宿主审批关卡记录了对同一个待批请求的批准。
3. 读取完成，结果与 R-B1 关联：Status label: Waiting for review。

只有完成第 3 步之后，核对表才记录读取已完成。如果审批关卡接受了决定，但无法获取结果，就记录已批准，并将执行情况保留为未知。成功读取为措辞任务提供了证据；它不代表整项任务已经验收通过。

这里的“继续”描述的是有依据的工作流程步骤。它不是自动批准请求的指令，不是一项 API 操作，也不能替代宿主应用的控件。如果无法可靠识别原始控件，就改为暂缓处理。

将卡片与原始历史记录比较

这些处理结果也适用于不那么整齐的历史记录。对于已经确定身份的请求，已记录的拒绝仍然是拒绝；不要把重连视为重放它的许可。如果请求已获批准，但结果未知，接下来要查的是执行证据。再点击一次批准无法回答这个问题。记录存在冲突时，保留冲突，而不是选择最方便推进的状态。

复制这份状态核查请求

用它对现有历史记录进行只读检查。它不授权任何操作，也不改变审批关卡。

操作前，将恢复显示的审批与原始任务历史核对。在能够可靠获取的情况下，识别原始目标、所属会话、回合和请求；将缺失的标识符标记为不可获取。比较确切操作、目标及参数与显示卡片是否一致。保留此前已经给出的任何有效人类授权，并分别报告原始宿主决定、执行证据和结果。不要根据卡片显示位置或相同文件名推断身份。核查期间，不要批准、拒绝、重放、重新发出请求、安装、重置或更改策略。返回已确认事实、未知项、冲突，以及一个具体下一步：通过已可靠识别且受支持的原始控件继续，暂缓受影响的操作，或核对并厘清某项具体不一致。真实的宿主审批关卡仍然具有约束力。如果现有历史无法建立对应关系，就如实说明，不要编造字段或恢复 API。

有用的核查结果应当具体：“H-B 覆盖这次读取，但卡片请求第 2 行，而原始待批 R-B1 请求第 1 行。暂缓变化后的卡片；在受支持的原始视图中核实请求。”它既保留现有权限，也说明缺失的证据。

这套方法适用于哪里

这是一种人工推理辅助方法，适用于能够访问相关原始记录的人或智能体。当重连带来归属不明的卡片、重复的决定，或显示参数与历史记录不一致时，它可以提供帮助。它无法补出隐藏的宿主状态，无法撤销已执行的操作，无法推翻拒绝，也无法保证两个相似请求就是同一个。

促成这套方法的公开线索，是一条 Codex CLI 问题报告，称重连后审批和输出出现在不相关的会话中。报告提到的版本是 0.160.0。这是报告者的描述，并非独立复现的缺陷，也不是当前行为的证据；本文不对其成因或目前修复状态作出判断。

报告自己遇到的、尚未解决的不一致时，只包含相关请求描述、可获取的关联证据、最后核实的决定、已知执行情况，以及重连后发生了什么变化。隐去凭据和不相关的任务内容。通过受支持的方式保留原始记录。这样，下一位接手者就有一项具体差异可调查，同时有效授权和实际宿主控件也得以保留。