codex: headless sessions run read-only and cannot write files (SetApprovalMode ignored in exec path)

[edwin-zvs]

Summary

A headless codex session (created with an initial prompt) runs codex exec in a read-only sandbox and cannot write files. It hard-blocks with "Blocked: the workspace is read-only, so index.html could not be [written]" and then goes silently to awaiting_input — no approval request, no error event the user can act on.

Why it happens

In crates/adapter-codex/src/main.rs the headless exec path:

• adds no --sandbox / -a (--ask-for-approval) flag, so codex uses its default read-only policy; and
• ignores AdapterInboxMsg::SetApprovalMode (the match arm just continues).

So changing the session approval mode (Manual / Auto-review / Unsafe-auto) in the TUI or webui has no effect on a headless codex session, and there is no agent new flag for sandbox/approval. The only workaround was reconfiguring the adapter command and restarting the daemon:

[adapters.codex.env]
AGENTD_CODEX_CMD = "codex --sandbox workspace-write --ask-for-approval never"

Repro

1. Isolated daemon, default config.
2. agent new codex "edit index.html to add X" --cwd <repo>
3. Session reports read-only block and stops; the file is never written.

Suggested fix

• Map the session approval mode to codex flags in the exec path, e.g. UnsafeAuto → --dangerously-bypass-approvals-and-sandbox, AutoReview → --sandbox workspace-write -a on-failure, Manual → read-only.
• Surface the read-only block as an error/approval event with a hint, not a silent awaiting_input.
• Document the codex sandbox default in docs/harnesses.md.

Related: #271 (auto-approve policy for codex/antigravity).

Found during an isolated dogfood run building a browser game with claude/codex/zarvis.

[rpelevin]

I would make the session approval mode part of the headless launch envelope, not only a TUI/web setting.

The current failure mode sounds especially confusing because the user changes approval mode, but the exec path launches with different effective authority and then reports a read-only block as awaiting_input without an approval event the user can answer.

For each headless Codex session I would record:

• session id;
• requested approval mode;
• effective Codex sandbox;
• effective Codex ask-for-approval policy;
• source of the mode: default, TUI, web, API, config;
• launch argv digest;
• cwd / workspace id;
• first blocked action, if any;
• blocker state: approval_required, sandbox_denied, unsupported_mode, runtime_error;
• user-action hint;
• terminal state.

The key distinction is: a sandbox denial is not the same as "waiting for input" unless there is a real approval request with an id and a way to resolve it.

Tests I would add:

1. Manual / Auto-review / Unsafe-auto each map to the documented Codex flags in the headless exec path.
2. SetApprovalMode changes the next headless launch envelope or returns an unsupported-mode event.
3. read-only write denial emits a sandbox_denied or approval_required event with a hint, not silent awaiting_input.
4. if approval is required, the event carries an approval id and the blocked action does not run before resolution.
5. if the mode is unsupported, the UI/API shows requested mode versus effective mode.
6. transcript/session metadata records the effective mode for later debugging.

That would make the authority boundary visible: the session asked for mode X, launched with mode Y, and either produced a resolvable approval request or a terminal sandbox denial.