Repository navigation
compat(agent): re-verify Codex Room approvals on current codex-acp #426
Description
Why
Free4Chat #297 classified Codex Room approval as an upstream limitation based on older codex-acp versions.
Free4Chat currently pins @agentclientprotocol/[email protected]. 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_escalatedmay fail to surfacerequestApproval; 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 VERIFIEDPARTIALUPSTREAM APP-SERVER LIMITATIONUPSTREAM BRIDGE LIMITATION
Acceptance
- probe current
codex-acp1.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-serverrequestApproval
→codex-acpsession/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,
TaskSessionContinuationunchanged; - 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
Activity
madawei2699 commentedon Sep 20, 2026
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 commentedon Sep 20, 2026
#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:cf-sfu;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.
Merge pull request #432 from i365dev/codex/codex-acp-1-12-0
compat(agent): verify Codex Room approval and pin codex-acp 1.12.0 (i…