Allow sub-agent escalation requests to inherit parent auto-approval policy

Open 💬 3 comments Opened May 18, 2026 by thomast8
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What problem are you trying to solve?

When Codex uses delegated sub-agents, a child agent can hit a sandbox escalation prompt, for example while running a safe verification command such as uv run .... In the main agent loop, the auto-approval mechanism can classify and approve safe recurring commands with narrow prefix rules, so the workflow remains autonomous.

For sub-agents, the same kind of escalation can block indefinitely because the parent agent does not appear to receive an actionable approval event, and the user is not necessarily watching the child thread. This makes review/exploration sub-agents less reliable, especially for long-running code review gates.

Desired behavior

Sub-agent escalation requests should be handled by the same approval policy available to the parent agent, or routed through the parent agent as an approval broker.

A useful behavior would be:

  • Child agent requests escalation for a command.
  • The request is evaluated by the inherited auto-approval classifier and existing approved prefix rules.
  • If approved, the sub-agent continues without user intervention.
  • If denied or ambiguous, the request is surfaced to the parent/main thread with the exact command, justification, and suggested prefix rule.
  • The child should not silently block in a place where neither the parent nor the user can keep the task moving.

Why this matters

Delegated review agents are most valuable when they can run in parallel and stay autonomous. Today, a parent agent can preflight common commands, but it cannot predict every verification command a sub-agent may discover while reviewing. When that happens, the sub-agent may stall instead of returning useful partial findings.

This pushes users toward brittle prompting rules like "sub-agents must never request escalation," which avoids deadlocks but also reduces verification quality.

Possible implementation

Consider one of these models:

  1. Inherit the parent thread's auto-approval policy and approved prefix rules into child agents.
  2. Route child escalation requests to the parent agent loop for classification.
  3. Add a sub-agent setting such as approval_policy = inherit | parent_brokered | never.

The key requirement is that sub-agent escalation should not create an unobserved blocking approval prompt.

Environment

Codex App with delegated sub-agents and sandboxed command execution.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #21982

Powered by Codex Action

1Ghasthunter1 · 1 month ago

Plz

ShadowTheFrog · 6 days ago

Adding a Windows Codex Desktop reproduction that shows why parent-brokered escalation matters for terminal callback workflows.

Environment

  • Codex Desktop: 26.818.4152.0
  • Bundled CLI: codex-cli 0.147.0
  • Windows 11 build 26200
  • Multi-agent/subagent workflow with workspace-write sandboxing

Reproduction shape

  1. A parent/orchestrator spawned one fresh, single-use subagent for a tiny callback canary.
  2. The parent deliberately ended its turn and became idle, avoiding status polling.
  3. The child was required to make one workspace-local write to a canonical callback journal, then send a native completion message to the idle parent.
  4. All task/repository preconditions matched, but the child hit Permission denied on the workspace-local journal write.
  5. No actionable approval/escalation event was surfaced to the parent. Consequently, the child could not create the callback or attempt the completion send, and the parent remained idle until a user message resumed it.
  6. A single bounded owner readback identified the permission failure; repeated polling was not used.

This is not a pure parent-wake reproduction of #15723 because the send was never reached. It is an example of this issue's core problem: a subagent's missing/inapplicable write authority or escalation path can silently strand an autonomous parent workflow.

Expected

  • The child should inherit the parent's effective approval/auto-review policy for a monotonic in-workspace operation, or
  • the escalation should be surfaced as an actionable parent event with the exact command/path and requested delta.

A subagent should not fail or wait invisibly while the parent has no event that can resume the workflow.

Current workaround
We are adding an explicit launch preflight that proves the child can write the exact callback store (or can request controlled escalation) before the parent enters passive wait. This reduces the symptom but does not replace a runtime-level inherited or parent-brokered approval path.