Subagents panel permanently shows completed agents as Active and Working

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

• #37222
• #37563
• #37802
• #37426
• #38050

Powered by Codex Action

Same here on Mac, I got 129 "working" agents and don't know how to mark them inactive.

Confirmed on Codex Desktop 26.803.10989.0 / bundled CLI 0.147.0-alpha.6.6 / Windows 11 build 26200, with a much larger affected graph and a read-only comparison between the UI, persisted state, rollout lifecycle, and live processes.

Configuration:

[agents]
max_concurrent_threads_per_session = 6

Observed in one parent task:

• Desktop panel: 273 Active + 13 Done
• The parent timeline/runtime reported 1 currently active child; five recently used children were completed or interrupted.
• A recursive query of ~/.codex/state_5.sqlite found 286 descendants: 81 direct children, maximum depth 7.
• Exact correlation: 273 + 13 = 286.
• All 286 rows in thread_spawn_edges still had status = 'open'.
• Last durable rollout lifecycle event across those 286 children:
• 268: task_started
• 10: task_complete
• 8: turn_aborted
• A simultaneous Windows process snapshot showed one codex.exe, one code-mode host, and 9 node_repl.exe children—not hundreds of executing workers.

This means the panel's 273 count is not evidence that the concurrency cap was exceeded. It is an accumulated historical graph/lifecycle count being presented as live execution. The configured cap appears to bound current V2 residency/execution, while persisted open edges and incomplete terminal records survive across sequential batches, eviction, crash/restart, or resume.

A source-level candidate is the separation between V2 residency eviction and persistent graph state: current main can shutdown_and_wait and remove an unloadable resident to make room for another child, while thread_spawn_edges is marked closed on explicit close_agent. Regardless of the exact repair site, an open graph edge must not be sufficient to classify a child as Active/Working.

Suggested invariant and regression:

1. Active must be derived from an authoritative live execution/residency state, not cumulative spawn history.
2. Completion, interruption, eviction, startup failure, and app-server shutdown must persist a durable non-running lifecycle state.
3. On restart/resume, reconcile graph edges and rollout terminal state without resuming the child runtime.
4. With cap 6, spawn more than 6 children sequentially, restart Desktop, and assert:

• live Active count never exceeds 6;
• completed/evicted history remains available under Done/history;
• opening the parent or a terminal child creates no MCP/node_repl runtime.

1. Consider displaying separate counters such as executing, resident, and historical so a concurrency limit cannot be confused with cumulative descendants.

The resource impact is not purely cosmetic: stale historical hydration can also recreate tool/MCP stacks, as reported in #37453. The MCP capability/broker side is tracked separately in #38353.

Additional quantified Windows reproduction on a newer build, plus a cross-thread scoping symptom.

Environment

• Codex Desktop for Windows: 26.810.4967.0
• Bundled Codex runtime observed in session metadata: 0.148.0-alpha.9
• OS: Windows 10.0.26200.0 x64

Same-parent status misclassification

For one long-running parent task, the Desktop Subagents summary displayed:

21 Working + 1 Done = 22

A read-only audit of that parent's local rollout metadata found exactly 22 unique directly spawned child threads, but their current/terminal states were:

3 active
15 task_complete
4 turn_aborted

The three genuinely active children were still appending rollout events, and the parent was waiting on an active collaboration wait. The other 19 child rollouts had terminal completion or abort events and no resumed active turn.

So the panel's total matched the historical child-thread count, but the status partition was wrong: it presented almost all historical children as Working.

Cross-parent panel leakage

There was a second, independently observable UI problem:

1. Parent A had the three genuinely active children above.
2. I selected unrelated Parent B in the Desktop UI.
3. Parent B's backend thread state was idle; its recent turns were completed and its child rollouts were terminal.
4. Parent B's environment sidebar still displayed 3 Working subagents.
5. Those three entries corresponded exactly to Parent A's live children.

