M3: Guardian approval decision -> verification kickoff

[NgoHarrison]

When the guardian approves an access request, starts outbound verification using the existing channel-guardian service. When denied, sends a refusal reply to the requester. Handles stale decisions and idempotency.

Closes #9436
Part of #9432

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🔴 Idempotency check uses stale in-memory approval.status instead of DB state, allowing duplicate verification sessions

The idempotency guard at line 70 checks approval.status (the in-memory object passed by the caller) rather than comparing against the freshly-read database state returned by resolveApprovalRequest. When two concurrent requests both fetch the same pending approval before either resolves it, both will have approval.status === 'pending', causing both to bypass the idempotency check and create duplicate verification sessions.

Root cause and race condition scenario

The race is exploitable through the conversational engine path in guardian-approval-interception.ts, where await runApprovalConversationTurn(...) at line 269 yields back to the event loop between the approval fetch (line 146) and the call to handleAccessRequestApproval (line 328–336):

1. Request A: fetches guardianApproval (status=pending) at line 146
2. Request A: calls await runApprovalConversationTurn(...) at line 269 → yields
3. Request B: fetches the same approval (still pending) at line 146
4. Request B: calls await runApprovalConversationTurn(...) → yields
5. Request A: engine returns, calls handleAccessRequestDecision → resolveApprovalRequest transitions pending→approved, creates session feat: initialize Next.js app in /web directory #1
6. Request B: engine returns, calls handleAccessRequestDecision → resolveApprovalRequest returns the existing approved record (idempotent), but approval.status === 'pending' (stale!), so the check at line 70 does not trigger → creates session feat: add platform terraform for GKE deployment #2, which revokes session feat: initialize Next.js app in /web directory #1

The guardian receives two verification codes, but only the second one is valid because createOutboundSession (channel-guardian-service.ts:410-431) auto-revokes prior sessions. If the guardian relays the first (now-revoked) code to the requester, verification fails.

Impact: In concurrent approval scenarios, the first delivered verification code is silently invalidated, causing a confusing UX where the guardian's code doesn't work. The requester also receives duplicate "approved" notifications.

Prompt for agents

In assistant/src/runtime/routes/access-request-decision.ts, the idempotency check at lines 70-72 uses `approval.status` (the in-memory object passed by the caller) which may be stale. Instead, it should detect idempotency by comparing the resolved record's state to determine whether the DB transition actually happened in THIS call vs a prior call.

Option 1: Have resolveApprovalRequest in assistant/src/memory/channel-guardian-store.ts return a discriminated result that distinguishes 'newly_resolved' from 'already_resolved_same_decision' (e.g., include a `wasAlreadyResolved: boolean` flag).

Option 2: In handleAccessRequestDecision, re-read the approval from the DB after resolveApprovalRequest returns, and compare the updatedAt timestamp or status to detect whether the transition was made by this call.

Option 3 (simplest): Replace the check at line 70 with `if (resolved.status === decision && resolved.updatedAt !== resolved.createdAt && resolved.updatedAt < Date.now() - some_small_threshold)` — though this is fragile. The cleanest fix is option 1: modify resolveApprovalRequest to return `{ record, transitioned: boolean }` so the caller can reliably distinguish.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d31fe2570e

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Make access-request approvals truly idempotent

resolveApprovalRequest already returns the existing row for same-decision replays, but this code checks approval.status (the caller’s snapshot) instead of whether this call actually transitioned the DB row. If the same approval is processed again from a stale pending snapshot (for example duplicate/retried callback handling across workers), the replay is treated as a fresh approval and creates a new outbound session/code, revoking the prior code and sending conflicting verification instructions to guardian/requester.

Useful? React with 👍 / 👎.