compat(agent): re-verify Codex Room approvals on current codex-acp

[madawei2699]

Why

Free4Chat #297 classified Codex Room approval as an upstream limitation based on older codex-acp versions.

Free4Chat currently pins @agentclientprotocol/codex-acp@1.6.2. Upstream changed materially after that: codex-acp 1.7.0 added ACP v1 permission presentation (agentclientprotocol/codex-acp#405). Current latest is 1.12.0, and current main contains explicit mappings for item/commandExecution/requestApproval, item/fileChange/requestApproval, item/permissions/requestApproval → ACP session/request_permission.

The old Free4Chat compatibility result therefore has to be re-verified against current upstream.

Remaining upstream uncertainty

Permission presentation support does NOT imply every Codex approval path is correct. Still-open upstream evidence:

• Codex sandbox_permissions approval doesn't get surfaced through app-server openai/codex#21982 — sandbox_permissions / require_escalated may fail to surface requestApproval; issue remains OPEN, similar symptom reported on newer Codex versions.
• Sandbox and approval policies from config.toml are ignored agentclientprotocol/codex-acp#310 — bridge mode presets / config policy limitations.
• MCP calls can run before permission mediation and surface as execute wrappers agentclientprotocol/codex-acp#401 — some MCP execution can occur before permission mediation.

Goal

Determine current real behavior, not design a new Free4Chat permission system. Classify the current Codex bridge as one of:

• ROOM APPROVAL VERIFIED
• PARTIAL
• UPSTREAM APP-SERVER LIMITATION
• UPSTREAM BRIDGE LIMITATION

Acceptance

• probe current codex-acp 1.12.0 against the current Free4Chat pin 1.6.2 in a disposable workspace;
• choose the narrowest mode/policy that is supposed to produce manual approval (do not assume old INITIAL_AGENT_MODE semantics; do not permanently widen Free4Chat's read-only policy — an isolated alternate mode/config is acceptable for the probe);
• trigger real command/file approval and trace the exact layer:
  Codex app-server requestApproval
  → codex-acp session/request_permission
  → Free4Chat Room approval card
  → exact native option
  → same turn continues (allow) / action prevented (deny);
• if PASS: run the Codex serial regression on 1.12.0 (ordinary Task, >2 min turn, Task B queued, interrupt, follow-up, session behavior, permission allow/reject) and only then decide whether Free4Chat should bump its launcher pin — Codex stays serial, no concurrency, TaskSessionContinuation unchanged;
• if FAIL: identify the exact upstream repo (bridge vs app-server) and add sanitized evidence there with a concise reproduction — no duplicate issues, no credentials/private paths;
• update compat(agent): track built-in Harness Room-approval behavior after #286 #297's historical matrix by comment/link only after re-verification;
• no Free4Chat fake permission policy.

Refs

• Free4Chat compat(agent): track built-in Harness Room-approval behavior after #286 #297 — built-in Harness Room-approval compatibility history
• feat: add ACP v1 permission presentation agentclientprotocol/codex-acp#405 — ACP v1 permission presentation
• Sandbox and approval policies from config.toml are ignored agentclientprotocol/codex-acp#310
• MCP calls can run before permission mediation and surface as execute wrappers agentclientprotocol/codex-acp#401
• Codex sandbox_permissions approval doesn't get surfaced through app-server openai/codex#21982

[madawei2699]

Verification — 2026-09-20

Tested the released combinations in disposable workspaces: codex-acp 1.6.2 with Codex/app-server 0.148.0, and codex-acp 1.12.0 with 0.154.0. Both used INITIAL_AGENT_MODE=read-only.

1.6.2 command path: app-server used approval_policy=on-request, approvals_reviewer=user, sandboxPolicy=readOnly and emitted item/commandExecution/requestApproval. The bridge emitted session/request_permission, but toolCall.title and permission presentation metadata were empty. Runtime rejected it as “invalid Harness permission title”; no Room request was created and the command did not execute.

1.12.0 command path: effective policy was on-request, reviewer=user, sandboxPolicy=workspaceWrite with writableRoots=[]. The app-server emitted item/commandExecution/requestApproval and the bridge forwarded a titled ACP request. Runtime rejected the accept_execpolicy_amendment option because its native display name was 175 characters, over the 160-character Room limit. No Room request was created and the command did not execute. Narrow regression issue: #429.

1.12.0 file-change path: item/fileChange/requestApproval → session/request_permission → structured Room permission request (title “Make edits?”, kind edit, exact native options preserved). Allow changed the disposable file in the same turn; Reject left it unchanged; a follow-up turn remained usable in the same native Codex session. This exercised the real Free4Chat Runtime projection and decision mapping with a test Room transport; I did not open a live browser Room.

Inspected, but did not force, permissions/requestApproval. codex-acp 1.12.0 has a handler for it. #310 concerns the mode/config coupling; the chosen manual mode did emit app-server approvals. #401 concerns MCP mediation and was outside these shell/file paths. For #21982, the 0.154.0 trace emitted the expected command request with reviewer=user; this does not settle reports on other versions/configurations.

Classification: PARTIAL / Free4Chat bug. File-change approval passed through Runtime; command approval is dropped at Room projection. Do not bump the launcher yet. Consider 1.12.0 after #429 is fixed and the full Codex regression passes. The existing 1.6.2 command request also lacks presentation data. Codex remains SERIAL and TaskSessionContinuation stays disabled. No Free4Chat launcher code changed.

[madawei2699]

#429 is now fixed and merged via #430 (ce6a62b23ca57226c26d79b90ced9b3174700747), so the Free4Chat-owned blocker from the first 1.12.0 probe is cleared.

Upstream latest remains codex-acp v1.12.0 (Codex/app-server 0.154.0), so the next step is the acceptance already defined here:

1. re-run the real 1.12.0 command approval path against current cf-sfu;
2. verify a live browser Room card, not only test Room transport;
3. Allow → exact command executes in the same turn;
4. Reject → command does not execute;
5. exact native option id round-trips through the now-bounded Room presentation;
6. then run the broader SERIAL regression: ordinary Task, >2 min turn, Task B truthfully queued, interrupt, follow-up, session coherence, permission allow/reject.

Only if that passes should the provider registry pin move from 1.6.2 to 1.12.0. Codex remains SERIAL and TaskSessionContinuation remains disabled.

No new Free4Chat permission design is needed before this probe.