Request-bound human approval

The Java durable profile demonstrates human-in-the-loop approval for an exact simulated request. Its trusted reviewer context requires an authenticated, authorized human in the same tenant. Self-approval is rejected. Approval binds the subject, actor/lineage, event, action hash, policy, tool, resource, and expiry; PostgreSQL atomically consumes it with the execution claim before simulator dispatch.

Agent proposes an allowlisted simulated change
          ↓
Policy requires approval → pending durable request
          ↓
Separate trusted reviewer approves exact request
          ↓
Approved / not executed → original requester explicitly resumes
          ↓
Atomic approval + permit claim → simulator execution

Atomic claim and approval boundary

The default POC does not expose a public approval API, editable console control, or Slack/Teams notification workflow. A separate loopback-only Java API foundation verifies access tokens plus operator-owned reviewer membership and persists exact action snapshots with pending approvals. Its automated qualification uses a synthetic IdP and safe simulator, including rendered browser sign-in, not live external-provider compatibility. A separate pnpm dev:approvals entry point accepts explicit private operator configuration; --check validates files and trust configuration offline, not IdP or database readiness. It is not started by existing demo launchers. See the API qualification runbook. The default demo console remains read-only. An optional same-origin Java browser adapter now provides OIDC code/PKCE sign-in and a role-scoped React approval inbox over the fixed simulator. Tokens stay server-side; all API role, scope, ownership and exact-request checks still apply. Run pnpm demo:approvals:browser for the test-only synthetic IdP/disposable DB qualification. It is not a public browser deployment or live external-IdP qualification. See the browser runbook.

The separate Codex MCP composition exposes only request, status and explicit resume tools over that same durable service. It cannot approve its own request. Native app-server MCP calls and a synthetic browser review have been qualified. The separate model-driven record qualifies Codex 0.162.1/gpt-5.6-sol request/review/resume, replay, expiry and explicit reviewer-denial rejection. This is one bearer-only local profile, not arbitrary prompt/client compatibility, endpoint source attestation or hosted OAuth. See Flow 3 and the Codex runbook.

Inspect history without granting authority

The inbox supports exact status/tool/request-ID filters and explicit older pages. Each read rechecks current token, enrollment, role, scopes and tenant/owner context. The cursor is an unsigned page position, never authorization; React bounds retained rows, validates responses and renders untrusted action data as text. This is not a complete audit export, retention system or policy-admin console.

See Flow 10 and the history API contract. For a step-by-step second-machine test, use the fresh Mac walkthrough.

Expiry while reviewing

Loaded pending/approved requests update their local expiry labels without a refresh. When an approval lifetime elapses, review/execute controls and an open confirmation become unavailable; stored status remains visible rather than being rewritten. The confirmation handler also rechecks eligibility immediately before POST. No timer approves, executes or retries anything. Browser time is advisory and can be skewed or throttled in background tabs; Java remains authoritative. Use Refresh to inspect current server state before continuing.

Scenario 3 and Scenario 8 exercise the approval boundary with safe simulators and disposable state.