This suggests the sidebar can retain or bind to a global/previous-parent subagent aggregate instead of the currently selected parent.

Expected

• Working should count only authoritative live execution for the currently selected parent.
• Completed and aborted historical children should not be grouped under Working.
• Switching threads should rebind/clear the Subagents summary so another parent's children cannot appear in the selected task.
• If a historical child is resumable but not executing, a neutral Waiting/Resumable state would be safer than Working.

This reproduction does not establish continuing token consumption or a process leak; it establishes a deterministic mismatch between the Desktop presentation, parent ownership, and rollout lifecycle state.

No screenshots, project names, local paths, prompts, account information, or private thread identifiers are included. I can provide redacted identifiers privately if maintainers need them.

Independent reproduction on the same Windows desktop build.

Environment

• Codex Desktop: 26.803.10989.0 (x64)
• Windows
• Long-running parent task with many sequential subagents

Observed mismatch

• Desktop Subagents panel: Active · 29
• All 29 rows were labeled Working; many timers had continued for roughly 1–2 days.
• At the same moment, the authoritative live collaboration tree contained 1 running child.
• The same live tree identified one prior reviewer as terminal/completed and another prior worker as completed, while older children displayed by the panel were absent from the live tree.

So the panel overstated live child execution by 28 and presented historical/terminal children as currently Working. This reproduces the issue without establishing ongoing token use or compute for the stale rows.

A redacted screenshot showing Active · 29 and the multi-day Working rows is available if maintainers need it.

Expected

• Active should be derived from authoritative live execution for the selected parent.
• Completed, interrupted, evicted, or otherwise nonresident children should move to Done/history and stop accumulating duration.
• Opening/reloading a long-running task should reconcile persisted spawn history with current terminal/live state.
• The panel should ideally expose separate live and historical counts so users can trust whether work is actually running.

Confirmed independently on macOS.

Environment:

• Codex Desktop 26.810.52044 (CFBundleVersion 6662)
• Bundle id com.openai.codex
• macOS 26.2 (25C56), arm64

Observed:

• Subagents panel displayed Active · 33.
• Every visible entry was marked Working, with elapsed counters ranging from ~11 hours to nearly 3 days.
• The entries corresponded to helper agents that had already returned final results.
• A live coordinator query at the same moment returned exactly one active agent: /root, with no live subagents.
• The runtime concurrency limit was four slots, so 33 concurrently running subagents was not possible.

This strongly supports a stale presentation/reconciliation bug rather than continuing model execution. The panel appears to preserve historical start/working state after the coordinator has transitioned or removed the agents. It should reconcile against the live agent registry on panel open and after task restoration, and elapsed timers should stop for terminal agents.

A screenshot exists, but I am not attaching it publicly because the subagent titles contain private task context. I can provide a redacted version or private identifiers to maintainers if useful.

The durable lifecycle mismatch here is a good codex-rescue==0.1.0a4 field case. doctor will not change thread_spawn_edges, stop agents, or fix the Desktop panel, but it can independently inspect an affected child/parent rollout for terminal vs unfinished tool/lifecycle evidence and structural/schema findings.

For one representative affected rollout, could you run the read-only check locally:

codex-rescue doctor --json "/path/to/the-affected-rollout.jsonl"

A sanitized summary of status/findings/aggregate counts is enough. Please do not post raw JSONL/SQLite, prompts, tool arguments/output, thread IDs, repository data, credentials, usernames, or private paths.

This issue has been burning through my weekly limits extremely fast. Every 10 minutes of idle activity in a single chat burns about 1% of my weekly Pro 20x usage limits.

This chat has 216 'active' subagents when opened. All were last active 1-4 days ago. After about 20 minutes the 216 active went to 207 active and 9 done. Which drained 2% of my weekly usage with no other chat or background task running at that time. Closing the ChatGPT Codex app fully stopped my usage from draining further.

Context:

