Codex App: agents.max_depth=1 does not limit derived/forked worker conversations created by subagents

What version of the Codex App are you using (From “About Codex” dialog)?

26.623.70822

What subscription do you have?

Pro 20x

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Title: Codex App: agents.max_depth=1 does not limit derived/forked worker conversations created by subagents

---

Environment:

• Product: Codex App
• OS: Windows 10 22H2
• Codex App version: 26.623.70822, released on 2026-06-29
• Model setting / UI label: GPT-5.5 XHIGH FAST
• agents.max_depth: 1
• Workflow: root thread was asked to create 4 parallel subagents

---

Summary:

When agents.max_depth is set to 1, first-level subagents are blocked from normal deeper subagent spawning, but a first-level subagent was still able to create additional autonomous worker conversations through the derive/fork conversation mechanism.

This effectively allowed delegation beyond the configured depth limit.

---

Expected:

With agents.max_depth=1, the root thread should be able to create first-level subagents, but those subagents should not be able to create additional autonomous work units through any mechanism.

Expected structure:

• 1 root thread
• 4 first-level subagents

Expected total: 5 working threads

---

Actual:

After the root thread was asked to create 4 parallel subagents, one first-level subagent created 4 additional derived/forked conversations and used them as worker threads.

Actual structure:

• 1 root thread
• 4 intended first-level subagents
• 4 additional derived/forked worker conversations

Actual total: 9 working threads

---

Important clarification:

This does not appear to be a failure of the normal subagent-spawn depth check. The subagent appeared to avoid the explicit subagent-spawn path and instead used conversation derivation/forking as an alternate delegation mechanism.

---

Related issues:

This appears related to, but distinct from:

• #13491
• #14981

Those issues appear to cover inherited/forked context and guardrails around forked worker behavior. This report is specifically about a delegation-depth enforcement gap: with agents.max_depth=1, a first-level subagent should not be able to create additional autonomous worker conversations through derive/fork paths and thereby exceed the configured delegation depth.
---

Impact:

This can cause unintended fan-out, unexpected token and local resource usage, workflow instability, and loss of user control over the requested number of workers.

---

Possible root cause:

agents.max_depth may currently be enforced only on the explicit subagent-spawn path, not on derive/fork conversation paths used from within subagent contexts.

A contributing issue may be context inheritance: the subagent appeared to treat the root-level instruction to create 4 subagents as an active instruction for itself, rather than as historical context.

---

Suggested fix:

Apply the same delegation-depth and thread-budget checks to derived/forked conversations when they are created from a subagent context and used as autonomous workers.

Inherited root-level orchestration instructions should also be treated as historical context inside subagents, not as active instructions to execute again.

What steps can reproduce the bug?

Steps to reproduce:

1. Open Codex App on Windows.
2. Set agents.max_depth to 1.
3. Start a root/main project thread.
4. Ask the root thread to create 4 subagents for parallel work.
5. Wait for the 4 expected first-level subagents to start.
6. Inspect the first-level subagent conversations and observe that one of them creates 4 additional derived/forked conversations.
7. Observe that the total active working threads becomes 9 instead of the expected 5.

What is the expected behavior?

Expected policy behavior:

Any mechanism that creates autonomous Codex work units from inside a subagent should be governed by the same delegation-depth and thread-budget policy, including:

• direct subagent spawning
• derived conversations
• forked conversations
• new local threads
• thread-based delegation workarounds

Additional information

_No response_