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:
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:
- Open Codex App on Windows.
- Set
agents.max_depth to 1.
- Start a root/main project thread.
- Ask the root thread to create 4 subagents for parallel work.
- Wait for the 4 expected first-level subagents to start.
- Inspect the first-level subagent conversations and observe that one of them creates 4 additional derived/forked conversations.
- 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
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=1does not limit derived/forked worker conversations created by subagentsEnvironment:
agents.max_depth: 1Summary:
When
agents.max_depthis 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:
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:
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:
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_depthmay 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:
agents.max_depthto 1.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:
Additional information
No response