• This chat was using /goal for ~48 hours straight working on a large task. The goal was manually paused and still correctly shows as paused when opening the chat.
• I very often saw Authentication expired. Reconnect to keep using this MCP server message while using the app. I suspect this was coming from some of the 216 completed subagents.
• CPU/GPU usage was relatively high for the ChatGPT Codex app even though I had no active chats. Suggesting these complete subagents were very actively doing things.
• ~Opening the chatGPT app but not opening the specific chat also seems to prevent these subagents from becoming active.~ Seems it kept burning tokens, my usage fully drained to 0% while no task was running.
• Usage at https://chatgpt.com/codex/cloud/settings/analytics reports 55% of my usage yesterday from "Exec" and 235 turns yesterday with "gpt 5.5", which is not a model is selected to use.
• It seems gpt 5.5 usage came from Chronicle (Computer History) creating excessive amount of summaries. This is the default model in the codex_chronicle binary in the app because no model was set.

Environment:
ChatGPT Codex app 26.814.41407
OS: Mac OS 26.6.1

I'm pretty usre this is also what's been causing my 429 errors that have
been constantly popping too possibly.

On Wed, Aug 19, 2026 at 8:56 AM Dorusvandenoord @.***>
wrote:

Dorusvandenoord left a comment (openai/codex#38364) <https://github.com/openai/codex/issues/38364#issuecomment-5342413159> This issue has been burning through my weekly limits extremely fast. Every 10 minutes of idle activity in a single chat burns about 1% of my weekly Pro 20x usage limits. This chat has 216 'active' subagents when opened. All were last active 1-4 days ago. After about 20 minutes the 216 active went to 207 active and 9 done. Which drained 2% of my weekly usage with no other chat or background task running at that time. Closing the ChatGPT Codex app fully stopped my usage from draining further. Context: - This chat was using /goal for ~48 hours straight working on a large task. The goal was manually paused and still correctly shows as paused when opening the chat. - I very often saw Authentication expired. Reconnect to keep using this MCP server message while using the app. I suspect this was coming from some of the 216 completed subagents. - CPU/GPU usage was relatively high for the ChatGPT Codex app even though I had no active chats. Suggesting these complete subagents were very actively doing things. - Opening the chatGPT app but not opening the specific chat also seems to prevent these subagents from becoming active. Environment: ChatGPT Codex app 26.814.41407 OS: Mac OS 26.6.1 — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/38364?email_source=notifications&email_token=AFKHFCTPQN6IWHB5WUN7DGT5KWPYNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZUGI2DCMZRGU42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5342413159>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFKHFCWC2IUFEJXLIG6DHUL5KWPYNAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKMJUGEYTSMZUGY2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AFKHFCRGCFLHDD4WO5BH7QT5KWPYNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZUGI2DCMZRGU42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AFKHFCVXSEUG3PSTWSXU46T5KWPYNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZUGI2DCMZRGU42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: @.***>

Independent Windows reproduction on a newer build; the stale state survives multiple full App quits, relaunches, and App package updates.

Environment:

• Codex Desktop MSIX: 26.818.2872.0 (x64)
• Windows: 10.0.26200.0

Observed in one long-running parent task:

• Environment sidebar: 32 working / 17 done
• Expanded Subagents panel: the same historical rows remain labeled Working, with timers around 7–11 days
• Authoritative live collaboration registry queried at the same time: only /root is running; no live child agents exist
• Fully closing and reopening the App does not reconcile the counts
• Updating the App package also does not reconcile them

This confirms that opening/restarting/updating the App is insufficient to repair the persisted presentation state. It does not establish continuing model execution or resource consumption; it establishes a deterministic mismatch between the live agent registry and the Desktop sidebar/panel.

Expected:

1. On task load and App restart/update, reconcile historical spawn edges against authoritative live/terminal child state.
2. Show only genuinely executing children as Working.
3. Move completed/interrupted/evicted children to Done/history and stop their timers.
4. Do not require opening each stale child to repair its status.

I am not attaching the screenshot publicly because the visible subagent titles and branch name contain private project context. Redacted identifiers can be provided privately if maintainers need them.

Yeah and I had over 38 today 'working' and some that properly closed out. I
asked my agents if they could verify and they said it all appeared shut
down and no active workers, yet I had some that closed while others keep
counting. Unless their counters are a literal start counter and stop
counter and have nothing to do with actual agents working, then that's a
problem they should resolve and actually create counters that count real
information.

On Thu, Aug 20, 2026, 6:17 PM Axiom @.***> wrote:

axiom-ncis left a comment (openai/codex#38364) <https://github.com/openai/codex/issues/38364#issuecomment-5362674485> Independent Windows reproduction on a newer build; the stale state survives multiple full App quits, relaunches, and App package updates. Environment: - Codex Desktop MSIX: 26.818.2872.0 (x64) - Windows: 10.0.26200.0 Observed in one long-running parent task: - Environment sidebar: 32 working / 17 done - Expanded Subagents panel: the same historical rows remain labeled Working, with timers around 7–11 days - Authoritative live collaboration registry queried at the same time: only /root is running; no live child agents exist - Fully closing and reopening the App does not reconcile the counts - Updating the App package also does not reconcile them This confirms that opening/restarting/updating the App is insufficient to repair the persisted presentation state. It does not establish continuing model execution or resource consumption; it establishes a deterministic mismatch between the live agent registry and the Desktop sidebar/panel. Expected: 1. On task load and App restart/update, reconcile historical spawn edges against authoritative live/terminal child state. 2. Show only genuinely executing children as Working. 3. Move completed/interrupted/evicted children to Done/history and stop their timers. 4. Do not require opening each stale child to repair its status. I am not attaching the screenshot publicly because the visible subagent titles and branch name contain private project context. Redacted identifiers can be provided privately if maintainers need them. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/38364?email_source=notifications&email_token=AFKHFCVJC644CRGWK5WQN2L5K52HHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZWGI3DONBUHA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5362674485>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFKHFCUJQGKZKO6WB2BMD7L5K52HHAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKMJUGEYTSMZUGY2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AFKHFCTHCZCV2UAGMGVARED5K52HHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZWGI3DONBUHA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AFKHFCTEHE4NEOWF6G7SHSL5K52HHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZWGI3DONBUHA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: @.***>

Additional Windows reproduction with direct app-server evidence:

• Codex Desktop: 26.814.5167.0
• Platform: Windows x64
• The Subagents panel initially showed Active: 68.
• Every visible row was labeled Working, with elapsed timers continuing for roughly 5–12 hours.
• Restarting Codex did not reconcile the panel. The displayed count increased from 68 to 72 while no new subagents were spawned.
• Opening an individual stale entry sometimes caused that entry to disappear, suggesting lazy per-item reconciliation.

Read-only app-server check at 2026-08-21T08:29:05.934Z:

thread/list {
  ancestorThreadId: <root thread>,
  archived: false,
  useStateDbOnly: true,
  limit: 100,
  sortKey: "recency_at"
}

descendants returned: 85
status.type=notLoaded: 85
status.type=active: 0
intersection with thread/loaded/list: 0
active in-progress turns: 0

There were also no task-specific OS worker processes. Therefore the Desktop panel's Active/Working count and elapsed timers disagreed with the authoritative runtime state.

The restart behavior appears to rehydrate additional persisted descendants into the Active UI before terminal/notLoaded reconciliation. Suggested invariant: render Active only for authoritative status.type=active threads with an in-progress turn, and reconcile persisted spawn/history records both at startup and when opening the panel.

A screenshot is available if maintainers need it; it contains local task names, so I have not attached it publicly.

Follow-up verification and impact

• Two full Codex restarts reproduced the same sequence: the panel briefly showed zero, then historical rows reappeared as Working.
• All 85 descendants were archived through the supported thread archive API; the local state DB readback showed archived=85, unarchived=0. Nevertheless, after delayed rehydration the panel still showed Active: 65 (and at other points Active: 70, Done: 14).
• Ten archived historical threads were temporarily unarchived, individually read back to their existing terminal states, and archived again. This did not durably move the stale rows out of Active.
• The elapsed timers continue to advance for these non-running historical rows. This is a real local resource/UI impact: renderer timers, persisted-history rehydration, and repeated app-server state queries consume CPU/memory/I/O. The exact token or model-usage cost is not established by this evidence.
• The remaining Active count is therefore not evidence of 65 running agents; the authoritative runtime check still found no active in-progress child turns.

I can reproduce this on Codex Desktop 26.814.5517.0 on Windows x64. I checked the local state read-only instead of treating the panel count as a worker count.

• The UI showed Processing / Active 19.
• state_5.sqlite.thread_spawn_edges had exactly 19 global open rows at that point.
• Two new children were spawned, taking the count to 21. Both returned final answers and their rollouts ended in task_complete, but the database stayed at 21 open edges and the UI count did not fall.
• During an all-completed snapshot, all 21 open edges had a latest matching task_complete and none had a newer task_started.
• The parent later reused three of those existing child threads. The open-edge total remained 21. At the final capture, 2 children were genuinely in progress and 19 were terminal-but-open. Under the affected parent, 2 of its 9 open direct children were running and 7 were terminal.
• read_thread had already returned completed/idle children while their edges remained open for minutes to days.

The 19 -> 21 -> 21 sequence is the clearest part of this reproduction. The Desktop badge matched the persisted open-edge count, not live execution. Reusing an old child changes its current turn state without changing that edge count, so open cannot safely mean Working.

I also watched node_repl.exe grow from 28 to 44 direct children of one Codex process during the read-only investigation. Two short quiescence samples had zero CPU delta and checked samples had no TCP connections. I would treat that as a separate runtime-retention question, not evidence that 19 or 21 model agents were still running.

I did not edit SQLite, terminate processes, or restart the app. A restart was not a safe test while the parent still had an active turn, and the stale state was already persisted in SQLite.

I have a sanitized timeline, SQL queries, and aggregate process samples if a maintainer wants them. No raw rollouts, private thread IDs, prompts, project paths, or database files need to be shared.

I’m seeing the same issue on Codex Desktop for Windows, and my conversation has accumulated the stale state at a fairly large scale.

Environment

• Codex app version: 26.814.41957
• Platform: Windows
• Conversation: Long-running conversation with extensive subagent delegation

Observed behavior

The Subagents UI currently reports:

• 1,239 Working
• 194 Done

When opening the expanded Subagents view, it reports:

• Active · 1240

Many of these agents have clearly stale elapsed times. For example, one entry is still shown as Working after approximately 2 days 22 hours.

Fully closing and restarting the Codex app does not clear or reconcile the state. Reopening the conversation restores the same large set of supposedly active subagents.

Runtime verification

I asked the root agent to inspect the authoritative collaboration runtime registry rather than relying on the Subagents UI.

The registry reported no active subagents.

The only subagent runtime records it found were:

| Runtime | Status |
| --- | --- |
| /root/query_health_derived | Completed with final publication evidence |
| /root/query_health_docs | Completed with final cleanup-gate evidence |
| /root/compensation_integration_audit/final_query_health_docs_audit | Interrupted / failed or cancelled |

The resulting runtime summary was:

Actually running: 0
Waiting: 0
Terminal/stale: 3

Additional Windows evidence from the same cluster: terminal child rollouts and an empty live-agent registry coexisted with a large persisted Active/Working roster after restart. The panel followed persisted activity/open edges rather than current execution, linking this presentation defect to #37042, #38805, and the resident-slot failure in #39694.

The stale Active roster likely also explains the quota-drain reports above: phantom workers keep polling. While the lifecycle bug is open, vetto rescue --json scan --limit 200 gives an honest count of real rollouts versus what the panel claims - handy if you are collecting evidence numbers for the maintainers.