fix(auth-resume): preserve input replay across gate boundaries

[serrrfirat]

Summary

• Preserve the original capability input and estimate when a runtime auth gate blocks.
• Replay that saved input during auth resume instead of resolving a stale or already-consumed input_ref.
• Preserve approval-to-auth invocation identity, including the prior approval resume token, so approval-scoped leases still match.

Change Type

• Bug fix
• New feature
• Refactor
• Documentation
• CI/Infrastructure
• Security
• Dependencies

Linked Issue

Related #4887

Validation

• cargo fmt --all -- --check
• cargo clippy --all --benches --tests --examples --all-features -- -D warnings
• cargo build: cargo check --workspace --quiet
• Relevant tests pass:
  • cargo test -p ironclaw_agent_loop --quiet
  • cargo test -p ironclaw_loop_support --quiet
  • cargo test -p ironclaw_turns --quiet
  • cargo test -p ironclaw_hooks --quiet
  • cargo test -p ironclaw_reborn --test loop_driver_host --quiet
  • cargo test -p ironclaw_reborn_composition local_dev --quiet
• cargo test --features integration if database-backed or integration behavior changed
• Manual testing
• If a coding agent was used and supports it, review-pr or pr-shepherd --fix was run before requesting review: thermo-nuclear code-quality review pass plus Gemini review follow-up addressed.

Security Impact

Touches auth/runtime resume handling. This does not weaken auth checks; it preserves the already-validated capability input/estimate for auth resume so the host does not resolve a stale scoped input ref after OAuth. The replay payload is serde-optional for checkpoint compatibility and covered by migration/round-trip tests.

Reborn Trust-Boundary Checklist

• Public policy/evidence/trust-bearing types: who can construct them? CapabilityAuthResumeReplay is host/loop contract data constructed by the runtime conversion path or restored from checkpointed pending auth state.
• Untrusted content enters prompts only through an envelope/escaping primitive. No prompt content path changed.
• Hashes declare purpose; trust/binding/authenticity uses SHA-256/BLAKE3 or separate authenticity check. No hashing path changed.
• New/changed status, exit, policy, runtime, or error variants: downstream match sites audited. Command/output: cargo check --workspace --quiet; updated AuthRequired constructors/matches in agent-loop, loop-support, hooks, and tests.
• Security/durability serde(default) fields fail closed or have migration tests. PendingAuthResume.replay and CapabilityAuthResume.replay are optional defaults; checkpoint compatibility tests cover absence and round-trip.
• Queues/maps/buffers/counters have bounds and overflow-safe arithmetic. No queue/map/buffer/counter behavior changed.
• Driver/operator-visible errors have stable class semantics (Transient, Permanent, Misconfigured, PolicyDenied or equivalent). No error class changes.
• Sandbox/native/host names accurately describe trust boundary. No sandbox/native/host naming changes.

Database Impact

None. No migrations or persistence backend schema changes. Checkpoint payload shape gains optional serde-default fields only.

Blast Radius

Touches Reborn capability auth-resume flow across ironclaw_turns, ironclaw_agent_loop, ironclaw_loop_support, and hooks middleware. Regressions would most likely affect approval/auth gated capability replay, especially Gmail/Google workspace tools after OAuth completion.

Rollback Plan

Revert this PR. The previous behavior may reintroduce scope_mismatch on Gmail auth resume when the original input_ref is stale or consumed.

Review Follow-Through

Gemini requested preserving the original approval invocation token when approval flows into auth. The latest commit makes the prior approval token win and extends the caller-level regression test to cover that token carryover.

---

Review track: C (runtime/auth resume path)

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes
  • Preserve authentication replay metadata across auth-required checkpoint cycles and resumptions.
  • Improve auth-resume re-dispatch to reuse the original input/estimate instead of resolving a stale input reference.
  • Strengthen capability execution so auth-resume details are consistently carried through approval, authentication-required, resource-blocked, and await-dependent paths.
• API Updates
  • Added replay support via CapabilityAuthResumeReplay and an auth_resume field on CapabilityOutcome::AuthRequired so hosts can provide replay data.

Walkthrough

Adds CapabilityAuthResumeReplay (carrying captured input and estimate) and threads it through the entire auth-resume gate path: new fields on CapabilityAuthResume and CapabilityOutcome::AuthRequired, a new auth_resume slot in GateInput, persistence in PendingAuthResume, a merge helper auth_resume_for_gate, and loop-support runtime conversion now populates replay for both approval and auth outcomes. Re-dispatch reuses the captured payload instead of re-resolving a stale CapabilityInputRef.

Changes

Auth-Resume Replay Metadata Threading

