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

Activity

1. robertor-develop

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Aug 15, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   performance

   on Aug 15, 2026
3. github-actions commented on Aug 15, 2026

   

   github-actionsbot

   on Aug 15, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • [Windows] Old subagents remain stuck as running after restarting Codex App #38408
   • Subagents panel permanently shows completed agents as Active and Working #38364
   • Codex Desktop shows growing number of phantom working subagents #38577
   • Codex Desktop: completed subagents remain shown as running/processing in the summary panel #38478

   Powered by Codex Action
4. pomazanbohdan commented on Aug 23, 2026

   

   pomazanbohdan

   on Aug 23, 2026

   More actions

   Additional Windows cluster evidence: stale/orphaned children, persisted Active/Working state, large rollout growth, and archive failures appeared together after long multi-agent sessions. The cluster separates live execution from persisted projection/residency (#37042 and #39694) and requires backup-first cleanup with post-restart parity checks.
5. LAVMendonca-labs commented on Aug 23, 2026

   

   LAVMendonca-labs

   on Aug 23, 2026 – with ChatGPT Codex Connector

   More actions

   Fresh Windows reproduction on Codex Desktop 26.818.5229.0:

   • The Subagents panel shows 11 historical children as Processing, with displayed ages of roughly 1 day to 9 days.
   • Local lifecycle evidence shows that 10 of those 11 children had already emitted at least one FINAL_ANSWER. One has no visible terminal result.
   • The current collaboration readback does not expose those historical children; attempting to interrupt one by its former canonical path returns not_found.
   • Despite that, the UI continues to render all 11 as active/processing.
   • App-level list_threads did not return after more than 45 seconds and had to be aborted. An individual read_thread attempt against one stale child also did not return after more than 30 seconds.
   • The affected rollout is currently about 58.14 MiB.

   This looks like persisted UI/session projection diverging from authoritative runtime state, consistent with the issue description. No prompts, repository contents, private paths, credentials, or thread IDs are included here. A cropped Subagents-panel screenshot is available privately if maintainers need it.
6. sideburns42 commented on Sep 16, 2026

   

   sideburns42

   on Sep 16, 2026

   More actions

   macOS variant: stale/orphaned subagents persist and exhaust agent capacity

   Related issue: #38805

   Environment

   • Codex desktop app on macOS
   • ChatGPT Work account
   • App version: [fill from About Codex]
   • macOS version: [fill in]
   • Date observed: 2026-09-16

   Summary

   A long-running Codex coordination task accumulated a very large number of subagent contexts. The task UI eventually displayed approximately 234 subagents.

   Many of these appeared to be completed or inactive, but the aggregate count persisted. Quitting and relaunching the ChatGPT/Codex application did not visibly clear the count. Other Work tasks did not show the same subagent population.

   The behavior appears to be a macOS variant of the stale/orphaned subagent problem described in issue #38805.

   Reproduction pattern

   1. Use one long-running coordination task.
   2. Spawn many bounded worker and reviewer subagents over time.
   3. Complete workers and attempt to close them after their handoffs.
   4. Continue using the same parent task for additional waves of work.
   5. Observe the Subagents count grow substantially.
   6. Quit and relaunch the desktop application.
   7. Reopen the task and observe that the accumulated subagent count remains.
   8. Attempt to continue spawning agents.

   Observed behavior

   • The task displayed approximately 234 subagents.
   • Completed or obsolete contexts appeared to remain associated with the task.
   • There was no visible global inventory or reliable bulk-cleanup control.
   • The orchestration layer eventually returned an agent thread limit reached error when additional workers were requested.
   • The controller could close known agent IDs individually, but could not enumerate or clean up unknown historical/orphaned contexts.
   • Archiving the parent task was unclear as a cleanup mechanism and did not provide confidence that subagent capacity would be released.
   • Restarting the application did not appear to reconcile the persisted subagent count.

   Expected behavior

   • Completed, interrupted, or explicitly closed subagents should be removed from active capacity accounting.
   • Restarting the application should reconcile persisted agent state with actual runtime state.
   • The parent task should expose a reliable inventory of child agents and a safe “close all completed/orphaned agents” operation.
   • Historical child records should not continue consuming the session’s agent limit.
   • Archiving a parent task should either clean up its child-agent runtime state or clearly document that separate cleanup is required.
   • A circuit breaker should prevent a task from accumulating hundreds of stale child contexts.

   Diagnostic information

   In this case:

   • The parent task was a long-running product-owner/orchestration task.
   • Workers and reviewers were created for independent repository research, evidence review, and implementation handoffs.
   • Durable work products were retained externally in GitHub Draft pull requests.
   • Known temporary agents were closed after handoff where the controller could address them.
   • At least one obsolete completed worker was still discoverable later and had to be closed manually.
   • The UI count was substantially larger than the set of currently active workers.
   • No customer data, repository contents, private prompts, or full transcripts are included here.

   Potentially useful diagnostics for maintainers:

   • Parent task/session identifier: [fill from task details if available]
   • Current app version and macOS version
   • Screenshot showing the 234-subagent count
   • Sanitized subagent-state metadata showing terminal versus active status
   • Whether the count decreases after closing a known completed agent
   • Whether the count changes after archiving/unarchiving the parent task
   • Any app logs containing thread not found, stale callback, orphan cleanup, or agent-limit errors

   Hypothesis

   The parent task may be retaining persisted child-agent records after their runtime state has terminated. Capacity accounting may be based on historical child records rather than live agent state, and application restart may not reconcile those records.

   This is a hypothesis only; the important symptom is that completed/orphaned subagent state appears to remain attached to the task and can exhaust the agent limit.

   Impact

   This makes long-running coordination tasks progressively less usable:

   • New parallel work cannot be started.
   • The task becomes difficult to recover or archive.
   • Users cannot determine which contexts are actually live.
   • Manual cleanup requires already knowing individual agent identifiers.
   • Restarting the application does not provide a reliable recovery path.

   Powered by Codex & OWL
   Version 26.908.70816

   Released Sep 14, 2026