[codex] Verify auth gate blocked exits

[serrrfirat]

Summary

• verify Reborn auth blocked exits against a durable same-run BeforeBlock checkpoint
• allow validated auth blocked exits to persist as BlockedAuth instead of falling into RecoveryRequired
• keep approval/resource/dependent-run blocked evidence fail-closed until their pending gate/process evidence exists

Tests

• cargo fmt --all
• cargo test -p ironclaw_reborn loop_exit_applier
• cargo test -p ironclaw_reborn
• git diff --check

Base is now reborn-integration; this PR no longer depends on #4231.

[gemini-code-assist]

Code Review

This pull request implements verification for auth-blocked checkpoints in verify_blocked_evidence by retrieving and validating the checkpoint from the store. It also adds comprehensive unit tests and test helpers to support this functionality. The reviewer suggests using an exhaustive match statement over LoopBlockedKind instead of an inequality check to leverage compiler-enforced safety for future enum variants.

[gemini-code-assist]

To ensure safety and maintainability, prefer using an exhaustive match statement over LoopBlockedKind instead of an inequality check. This forces a compile-time error if new variants are added to the enum in the future, preventing silent failures or unhandled cases.

        match request.blocked.kind {
            LoopBlockedKind::Auth => {}
            LoopBlockedKind::Approval
            | LoopBlockedKind::Resource
            | LoopBlockedKind::AwaitDependentRun => {
                // A BeforeBlock checkpoint alone is not sufficient for approval,
                // resource, or dependent-run gates: #3424 requires a durable
                // pending gate/process ref for those block types. Auth gates use
                // the blocked turn state itself as the product-visible pending ref,
                // so verifying the pre-block checkpoint is enough to let the
                // applier persist that state.
                return Ok(false);
            }
        }

References

1. Prefer exhaustive enum matching over runtime property-based checks for classifying variants when the set is small and known, as it leverages compiler-enforced safety and prevents loosening type constraints.

[abbyshekit]

Review — verify auth gate blocked exits

Combined pass (Claude Code + Codex 5.5 gpt-5.5, branch diff vs origin/reborn-integration). Sound, fail-closed, well-scoped change; the new tests genuinely drive the production verify_blocked_evidence path (not tautological). One protocol gap, flagged independently by both reviewers.

Medium — Auth blocked-evidence isn't bound to the actual gate

crates/ironclaw_reborn/src/loop_exit_applier.rs:302-303 — for LoopBlockedKind::Auth the check is checkpoint.kind == BeforeBlock && checkpoint.state_ref == blocked.state_ref. But BeforeBlock carries no gate-kind discriminator, and gate_ref is never cross-checked against the checkpoint. A buggy/compromised driver can reuse a legitimate Approval/Resource/dependent-run BeforeBlock checkpoint from the same run, label the exit Auth, and it validates as BlockedAuth — routing resolution through the auth path instead of the durable gate evidence the other kinds keep fail-closed. Within the driver-trust model this is low-likelihood, but the Auth carve-out gets weaker evidence than its peers. Bind gate identity into the checkpoint record (so the kind can be asserted), or verify durable auth-gate metadata / gate_ref against the checkpoint.

Low

crates/ironclaw_reborn/src/loop_exit_applier.rs:286 — the trailing _ => return Ok(false) correctly fails unknown LoopBlockedKind variants closed (the enum is #[non_exhaustive] in a sibling crate), but a future variant silently lands in the fail-closed bucket rather than forcing a compile-time decision. A comment noting that would help.

What's good

Auth carve-out maps correctly to BlockedAuth via BlockedReason::status(); lookup is strictly same-run scoped (no cross-run replay); Approval/Resource/AwaitDependentRun stay fail-closed; mirrors the existing verify_final_checkpoint pattern with an added state_ref binding.

Coverage gaps

Auth with a wrong-kind checkpoint at the same checkpoint_id (should return false); Auth with an unparseable gate_ref (verified evidence but to_blocked_reason fails → UnverifiedBlockedEvidence); a positive end-to-end apply() asserting Approval/Resource/AwaitDependentRun still land in RecoveryRequired.

_{Codex 5.5 independently flagged the same gate-binding gap as P2.}

[serrrfirat]

Addressed the combined review findings in a45df3aca.

Fixed

Severity	Finding	Fix
Medium	Auth blocked-evidence not bound to gate — BeforeBlock checkpoint carries no gate-kind discriminator; rogue driver could reuse Approval/Resource checkpoint labeled as Auth	Thread gate_ref through LoopCheckpointRequest → PutLoopCheckpointRequest → LoopCheckpointRecord. CheckpointStage::write_before_block stores the gate ref in BeforeBlock checkpoints. verify_blocked_evidence now cross-checks checkpoint.gate_ref == Some(&blocked.gate_ref)
Low	_ => return Ok(false) wildcard arm on LoopBlockedKind needs comment	Added comment explaining wildcard is required by #[non_exhaustive] in sibling crate, intentionally fail-closed for unknown variants

Tests

• Updated auth_blocked_exit_with_durable_checkpoint_maps_to_blocked_auth to supply matching gate_ref
• Updated thread_checkpoint_evidence_verifies_auth_blocked_checkpoint to supply matching gate_ref
• Added thread_checkpoint_evidence_rejects_auth_blocked_checkpoint_gate_mismatch — verifies cross-gate checkpoint reuse is rejected

Validation

cargo fmt --check     ✓
cargo clippy          ✓ (no errors)  
cargo test -p ironclaw_turns -p ironclaw_agent_loop -p ironclaw_reborn -p ironclaw_hooks  ✓
git diff --check      ✓