spawn_agent forces approval_policy=never; breaks collab thread navigation and blocks sandbox escalation

Thanks — sharing a ready-to-cherry-pick patch for this issue.

PR #12714 was automatically closed because contributions are invitation-only, but the minimal fix is implemented here:

• commit: https://github.com/palvaleri/codex/commit/a02e26f60be900448ceaa7b9d1fe3f25b856fc59

Patch summary:

• stop clamping spawned threads to approval_policy=never in apply_spawn_agent_overrides (multi_agents handler)
• spawned subagents now inherit the parent thread’s effective approval policy (and allowed set)
• tests updated accordingly

Minimal diff:

fn apply_spawn_agent_overrides(config: &mut Config, child_depth: i32) {
-    config.permissions.approval_policy = Constrained::allow_only(AskForApproval::Never);
     let max_depth = max_thread_spawn_depth(config.agent_max_spawn_depth);
     if exceeds_thread_spawn_depth_limit(child_depth + 1, max_depth) {
         config.features.disable(Feature::Collab);
     }
}

Why this matters in practice:

• interactive Collab users running -a on-request hit OnRequest is not in the allowed set [Never] when navigating/resuming spawned agent threads
• on macOS workspace-write sandbox, Playwright/Chromium frequently requires sandbox escalation; with approval_policy=never, spawned agents can never request it, forcing danger-full-access as a workaround

If you want to keep the current default for safety, a follow-up alternative is to make this behavior configurable (default: clamp, opt-in: inherit), but the above commit is the smallest behaviorally-correct fix for interactive Collab.

This will be removed once the UX is good enough such the approval requests are correctly piped to you. In the meantime we keep it like this on purpose

Thanks for confirming this is intentional for now.

Even if spawned threads are clamped to approval_policy=never, the current UX is rough for interactive Collab sessions started with -a on-request:

1) Switching to a spawned agent thread from the TUI (/agents) and sending a message often triggers OnRequest is not in the allowed set [Never]. Sometimes the thread becomes “stuck” at the final message / you can’t continue the conversation.
2) This is especially painful on macOS workspace-write where Playwright/Chromium frequently needs sandbox escalation; with never the subagent can’t request it, pushing users to danger-full-access.

Suggested improvements (keeping the safety clamp):

• When attaching/resuming a thread, the client should use the thread’s own allowed set and silently clamp the effective policy for that thread (or show a one-time banner), rather than emitting a confusing validation error and/or failing send_input.
• In /agents, show each agent thread’s effective approval_policy (and maybe sandbox_mode) so the user understands why approvals won’t happen.
• If the long-term plan is “pipe approvals to the user via parent”, it would help to document current workarounds (e.g. configuring rules/allowlists for common tools like Playwright), so Collab remains usable without danger-full-access.

Happy to provide a minimal repro script / rollouts if useful.

One more clarifying point on severity: in the current TUI Collab flow this is not just a warning—after switching to a spawned agent via /agents, attempting to send any message can fail immediately with the allowed-set mismatch (send_input errored / UI rejects the turn). In other words: sometimes you can’t even ask the subagent a question, making Collab effectively unusable in interactive (-a on-request) sessions.

Workaround we found (Codex CLI 0.106.0, interactive Collab TUI):

• Start the manager/parent session with -a never (or re-attach/resume the manager SID with -a never before spawning / switching to agents).
• Once the parent is never, /agents navigation + sending messages to spawned agents works reliably (no OnRequest is not in the allowed set [Never] / no immediate send_input failure), because the whole tree shares allowed-set [Never].

Tradeoff: no interactive approvals anywhere, so for things like Playwright on macOS workspace-write you need to pre-allow the required command prefixes via rules/allowlists (or use a higher permission preset).