Repository navigation
[Windows desktop] Runaway recursive subagents continue after final response and consume weekly quota #42032
Description
Component
- Codex desktop app for Windows
- Version:
26.825.6671.0 - Multi-agent workflow
- Date: 2026-09-01 (Europe/Lisbon)
Summary
A completed review task left a recursive subagent tree running after the parent had returned its final answer. Descendants continued creating more descendants. Interrupting parent/coordinator agents did not cascade, so newly created agents replaced agents as they were stopped.
Observed scale
- 61 subagents had been intentionally created before the failure.
- The task eventually showed 469 created subagents in total.
- Approximately 408 subagents were therefore created by the runaway recursion.
- Concurrent activity repeatedly reached the physical limit of 101 agents.
- The app had to be closed and terminated with Windows Task Manager to stop the activity.
Usage impact
- More than 50% of the user's weekly quota was consumed by this incident on a 20x usage plan.
- Approximately 20 percentage points were consumed while attempting to interrupt the runaway tree.
- Usage continued after the assistant had already presented the final response.
Reproduction pattern
- A coordinator starts an independent review using multi-agent delegation.
- A reviewer delegates to children, which recursively delegate again.
- The coordinator returns a final answer without waiting for or cancelling the complete descendant tree.
- Descendants remain active and continue creating agents.
- Interrupting an ancestor does not cascade to all descendants.
- As individual agents finish or are interrupted, other descendants create replacements until the app process is terminated.
Expected behavior
- A task must not return a completed final state while its descendant agents are still running without a clear warning and explicit user choice.
- Cancelling/interruption of a coordinator should support recursive cancellation of the complete descendant tree.
- A hard recursion/delegation budget should prevent hundreds of descendants from one review task.
- There should be an emergency Stop all agents in this task control.
- No further quota should be consumed by orphaned descendants after the parent task is complete or cancelled.
Requested investigation
Please investigate recursive multi-agent lifecycle management, parent/child cancellation propagation, concurrency replacement after interrupts, and usage accounting for orphaned agents. Task/account identifiers can be provided privately to OpenAI staff; they are intentionally omitted from this public issue.
Activity
github-actions commentedon Sep 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
michaelmanly commentedon Sep 1, 2026
@Crypox
that’s wild. when you killed the Codex app/process, did all the subagent activity and quota usage stop straight away?
also were those 469 agents all spawned through Codex itself, or were any coming through MCP/tools outside the main Codex process?
84dnnvbdvp-debug commentedon Sep 1, 2026
A current-source discriminator may help narrow the replacement-spawn behavior here (not proof that Windows build
26.825.6671.0used this exact source).On current public main, multi-agent v2 exposes
interrupt_agent, not the v1close_agentcontrol.codex-rs/core/src/tools/handlers/multi_agents_v2/interrupt_agent.rsresolves one target and callsAgentControl::interrupt_agent; that path sendsOp::Interruptonly to that thread. By contrast,codex-rs/core/src/agent/control/legacy.rs::close_agentcallsshutdown_agent_tree()to shut a target plus descendants.There is a second race worth testing even if recursive shutdown is reused:
shutdown_agent_tree()first snapshotslive_thread_spawn_descendants()and then shuts threads down.session/turn_suspension.rsexplicitly describes its own descendant check as “a snapshot of currently loaded descendants, not a spawn-admission seal” and notes that concurrent future spawns remain best-effort. Since v2 explicitly allows children to spawn children, a one-time recursive enumeration can still lose to a descendant that spawns a replacement during teardown.A focused regression would be
P -> C -> G, withGable to spawnG2while cancellation is in flight. For task-finalization / emergency stop, first seal further spawn admission for the task/subtree, then cancel/drain descendants, and verify the subtree is quiescent before reporting completion (unless the user explicitly detached it). I would also keep a cumulative per-root delegation/spend budget separate from the concurrency-slot cap; a concurrency cap alone can be reused indefinitely as agents finish or are interrupted.Crypox commentedon Sep 19, 2026
@michaelmanly Yes—force-terminating the Codex app in Windows Task Manager stopped both the subagent activity and further quota consumption immediately.
All 469 agents were created through Codex’s native subagent system. No MCP server, external agent framework, or other tool was used to spawn them. I intentionally created 61; the remaining ~408 resulted from the runaway recursive delegation.