Summary

• Problem: codex.cli.session.resume did not consistently pass through plugin approval before node dispatch.
• Solution: require a restricted plugin approval for resume, limited to allow-once and deny.
• What changed: the resume policy now requests approval before ctx.invokeNode(), uses the standard plugin approval timeout instead of the longer node resume timeout, fails closed when approval delivery is unavailable or denied, and the Control UI renders only the decisions allowed by the approval request.
• What did NOT change (scope boundary): session listing, node-host resume implementation, and Codex CLI spawn behavior are unchanged.

Change Type

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes: N/A
• Related: N/A
• This PR fixes a bug or regression

Motivation

codex.cli.session.resume can resume an existing local Codex CLI session with a caller-supplied prompt. Since this is a dangerous node-host command, the Gateway policy should require an explicit operator decision before forwarding the request to the node.

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Codex CLI session resume now requires plugin approval before node dispatch, and the Control UI shows only the decisions permitted for this approval.
• Real environment tested: macOS local checkout, branch codex-resume-approval, head 713c83eba2ce.
• Exact steps or command run after this patch: node --import tsx .artifacts/codex-resume-real-behavior-proof.ts; node .artifacts/codex-resume-control-ui-proof.mjs; targeted Vitest and oxfmt --check on touched files.
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): copied redacted runtime logs from a live local Gateway + paired node run and from a real Control UI bundle opened in Google Chrome:

[gateway] http server listening (10 plugins: acpx, bonjour, browser, canvas, codex, device-pair, file-transfer, memory-core, phone-control, talk-voice)
[proof ...] approval runtime client connected
[proof ...] operator invoke client connected
[proof ...] starting headless node host codex-proof-node-...
[gateway] device pairing auto-approved device=<node-device-id> role=node
[proof ...] approved node pairing request ... commands=["system.run.prepare","system.run","system.which","browser.proxy","codex.cli.session.resume","codex.cli.sessions.list"]
[proof ...] node connected: nodeId=<node-device-id> commands include codex.cli.session.resume after node-pair approval
[proof ...] non-dangerous list invoke succeeded: sessionCount=1 payloadJSON=present
[proof ...] plugin approval requested: id=plugin:... title="Resume Codex CLI session" severity="critical" toolName="codex.cli.session.resume"
[proof ...] plugin approval resolved with deny: id=plugin:...
[proof ...] deny resume result error: {"name":"GatewayClientRequestError","gatewayCode":"INVALID_REQUEST","message":"Codex CLI session resume requires plugin approval.","details":{"approvalId":"plugin:...","decision":"deny","code":"PLUGIN_APPROVAL_REQUIRED"}}
[proof ...] plugin approval requested: id=plugin:... title="Resume Codex CLI session" severity="critical" toolName="codex.cli.session.resume"
[proof ...] plugin approval resolved with allow-once: id=plugin:...
[proof ...] allow-once resume result error: {"name":"GatewayClientRequestError","gatewayCode":"INVALID_REQUEST","message":"Error: Missing or invalid Codex CLI session id.","details":{"nodeError":{"code":"INVALID_REQUEST","message":"Error: Missing or invalid Codex CLI session id."},"code":"INVALID_REQUEST"}}
[proof ...] proof completed

[control-ui-proof ...] branch=codex-resume-approval head=713c83eba2ce
[control-ui-proof ...] loaded real Control UI bundle from http://127.0.0.1:5173/
[control-ui-proof ...] approval title="Resume Codex CLI session" toolName=codex.cli.session.resume
[control-ui-proof ...] rendered decision buttons=["Allow once","Deny"]
[control-ui-proof ...] always allow visible=false
[control-ui-proof ...] click Deny -> handleExecApprovalDecision calls=["deny"]
[control-ui-proof ...] rerendered decision buttons=["Allow once","Deny"]
[control-ui-proof ...] click Allow once -> handleExecApprovalDecision calls=["allow-once"]
[control-ui-proof ...] proof completed

• Observed result after fix: codex.cli.sessions.list still dispatches without plugin approval; codex.cli.session.resume creates a plugin approval request before node dispatch; denied approval returns PLUGIN_APPROVAL_REQUIRED without dispatch; allow-once proceeds to the node handler; the resume approval uses the normal plugin approval timeout rather than the long node resume timeout; the Control UI renders only Allow once and Deny, with no Always allow button.
• What was not tested: remote multi-device deployment and a successful live Codex model turn after resume. The allow path intentionally used an invalid session id so the proof could verify dispatch reaches the node handler without running a model turn.
• Before evidence (optional but encouraged): before this change, the Codex resume node-invoke policy dispatched to the node without creating a plugin approval request.

Root Cause

• Root cause: the Codex CLI resume node-invoke policy did not request plugin approval before dispatching to the node.
• Missing detection / guardrail: there was no regression test covering approval behavior for this resume policy, and the Control UI approval prompt did not preserve plugin approval allowedDecisions.
• Contributing context: session listing and session resume are registered together, but only resume needs approval gating.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/codex/src/node-cli-sessions.test.ts, src/gateway/node-invoke-plugin-policy.test.ts, ui/src/ui/controllers/exec-approval.test.ts, ui/src/ui/views/exec-approval.test.ts, ui/src/ui/app-gateway.node.test.ts
• Scenario the test should lock in: resume requires plugin approval, does not dispatch when approval delivery is unavailable or denied, does not pass the long node resume timeout into the approval request, forwards only after allow-once, and the Control UI renders only the decisions allowed by the plugin approval request.
• Why this is the smallest reliable guardrail: the changed behavior is local to the Codex node-invoke policy, plugin approval request propagation, and the Control UI approval prompt.
• Existing test that already covers this: none before this PR.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Codex CLI session resume through this node command now requires plugin approval before dispatch. The approval prompt offers Allow once or Deny; it does not offer Always allow for this resume path.

Diagram

Before:
resume request -> node dispatch

After:
resume request -> plugin approval (allow-once / deny) -> node dispatch only after allow-once

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? Yes — this narrows the resume execution path by requiring explicit plugin approval before node dispatch.
• Data access scope changed? No
• If any Yes, explain risk + mitigation: command dispatch is narrowed by a fail-closed approval gate.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local development checkout
• Model/provider: N/A
• Integration/channel: Codex extension
• Relevant config: temporary local OpenClaw state/config, redacted in logs

Steps

1. Run the live Gateway + paired node proof.
2. Run the real Control UI decision-rendering proof.
3. Run targeted regression tests and formatting checks.

Expected

• Resume dispatch only happens after an allow-once plugin approval decision.
• Denied approval and unavailable approval runtime do not dispatch to the node.
• The Control UI shows only Allow once and Deny for the Codex resume approval.

Actual

• Matches expected in the live Gateway proof, Control UI proof, and targeted regression tests.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers

Human Verification

• Verified scenarios: deny blocks dispatch; unavailable approval runtime blocks dispatch; allow-once forwards to the node handler; Control UI renders only Allow once and Deny; Control UI click routing produces deny and allow-once.
• Edge cases checked: approval runtime unavailable; duplicate/limited plugin approval decisions are normalized before broadcast; disallowed allow-always is not rendered by the Control UI.
• What you did not verify: remote multi-device deployment and a successful live Codex model turn after resume.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Mostly
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A
• Notes: existing automation that invokes codex.cli.session.resume may now need an approval-capable runtime or an explicit approval decision.

Risks and Mitigations

• Risk: existing automation that resumes Codex CLI sessions may now stop for approval.
  • Mitigation: the change is limited to session resume; session listing and node-host resume behavior remain unchanged after approval.