Layer / File(s)	Summary
New public types: CapabilityAuthResumeReplay and AuthRequired.auth_resume crates/ironclaw_turns/src/run_profile/host.rs, crates/ironclaw_turns/src/run_profile/mod.rs	CapabilityAuthResume gains optional replay field backed by new CapabilityAuthResumeReplay { input, estimate }; CapabilityOutcome::AuthRequired gains optional auth_resume; CapabilityAuthResumeReplay re-exported from run_profile.
GateInput.auth_resume and PendingAuthResume.replay schema crates/ironclaw_agent_loop/src/executor/gates.rs, crates/ironclaw_agent_loop/src/state.rs	GateInput gains auth_resume field; GateStage::process extracts token/replay/prior-approval from it on auth block; PendingAuthResume gains serde-optional replay field persisted at checkpoint with serde(default) and backward-compat test coverage.
capability_invocation_from_auth_resume_candidate propagates replay crates/ironclaw_agent_loop/src/executor/capability_helpers.rs	Clones pending_auth.replay into the constructed CapabilityAuthResume so re-dispatch carries the original input/estimate; import list expanded.
auth_resume_for_gate helper and executor GateInput wiring crates/ironclaw_agent_loop/src/executor/capabilities.rs	New auth_resume_for_gate merges prior_approval identity into existing or newly constructed CapabilityAuthResume; all GateInput construction sites (ApprovalRequired, AuthRequired, ResourceBlocked, AwaitDependentRun) now supply explicit auth_resume values.
Loop-support replay-derived invocation and runtime outcome conversion crates/ironclaw_loop_support/src/capability_port.rs	Adds CapabilityReplayInput; invocation_replay_input reads replay from approval/auth resume; runtime_outcome_to_loop populates CapabilityAuthResume.replay for both ApprovalRequired and AuthRequired via runtime_resume_replay helper.
Hooks middleware PauseAuth wiring crates/ironclaw_hooks/src/middleware/capability_port.rs, crates/ironclaw_hooks/src/middleware/tests/capability_port.rs, crates/ironclaw_agent_loop/src/test_support/mod.rs	PauseAuth branch sets explicit auth_resume: None; test pattern updated with .. wildcard; scripted outcome wiring includes auth_resume field.
Checkpoint serde tests crates/ironclaw_agent_loop/src/state.rs	Round-trip, optional-fields, and legacy-compat tests cover replay field serde including absence → None decode and payload survival across encode/decode.
Executor and capability_helpers tests crates/ironclaw_agent_loop/src/executor/tests.rs, crates/ironclaw_agent_loop/src/executor/capability_helpers.rs	All GateInput and PendingAuthResume literals updated for new fields; correlation-id regression extended to assert replay.input is preserved through approval→auth→reinvoke pipeline.
Runtime lifecycle tests: replay re-dispatch and OneShotInputResolver crates/ironclaw_loop_support/src/capability_port/tests/runtime_lifecycle_tests.rs	New auth_resume_uses_replay_input_without_resolving_stale_input_ref test with OneShotInputResolver asserts resolver called exactly once and auth-resume request contains original JSON; QueuedHostRuntime extended with auth_resume_capability and outcome/request recording.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related issues

• agent_loop: unify pending gate-resume records and move replay payload out of checkpointed state #4747: Open issue flagging that storing replay payload in checkpointed PendingAuthResume violates the agent-loop contract (state must be refs, cursors, versions, safe summaries only); this PR adds replay to checkpoint state — verify host-side storage proposal in #4747 is compatible or superseded.

Possibly related PRs

• nearai/ironclaw#4839: Prerequisite that established PendingAuthResume seeding and auth-resume carryover plumbing in executor, gates, and state; this PR extends that with replay metadata threading.

Suggested reviewers

• henrypark133

Poem

🦀 A stale InputRef once caused despair,
The gate would block, the resume laid bare.
Now replay rides the GateInput stream,
OneShotResolver guards the one-call dream.
No ref re-resolved, no credential lost —
the auth path carries its payload, no cost. 🎯

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	Title follows Conventional Commits style with type(scope): summary format and accurately summarizes the main change of preserving input replay across auth gates.
Description check	✅ Passed	Description includes all required sections: summary, change type (bug fix), linked issue, comprehensive validation checks, security impact analysis, Reborn trust-boundary checklist completed, database impact, blast radius, and rollback plan.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request introduces capability auth-resume replay functionality to avoid resolving stale or already-consumed input references after a user completes authentication. It adds a replay field to CapabilityAuthResume and PendingAuthResume to capture and persist the original runtime input and resource estimate when an auth gate blocks. Feedback suggests propagating the resume_token from prior_approval to auth_resume if it is missing, ensuring the original invocation identity is preserved.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

