Codex Desktop does not enforce subagent cap or delegation depth, then root-scoped controls cannot clean up the full tree

What version of the Codex App are you using?

Codex Desktop 26.803.61601 (build 6396).

What platform is your computer?

macOS / Apple Silicon.

Summary

A long-running Desktop task accumulated 64 successful root-level spawn_agent calls over approximately two days. Some children also spawned children recursively, producing observed agent paths at least six levels deep.

The task's explicit project instructions imposed both of these safety limits:

• no more than 15 agents total in the task
• delegation depth 1 only; workers must not spawn workers

Those limits were not enforced by the runtime. Eventually the Desktop UI showed 94 active subagent entries and the computer became severely resource-constrained.

The cleanup path then produced a second failure: the root-scoped agent listing reported only /root, so the assistant incorrectly concluded that all workers had stopped. The UI still showed 94 active entries. The retained parent record contains only 10 root-level interrupt_agent calls for 64 root-level spawn calls, and recursive descendants were not globally enumerable through the scoped control path.

No raw transcript, encrypted task payloads, repository names, source, credentials, or private logs are attached to this public report.

Sanitized evidence

From the original parent rollout:

spawn_agent calls:     64
interrupt_agent calls: 10
list_agents calls:     38
wait_agent calls:      56

The 64 spawn calls occurred between 2026-08-10 and 2026-08-12. They were not all issued in a single burst.

Examples of recursively created paths visible in retained activity events:

/root/final_diff_review/asset_test_scan/tests_identity_scan/identity_claim_check/parity_review/home_identity_review

/root/domain_cutover_map/edge_architecture_audit/redirect_source_audit/config_redirect_scan/cf_worker_scan/redirect_patterns

At the incident point:

• Desktop UI showed 94 active agents
• root-scoped listing reported only /root
• the assistant announced successful cleanup based on that incomplete listing
• the UI contradicted the control result
• the machine was severely slowed / destabilized

After restarting into a fresh Desktop task, an OS process audit found no remaining codex exec worker swarm. This suggests the 94-entry symptom may include stale registry/UI state, but it does not remove the earlier runtime-cap and recursive-delegation failure.

Steps to reproduce

1. Start a long-running Desktop task with multi-agent enabled.
2. Give the task a textual safety limit, for example a total cap of 15 agents and depth 1.
3. Over multiple turns, allow the parent to call spawn_agent repeatedly.
4. Allow at least one child to attempt nested delegation.
5. Observe that the runtime continues accepting launches after the textual cap and beyond depth 1.
6. Accumulate enough agents that the Desktop list becomes large and the machine slows down.
7. From the root task, use the agent-listing and interrupt controls to stop all workers.
8. Observe that the root-scoped listing may show only /root while Desktop still displays many active child entries.

Expected behavior

• The runtime should enforce a configurable hard total-agent cap independent of model compliance.
• The runtime should enforce maximum delegation depth.
• A child marked as non-delegating should not receive or be able to invoke spawn_agent.
• The control plane should expose a global, authoritative list for the task lineage.
• “Stop all” should atomically enumerate and terminate every descendant, then reconcile UI and backend state.
• The app should never allow an incomplete scoped listing to look like proof that global cleanup succeeded.
• When limits are reached, additional spawn calls should fail with a clear error before resource exhaustion.

Actual behavior

• 64 root-level spawn calls were accepted over the task lifetime despite a 15-agent textual cap.
• Recursive child paths reached at least six levels despite a depth-1 rule.
• Desktop displayed 94 active entries and the Mac became unstable.
• Root-scoped cleanup controls did not expose the full set.
• A false successful-cleanup conclusion was possible because the listing and UI disagreed.

Related issues

• #19197 covers orphaned agents, incomplete cleanup, and frozen sessions.
• #25179 covers stale Desktop subagent UI/cache entries.
• #24668 covers UI degradation at 15 agents.
• #16688 covered TUI freezing during large fan-out.

This report adds a distinct safety/control-plane failure: runtime non-enforcement of total-agent and delegation-depth limits, plus the absence of an authoritative lineage-wide cleanup operation.

Suggested fix

1. Enforce max total descendants and max depth server-side in the spawn handler.
2. Propagate a non-delegating capability to workers and omit/reject the spawn tool there.
3. Add an authoritative lineage identifier and global descendant query.
4. Add an idempotent “interrupt entire lineage” operation.
5. Reconcile the Desktop list from backend lifecycle state after cleanup and on app restart.
6. Surface a warning when UI count and control-plane count disagree.