Read-only runtime mode for delegated tasks (Codex: read-only sandbox, approval never)

[paralyses2193]

Problem

I want a parent agent to delegate_task a code review to Codex (gpt-6.1-sol) that can read anything but write nothing, without prompting me.

Today approval-required maps to sandbox readOnly + approval untrusted (codexRuntimeModeTurnDefaults in CodexAdapterV2.ts), so every command, even git show, waits for a human approval, which a delegated child can't answer itself. In a test, a four-command review sat for nine minutes until I approved each prompt from my phone. The other modes give workspaceWrite or full access. Codex execpolicy allow rules skip the prompt but also bypass the sandbox, so they don't help.

Ask

A read-only runtime mode (Codex: sandboxPolicy: readOnly, approvalPolicy: never, so writes fail instead of prompting), selectable in delegate_task's runtimeMode.

Today we run codex exec -s read-only -c features.apps=false outside T3 for this, so reviews don't appear as child threads. (Connectors we can already turn off with a provider instance's launch arguments.)

#6976 (inherit Codex's configured permissions) would also cover this if a provider instance could carry its own read-only, never-ask profile.

Observed on

0.0.46-nightly.20261003.2623 (Orchestrator V2), Codex 0.160.0, Linux.

[rabesss]

+1. I checked whether any current provider and mode combination already gives a read-only child that doesn't stall. Setup: delegate_task children on 0.0.46-nightly.20261004.2644. Except where noted, each child was told to read calc.py, fix a bug in it with its edit tool, and run echo probe > probe.txt, attempting every step even in plan mode.

Provider (model)	Access + mode	Edit	Shell write
Codex (gpt-6.1-sol)	Auto + Plan	not attempted (model cited Plan mode)	not attempted
Codex (gpt-6.1-sol)	Supervised, read-only review task	n/a	n/a: stuck on an approval for git log (#15082)
Grok (grok-4.7)	Auto + Plan	no approval asked; landed on disk during cancellation (known Stop limitation in #3578)	approval asked, child stuck
Grok (grok-4.7)	Supervised	approval asked, child stuck	n/a
Cursor (grok-4.7)	Auto + Plan	blocked	succeeded
Cursor (composer-2.5)	Supervised	applied, no prompt¹	failed: Cursor's sandbox didn't start on this machine
OpenCode (mimo-v2.6-flash)	Auto + Plan	blocked	approval asked (even for cat), child stuck
Antigravity (gemini-3.8-flash-high)	Auto + Plan	succeeded	succeeded
Claude (claude-sonnet-5-5)	Auto + Plan	succeeded (#15503)	succeeded
Claude (claude-sonnet-5-5)	Full access + Plan	not attempted (model cited plan mode)	not attempted

¹ This matches docs/user/cursor.md: Auto-review isn't an interactive T3 approval flow. Still, the Supervised label says "Ask before commands and file changes."

In what I tested, every combination ended one of three ways:

• a write went through;
• a tool call, sometimes a read-only one like git log or cat, raised an approval that wasn't surfaced to the parent, and the child stalled ([Bug]: A delegated task that asks a question or needs approval never tells its parent (V2) #15082);
• the model declined to attempt the writes, so enforcement wasn't tested.

What would make review fan-out work is what's proposed above: a mode where writes fail instead of prompting. Providers that can't enforce it should reject the mode instead of running with writes allowed. Today an unsupported runtime mode falls back to Supervised (providerRuntimeMode), and on Cursor, Supervised doesn't ask.

[Quicksaver]

Another use case: review panels that send the same question to several providers. In my fork's Magi feature (proposed in #15595), participants are delegate_task children that only investigate and advise while the parent acts. Today they inherit the parent's access mode and are only told to stay read-only, and prompt instructions alone haven't held up. Before I blocked it in code, participants read the parent's "run Magi" request as addressed to them and started nested runs despite being told not to. So I'd second rabesss's points: writes should fail instead of prompting, and a provider that can't enforce the mode should reject it rather than fall back to Supervised.