If auth_resume is already Some but its resume_token is None, we should propagate the resume_token from prior_approval to ensure the original invocation identity is preserved. This prevents potential issues where the fingerprinted approval lease fails to match due to a missing or newly minted invocation ID.

    match auth_resume.as_mut() {
        Some(resume) => {
            if resume.resume_token.is_none() {
                resume.resume_token = prior_approval.resume_token.clone();
            }
            resume.prior_approval.get_or_insert_with(prior_identity);
            resume.replay.get_or_insert_with(prior_replay);
            auth_resume
        }

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

crates/ironclaw_agent_loop/src/executor/capabilities.rs (1)

152-160: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Consume the approval resume when auth-resume wins.

After an approval→auth block, the gate checkpoint carries both pending auth and approval resume state. This branch consumes only pending_auth_resume; a second same-capability_id call in the batch can then take the leftover approval resume at Lines 157-160, reusing a one-shot approval identity across a distinct invocation. As per coding guidelines, “Fail closed for auth, approvals, trust, filesystem containment, network policy, secret leases, runtime selection, and adapter identity.”

Proposed fix

                         if let Some(auth) = pending_auth_resume
                             .take_if(|auth| auth.capability_id == call.capability_id)
                         {
+                            let _ = pending_approval_resume
+                                .take_if(|resume| resume.capability_id == call.capability_id);
                             return capability_invocation_from_auth_resume_candidate(call, &auth);
                         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/ironclaw_agent_loop/src/executor/capabilities.rs` around lines 152 -
160, The auth-resume branch (lines 152-154) only consumes pending_auth_resume
but leaves pending_approval_resume in place, allowing a subsequent call with the
same capability_id to reuse the approval identity, which violates the
fail-closed security principle for approvals. After the auth-resume is taken in
the first branch, also consume the pending_approval_resume by calling take_if or
similar to clear it, ensuring the one-shot approval identity cannot be reused
across a distinct invocation in the batch.

Source: Coding guidelines

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/ironclaw_agent_loop/src/executor/capabilities.rs`:
- Around line 941-945: The code in the match block where auth_resume is
Some(resume) has a consistency issue: line 943 makes the checkpointed
prior_approval.resume_token authoritative, but lines 944-945 use
get_or_insert_with which preserves any existing prior_approval and replay values
in the resume. This creates a mixed state where the token comes from one
approval while the identity and replay fields may come from a different source.
Either replace the get_or_insert_with calls to directly assign the checkpoint's
prior_approval and replay values to ensure all fields come from the same
authoritative source, or add validation logic to return a contract error if the
existing fields differ from the checkpoint values. Given the requirement to fail
closed for auth and approvals, the safer approach is to make the checkpointed
prior approval the sole source of truth by directly assigning all its
constituent fields.

---

Outside diff comments:
In `@crates/ironclaw_agent_loop/src/executor/capabilities.rs`:
- Around line 152-160: The auth-resume branch (lines 152-154) only consumes
pending_auth_resume but leaves pending_approval_resume in place, allowing a
subsequent call with the same capability_id to reuse the approval identity,
which violates the fail-closed security principle for approvals. After the
auth-resume is taken in the first branch, also consume the
pending_approval_resume by calling take_if or similar to clear it, ensuring the
one-shot approval identity cannot be reused across a distinct invocation in the
batch.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: c0ed390f-5748-462f-a77d-7fceda427310

📥 Commits

Reviewing files that changed from the base of the PR and between 14b6072 and 8c98652.

📒 Files selected for processing (2)

• crates/ironclaw_agent_loop/src/executor/capabilities.rs
• crates/ironclaw_agent_loop/src/executor/tests.rs

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Do not checkpoint mixed auth/approval resume identity.

Line 943 makes checkpointed prior_approval.resume_token authoritative, but Lines 944-945 keep any existing auth_resume.prior_approval or auth_resume.replay. If those fields differ, the persisted auth resume has a token from one approval and identity/replay from another. Make the checkpointed prior approval the source of truth here, or return a contract error on mismatch. As per coding guidelines, “Fail closed for auth, approvals, trust, filesystem containment, network policy, secret leases, runtime selection, and adapter identity.”

Proposed fix

         Some(resume) => {
             resume.resume_token = prior_approval.resume_token.clone();
-            resume.prior_approval.get_or_insert_with(prior_identity);
-            resume.replay.get_or_insert_with(prior_replay);
+            resume.prior_approval = Some(prior_identity());
+            resume.replay = Some(prior_replay());
             auth_resume
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/ironclaw_agent_loop/src/executor/capabilities.rs` around lines 941 -
945, The code in the match block where auth_resume is Some(resume) has a
consistency issue: line 943 makes the checkpointed prior_approval.resume_token
authoritative, but lines 944-945 use get_or_insert_with which preserves any
existing prior_approval and replay values in the resume. This creates a mixed
state where the token comes from one approval while the identity and replay
fields may come from a different source. Either replace the get_or_insert_with
calls to directly assign the checkpoint's prior_approval and replay values to
ensure all fields come from the same authoritative source, or add validation
logic to return a contract error if the existing fields differ from the
checkpoint values. Given the requirement to fail closed for auth and approvals,
the safer approach is to make the checkpointed prior approval the sole source of
truth by directly assigning all its constituent fields.

Source: Coding guidelines