Reconcile a Recovered Agent Approval Before Acting

An approval card returns after a reconnect. You recognize the filename and remember saying yes. Before acting on it, establish which original request the card represents and what happened to that request. A repeated card might describe a completed action, an unresolved action, or an action whose connection to the current task is unknown.

Keep valid human authorization in the record. Reconnecting does not, by itself, mean the user must grant the same permission again. It also does not establish that the host approved a particular tool request or that the operation ran.

This worksheet helps you choose a next step when the available history supports one. If the host cannot reliably identify the request, leave the affected action on hold and describe the missing evidence. A worksheet cannot repair a host's approval routing.

Separate four things that can look like one approval

Use the original task history and supported host controls where they provide reliable correlation. A similar title or matching filename can help you search, but cannot settle ownership alone. An agent's recollection or generated summary is a lead to check, rather than a replacement for the original decision record.

If the host does not expose a request or turn identifier, write “unavailable.” Do not manufacture identifiers to make a row look complete. Reliable correlation may depend on the host's supported original view; if that view still leaves ambiguity, keep the ambiguity visible.

Start with two small requests

Everything in the following example is fictional: sessions, files, identifiers, decisions and results. The labels are human worksheet labels, not native host fields or a recovery API. The quoted read results come from these authored fixtures; no tools were run against them.

/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.

There are two baseline actions: read Alpha's first line and read Beta's first line. Neither changes a file or sends anything outside the fictional task.

The complete baseline history is:

1. In S-A, the user records H-A. The agent submits R-A1 during T-A1.
2. The host's actual gate records approval for R-A1. The read then completes, returning Alpha's first line. The worksheet calls this “consumed”: the fictional history records completion, rather than merely a click.
3. In S-B, the user records H-B. The agent submits R-B1 during T-B1, requesting only Beta's first line. That request remains pending at the host gate.
4. The connection drops. After reconnect, a card appears. Its display location is no longer enough to establish its owning session.

H-B intentionally covers more than the submitted request: permission to inspect both lines does not change R-B1's line-1 arguments. This distinction matters when the recovered card shows different parameters.

The four branches below are independent alternatives starting from this same baseline. They are not four consecutive events.

Branch 1: a completed request reappears

The card describes R-A1, S-A, T-A1 and Alpha line 1. Reliable original records connect those details to the approval, completed read and result already recorded before disconnect.

Reconcile the repeated card with the completed history. Record that the displayed pending state conflicts with the known completed request. Do not approve, deny or repeat the read just to dismiss the card. The record already contains the result needed for the header task.

The branch history ends with R-A1 still recorded as approved and completed. No second decision or execution is added. Where the host permits, the task can use the known result for its next authorized step. If the stale card blocks further work, report that specific mismatch through a supported help path; do not claim the interface has been repaired.

“I approved it earlier” would be insufficient without the connection to this exact request. Here, the decision is supported by both identity and completion evidence.

Branch 2: the card's owner is unknown

A card appears under S-A and describes reading Beta line 1. It exposes no reliable connection to an original request or turn, and the original Beta view is unavailable to the person checking it. The example author knows that R-B1 existed; the person seeing this card cannot establish that it is R-B1.

Hold the uncorrelated card. Record its minimal action description and the missing ownership evidence. Do not infer that it belongs to S-A because it appears there, or to S-B merely because it names a Beta file.

H-B remains valid. Asking the user to repeat H-B would not supply the missing request identity. Look for a reliable connection in the supported original history if it becomes available. Until then, the branch ends with the card unresolved, no new gate decision and no execution attributed to it.

Continue unrelated authorized work where practical. Do not create a substitute request or act on a different card as a way to clear the uncertain one. If correlation remains unavailable, the useful outcome is a precise account of what cannot yet be established.

Branch 3: the parameters changed

The recovered card claims to represent R-B1 in S-B / T-B1, but it requests Beta line 2. The reliable original R-B1 record requests line 1. A familiar request label cannot resolve this payload mismatch.

