[Windows App] Stale/orphaned subagents cause runaway session growth, thread errors, and archive failure

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

26.810.41047

What subscription do you have?

ChatGPT Work

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Long-running Codex App coordination sessions that use subagents can accumulate stale/orphaned agent state and very large JSONL transcripts. The App then becomes slow and unstable, the Subagents panel continues to show agents as active for days, repeated thread not found errors appear, and the affected task cannot be archived.

Observed in two successive coordination tasks:

• Task A transcript grew to approximately 1.20 GB.
• Task B transcript grew to approximately 472 MB.
• Task B's Subagents panel showed 2 agents still active for roughly 3 days and 54 completed agents.
• The UI repeatedly displayed thread not found for the affected task.
• Archiving the task failed with an App error.

No customer data, repository contents, prompts, or transcript attachments are included in this report.

What steps can reproduce the bug?

1. In the Windows Codex App, use a long-running main coordination task.
2. Spawn and complete multiple bounded subagent runs over time.
3. Mix subagent activity with coordination/wait activity across a long session.
4. Continue using the same task after completed agents accumulate in the Subagents panel.
5. Observe that some agents can remain shown as active after their useful work has ended.
6. Continue until the transcript becomes very large.
7. Reopen or interact with the affected task and attempt to archive it.

Observed results:

• Stale agents remain listed as Processing for days.
• Agent-related records and waits continue accumulating in session history.
• The App emits repeated thread not found errors.
• The task becomes difficult or impossible to use normally.
• Archive fails.
• Overall Codex App responsiveness degrades.

Affected session identifiers (provided for maintainers to correlate diagnostics):

• 019f5bdf-53b3-7fb3-ad75-9bee0194b844 (~1.20 GB transcript)
• 019fc779-001b-70e2-a2c0-645e8e4899d5 (~472 MB transcript)

What is the expected behavior?

Completed or terminated subagents should leave no live/orphaned runtime state. The App should enforce a hard circuit breaker before agent count or transcript size becomes dangerous, keep task ownership inspectable, allow reliable cancellation, and always allow an affected task to be archived. A stale agent must not generate persistent waits, callbacks, or repeated thread lookup failures.

Additional information

This appears related to #23700 (Stale Codex subagents), but the Windows App impact here also includes extreme transcript growth, repeated thread not found errors, system-wide App degradation, and archive failure.

Requested safeguards:

• Explicit subagent ownership by the initiating task
• No recursive subagent spawning unless explicitly enabled
• Configurable hard agent ceiling
• Per-run authorization and bounded lifetime
• Reliable cancellation and cleanup
• Session-size and agent-count circuit breakers
• Clear stale/orphaned state diagnostics
• Archive repair that does not require reopening or resuming corrupted runtime state

I can provide privacy-reviewed diagnostic counts or sanitized evidence if a maintainer identifies the exact safe diagnostic format needed. -----NEW INFO ---- The exact miss is now clear: MAIN 02 used visible thread-control tools wrapped inside custom_tool_call: exec, not just spawn_agent. The old script removed internal-agent calls but left 299 thread-routing calls plus their outputs, 126 duplicated session headers marked thread_source: subagent, 39 compaction payloads, 252 world-state snapshots, 975 turn contexts, and 1,077 old thread-setting records. Those are what rebuild the garbage and preserve the nightmare instructions.