Native Guardian approval is recorded before retry, but identical MCP action is rejected again

Native Guardian approval recorded, but identical MCP retry rejected

A client using Codex App Server and automatic review calls thread/approveGuardianDeniedAction for a concrete denied MCP action. The native API records its developer approval before the next user turn. An identical subsequent MCP call is nevertheless rejected by automatic review, which treats authorization evidence as untrusted.

Runtime

Director uses its dedicated Codex CLI 0.153.4 binary, with @agentclientprotocol/codex-acp 1.11.0, automatic review enabled, on macOS arm64. The unrelated shell PATH binary is not the runtime under test.

Observed sequence

1. A harmless synthetic reply through an MCP publish_reply tool is denied.
2. The human clicks Approve once on a UI showing the complete exact reply.
3. The client submits the retained current denial event to thread/approveGuardianDeniedAction; the call returns successfully.
4. At 14:42:57.738 UTC, the session rollout records the native developer approval and an allowed outcome for this MCP action.
5. At 14:42:58.090 UTC, the next user turn begins.
6. The agent retries the same MCP server, tool, and full argument object. Equality was verified without retaining the arguments in the report.
7. The retry receives another automatic-review denial. No reply is sent.

The earlier successful reproduction used the same session and exact-argument retry. This shows inconsistent behavior, not a reliable authorization mechanism.

Boundaries

Automatic review remained enabled. The client did not fabricate a developer marker, change approval policy, substitute another sending tool, or retry approval twice. The approval UI correctly became a terminal failure row with no approval button. Synthetic feed cards were removed; the spent approval and failure record remain for evidence.

Expected

A supported native approval of one concrete denied action should reliably be recognized for the matching retry, or the native API should provide a deterministic failure explaining why it cannot authorize it.

Unknown

Whether the reviewer context omitted the native approval, misclassified it, or interpreted its MCP action scope incorrectly. The reviewer’s private context is unavailable. The observed marker ordering rules out the client starting the retry before the approval was recorded; it does not prove the reviewer received that marker.

Local evidence (private; not attachments for publication)

• native-marker-order.json: native approval precedes retry input
• native-approval-investigation.json: direct MCP call argument equality and outcomes
• A30-full-proposal.png, A30-retrying.png, A30-approved-retry-failed.png
• A30-pending-metadata.json, A30-open-no-execution.json, cleanup-metadata.json

This draft excludes credentials, opaque authority/approval identifiers, raw event payloads, private channel IDs and message contents.

Start at the thread/approveGuardianDeniedAction entry point and trace how its native approval is passed into automatic review for the next MCP call. Reproduce the matching retry with automatic review enabled and verify that the approval is either honored consistently or produces a deterministic failure explaining why it cannot authorize the action.