Reconcile the changed arguments while holding the affected action. Keep both descriptions visible:

Original R-B1: /example/beta/beta-note.txt, line 1 only
Recovered card claiming R-B1: /example/beta/beta-note.txt, line 2 only
Prior H-B: inspecting either or both lines is permitted, read only
Known original host decision: pending
Known execution: none

There is no need to demand the same broad human permission again merely because line 2 is within H-B. The unresolved question is which concrete request the host is presenting and how it relates to the original.

The branch ends with the changed card held and the original R-B1 still pending in the last verified record. There is no line-2 result. Do not mark the original canceled, replaced or completed without evidence.

If supported host controls later establish a corrected or genuinely new request, compare its actual arguments and apply the real gate to that request. This worksheet cannot create that correction, transfer a decision to a changed payload or certify that a replacement occurred. If the changed action instead exceeds existing human authorization, resolve that specific new scope as well.

Branch 4: the exact pending request is verified

The card appears under S-A, but reliable supported original records establish that it represents R-B1 in S-B / T-B1, requesting Beta line 1. The original request is still pending, with no previous decision or execution. H-B covers the action.

Continue with the verified original request through the host's supported original control. Do not act on a control whose connection remains uncertain. Do not ask the user to restate H-B as though it had vanished. Any actual host approval gate remains binding.

For this paper example, the remainder of the branch is stipulated explicitly:

1. The original control is reliably associated with R-B1 and its line-1 arguments.
2. The host gate records approval for that same pending request.
3. The read completes and its result is associated with R-B1: Status label: Waiting for review.

Only after step 3 does the worksheet record a completed read. If the gate accepts a decision but the result is unavailable, record approval and leave execution unknown. A successful read supplies evidence for the wording task; it does not accept the whole task.

“Continue” here describes a justified workflow step. It is not an instruction to automatically approve requests, an API operation or an alternative to the host's controls. If the original control cannot be reliably identified, use the hold outcome instead.

Compare the card with the original history

These outcomes also help with less tidy histories. A recorded denial remains a denial for its identified request; do not treat reconnecting as permission to replay it. If a request was approved but its result is unknown, the next question concerns execution evidence. Another approval click does not answer that question. When records conflict, preserve the conflict rather than choosing whichever state makes progress easiest.

Copy this state-check request

Use this for a read-only examination of available history. It does not authorize an operation or change a gate.

Check the recovered approval against the original task history before acting. Identify the original goal, owning session, turn and request wherever reliably available; mark missing identifiers unavailable. Compare the exact action, target and arguments with the displayed card. Preserve any valid human authorization already given, and separately report the original host decision, execution evidence and result. Do not infer identity from the card's display location or a matching filename. Do not approve, deny, replay, reissue, install, reset or change policy during this check. Return confirmed facts, unknowns, conflicts and one concrete next step: continue through a reliably identified supported original control, hold the affected action, or reconcile a specific mismatch. Real host gates remain binding. If the available history cannot establish correlation, say so without inventing fields or a recovery API.

A useful check result is specific: “H-B covers this read, but the card requests line 2 while the original pending R-B1 requests line 1. Hold the changed card; verify the request in the original supported view.” It preserves the permission that exists and names the evidence that is missing.

Where this method applies

This is a manual reasoning aid for a person or agent with access to relevant original records. It is useful when a reconnect produces an ambiguous card, a repeated decision or a disagreement between displayed arguments and history. It cannot supply hidden host state, undo an executed action, override a denial or guarantee that two similar requests are the same.

The motivating public signal is a Codex CLI issue reporting approvals and output appearing in unrelated sessions after reconnect. The report names version 0.160.0. It is a reporter's account, not an independently reproduced defect or evidence of current behavior; this article makes no claim about its cause or present fix status.

When reporting your own unresolved mismatch, include only the relevant request description, available correlation evidence, last verified decision, execution knowledge and what changed after reconnect. Redact credentials and unrelated task content. Preserve the original record through supported means. That gives the next person a concrete discrepancy to investigate while leaving valid authorization and actual host controls intact.