Codex app subagent cards can remain stuck/visible after close while close/readback reports no live agent

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

• #23700
• #23219
• #22744
• #23292

Powered by Codex Action

Thanks. I reviewed the duplicate candidates from the bot.

This looks closest to #23700 and #23219, but I am leaving this issue open because it narrows the symptom to Codex Desktop/app UI lifecycle state: the live close/readback path no longer exposes a running subagent handle, while the app can still show stale/resumable subagent cards or stale open rows. #22744 and #23292 also look related on subagent status/rendering or parent-thread waiting behavior.

If maintainers prefer this tracked under #23700 instead, I can close this as a duplicate.

Additional datapoint from another current Desktop session:

• Codex App: 26.519.41501 (3044)
• Platform: Darwin 25.4.0 arm64 arm
• Date observed: 2026-05-23
• Symptom: the app right rail still showed named subagents plus “Show 67 more” after cleanup/close attempts, while the live close route no longer recognized several exact agent IDs as live handles.
• Local readback/checkpoint state in the same workflow showed 0 live nonterminal agents after closeout; the stale rows were historical/terminal, not active work.

This makes the issue look less like a live subagent leak and more like a Desktop UI/cache/state propagation problem: closed or already-gone subagents remain rendered as if attached/active in the thread side panel. I am not attaching the screenshot because it includes workspace/thread details, but the visible UI symptom was the Subagents section still listing entries such as Rawls/Linnaeus/Kuhn/Ptolemy and “Show 67 more” after the lifecycle state was terminal.

Additional public cross-link/update after checking the related stale UI / active-turn chain:

• #24287 now has multiple public datapoints where Codex Desktop can show stale or frozen active-turn state while backend work appears to continue, including goal/multi-window and long-running-session observations.
• This looks related to the same broader state/observability family as this issue: visible Desktop state can diverge from backend lifecycle state.
• Related public chain already being tracked from this issue: #23700, #23219, #22744, #23292, #23937, #24281, #23296, #24287, and #24342.

I am keeping this issue open because the specific symptom here remains stale subagent UI/lifecycle rendering after close/readback shows no live agent. #24287 strengthens the adjacent Desktop state-desync signal, but it does not replace this exact subagent-card lifecycle report unless maintainers prefer a different canonical issue.

Additional datapoint from today:

• A subagent named Kuhn with role explorer was closed from the parent thread.
• A later close attempt returned a pending_init previous-status style result.
• The Codex Desktop Subagents panel still showed Kuhn (explorer) afterward.

This matches the stale subagent lifecycle/UI symptom tracked here: the user-facing panel can keep showing a subagent after the parent-side lifecycle action has already been taken.

Additional datapoint from another current Codex Desktop session:

The Subagents panel showed multiple final-pass subagents still listed, including Pauli (final_synthesis_gate), Fermat (final_word_packet_auditor), final_counteruse_confidentiality_auditor, final_authority_source_force_auditor, final_service_procedure_auditor, and Banach (final_fact_pin_auditor).

This is the same stale subagent lifecycle/UI symptom: completed or closed helper agents remain visible in the Desktop Subagents panel, making it unclear which agents are still active versus stale UI entries.

Additional datapoint from another current Codex Desktop session:

The Subagents panel showed a long list of final-pass subagents still visible, including Mill (final_synthesis_gate), Sartre (final_word_packet_auditor), Kuhn (final_fact_pin_auditor), Bernoulli (final_synthesis_gate), Euler (final_word_packet_auditor), Faraday (final_fact_pin_auditor), and truncated unnamed role entries for final_counteruse_confidentiality_auditor, final_authority_source_force_auditor, and final_service_procedure_auditor.

The panel also showed Show less, which means the stale/visible subagent list had expanded beyond the first visible group. This is another example of completed or stale helper agents remaining visible in the Desktop Subagents panel, making active versus stale state unclear.

Additional root-cause clue from local state inspection:

• The persisted thread_spawn_edges table had stale rows marked open for old subagent children even after the live close route no longer had a handle for those children.
• For one affected parent session, close_agent changed one child edge from open to closed, while several sibling children still returned not found from the live close route and remained marked open in persisted state.
• After changing the stale persisted rows to closed locally, the affected parent sessions showed zero open subagent edges in local state.

This supports the theory that the Desktop panel can render from persisted spawn-edge state that may not be reconciled when a child is already gone from the live close route.

Additional confirmed datapoint after local repair and multiple app restarts:

The local Codex state database now shows all subagent spawn edges as closed:

• SQLite integrity check: ok
• thread_spawn_edges status count: closed=549, open=0
• affected parent threads checked locally, with full identifiers intentionally omitted from this public comment
• checker result: 0 open state spawn edges in the affected scope

Despite that, after restarting Codex Desktop multiple times, the Subagents panel still visually shows stale subagent cards.

This makes the remaining symptom look like Desktop UI/cache/rendering state surviving restart even when persisted lifecycle state reports no open edges, rather than an active subagent/lifecycle leak.

I added a small evidence packer for this subagent lifecycle/state-reconciliation class in trace-to-skill@0.1.66:

npx trace-to-skill@0.1.66 demo subagent-lifecycle
npx trace-to-skill@0.1.66 codex-report ./runs --output openai-codex-subagents.md

Not a fix, just a report-shaping helper. It tries to make future reports include Codex version, OS/surface, model/workspace, root thread id, subagent ids/nicknames/roles, spawn/close/list actions, close_agent results, list_agents or /agents output, thread_spawn_edges status counts, registry/max_threads/quota evidence, recent-list/sidebar behavior, child archive/top-level state, last-progress/halt reason, MCP state, compaction/resume timing, restart/reload behavior, and whether stale agents are UI-only or still block spawns.

Release: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.66

Adding a root cause from the source, since this reproduces deterministically across an app restart and the mechanism looks like a listing-filter gap rather than a problem with close_agent itself.

Repro

1. Spawn a subagent and let it finish.
2. close_agent it. It disappears from the Subagents panel.
3. Quit and reopen the app. The closed subagent is back in the panel.

In state_N.sqlite after step 2 the child row is thread_spawn_edges.status = 'closed' but threads.archived = 0. Setting threads.archived = 1 for that exact child id by hand makes it stay gone across a restart, which points at where the listing reads.

Root cause, as I read it

• close_agent (codex-rs/core/src/agent/control.rs) only calls set_thread_spawn_edge_status(child, Closed). It does not touch threads.archived.
• The recent-thread listing that repopulates the panel runs through push_thread_filters (codex-rs/state/src/runtime/threads.rs), whose WHERE clause filters on threads.archived but not on thread_spawn_edges.status (nor thread_source). So a closed subagent (edge closed, archived = 0) still satisfies the listing and comes back on the rebuild.
• The live agent-tree resume already filters spawn children on Open (resume_agent_from_rollout). So it is specifically the thread-listing path that does not know the subagent is closed.

On the fix direction
archived looks like the user-facing archive action (mark_archived / mark_unarchived, ThreadArchivedNotification, and the archive RPC cascades to subagent descendants), distinct from the subagent lifecycle that thread_spawn_edges.status tracks. So having close_agent set archived = 1 would make a lifecycle event perform a user archive and pull the thread out of history and search. Filtering the subagent listing on the spawn-edge status instead keeps the two separate, which also lines up with the direction in #25112. #25341 captures the same data-side mismatch.

Happy to help however is useful.

Environment: Codex Desktop on macOS, version 26.601.21317 (released Jun 3, 2026).

Seen same issue. Feedback: 019f04ff-b2ce-7302-be1a-b511e0ee7cc1

Additional CLI/TUI evidence for the stale subagent lifecycle state:

• Environment: Windows 11, Codex CLI/TUI v0.146.1, PowerShell, Multi-agent V2.
• /agents reports No sub-agents running, but the picker still lists two gray,

anonymous Agent entries for closed /side threads.

• Selecting either entry says `Agent thread ... is closed. Replaying saved

transcript. The composer still accepts a follow-up and displays Queued
follow-up inputs`, but the input remains pending because there is no live agent
loop to consume it.

• The runtime inventory contains neither UUID, and followup_task returns

agent with id ... not found for both. Local history/log/state inspection
confirms these are ephemeral replay artifacts, not persisted child agents
available for native resume.

This narrows the CLI/TUI failure to a replay/liveness boundary: a historical
closed entry is still presented as a dispatchable agent. Could closed replay
entries be placed in a clearly separate read-only history surface, or have the
composer disabled when the selected thread is closed, so queued input can never
appear dispatchable without a live agent loop?

Additional Windows evidence with a deterministic 1:1 mapping between the Desktop panel population and historical subagent rollouts.

Environment

• Windows 11 Enterprise, build 22631, 64-bit
• Codex Desktop 26.803.5235.0
• Codex CLI 0.147.0
• Multi-agent v2
• Three unrelated parent threads, all currently idle
• Read-only evidence collection only; no SQLite/state modification

Results

| Case | Desktop Subagents panel | Historical descendant rollouts | Terminal rollout endings | Live registry after observation | Goal |
|---|---:|---:|---:|---:|---:|
| A | 49 working + 49 done | 98 direct | 91 task_complete + 7 turn_aborted | 0 live subagents; list_agents returned only /root | null |
| B | 51 working | 51 direct | 46 task_complete + 5 turn_aborted | 0 live subagents; list_agents returned only /root | null |
| C | 95 working + 18 done | 113 total (111 direct + 2 nested) | 105 task_complete + 8 turn_aborted | 0 live subagents; list_agents returned only /root | null |

In every case, the panel's total card count exactly equals the complete historical descendant rollout population, while every rollout has a terminal ending and the live registry reports no live child.

The working/done split does not correspond to the terminal markers:

• Case A: all 98 rollouts are terminal, but 49 are shown as working.
• Case B: all 51 rollouts are terminal, but all 51 are shown as working.
• Case C: all 113 rollouts are terminal, but 95 are shown as working.

The last subagent spawns were on Aug 2, Aug 3, and Aug 4 respectively. The current Desktop process was started on Aug 8, so these cards survived a full app restart. Case A's parent had not performed new work after that restart before the stale cards were observed. Opening the affected parents produced ordinary thread read/resume activity and no new subagent spawn.

This strongly suggests that the panel rebuild is enumerating the historical child population correctly but is not reconciling terminal rollout state and/or durable child lifecycle state before assigning working/done labels. Goals are not required for the bug: all three cases have goal: null.

This independently supports the listing/rebuild explanation in the existing root-cause comment and the data-side mismatch in #25341. #26662 is merged and provides parent-filtered thread listing, but the current Desktop build still renders the complete historical population with incorrect lifecycle labels.

A separate fourth-thread observation may belong to #19197 rather than this UI-only bug: two exact agent IDs that had previously been successfully closed from running later returned as pending_init, with no intervening spawn or resume in the parent rollout. That anomaly is not needed to explain the three cases above.

Full thread IDs and screenshots can be provided privately if maintainers need them.

Codex Windows desktop "Codex & OWL Version 26.803.41515" the problem with subagents are still there. It's not possible to understand when an agent finish his task because the UI reports subagents active and in execution.

Reproduced on Windows with a current Codex desktop build.

Environment:

• Codex App: 26.803.10989.0 (Microsoft Store/MSIX)
• Windows 11 Pro Insider Preview, x64, build 26220.9022
• UI locale: cs-CZ

Observed:

1. A parent task spawned three subagents.
2. All three completed normally. The backend status for each was completed.
3. A cleanup/interrupt was then requested for every child; each returned previous_status: completed.
4. A fresh agent-state readback subsequently contained only the parent task and no child agents.
5. The Desktop UI still showed “3 working” (“3 pracují”).
6. Navigating away and back, reopening the task, and fully quitting/restarting Codex did not clear the indicator.

Expected:
The active/working count should be derived from live running states. Completed agents should stop contributing to the “working” count, and a full app restart should reconcile the UI with backend state.

This looks like the Windows manifestation of the UI/backend lifecycle drift described in this issue. No child agents are actually running according to the backend, but the visible status remains active.

@codex no plans to fix this?

@codex same here , please fix. Please add display of model selection and settings for sub-agents in the UI panel as well

@codex I did a read-only inspection of a current affected installation, and the key ambiguity appears to be that “working” is being used for persisted or retained subagents, not only for subagents that are currently executing.

Current data

Environment: Codex Desktop 26.803.61601, bundled CLI 0.147.0-alpha.6.5, observed on 2026-08-13. No local state was modified.

At the same moment:

• The Desktop panel showed 40 working and 4 done
• The live agent inventory showed 0 active subagents
• The OS showed 0 zombie processes
• thread_spawn_edges contained 920 open edges
• 799 open edges had not been updated for more than 24 hours
• The recently opened child agents I checked were already completed/idle
• I found no evidence of a long-held SQLite write lock

This suggests that the panel count is based on retained historical relationships. It does not represent active execution or zombie processes.

The product ambiguity

Multi-agent V2 intentionally keeps agents available for follow-up work. That is useful, but “available for reuse” and “currently running” are different states.

When both states are shown as working, users cannot tell:

• whether work is still executing,
• whether a concurrency slot is occupied,
• or whether the entry is only retained history.

A small, compatible fix

A first fix does not need to redesign the lifecycle or migrate existing rows:

1. Count an agent as working only when it has a live, non-terminal turn.
2. Show an open edge with no active turn as idle/available or historical.
3. Exclude inactive retained agents from the active concurrency count.
4. Keep the existing open/closed persistence so follow-up and history behavior remain compatible.
5. Add a regression test for an open/retained child whose latest turn is terminal.
6. If user-facing copy changes, update all supported locales in the same change.

This would let the panel answer the practical question: “What is running right now?” It also avoids a risky cleanup or migration of old state.

Because external PRs require an explicit maintainer invitation, I have not prepared a PR. If this direction matches the intended semantics, I would be happy to submit a focused, test-covered change. Could a maintainer confirm the intended source of truth for the working count and invite the contribution?

Everyone please also send /feedback in the app, open cass with support chat bubble to document all this everywher because its unacceptable lot of bugs without fix for months.

<img width="1524" height="478" alt="Codex Desktop subagent panel showing stale Processing states for about 19 days" src="https://github.com/user-attachments/assets/42ce3fdf-faa7-46b5-ba77-271dd6a424c9" />

Confirming the stale subagent state on the current Windows build.

Environment

• Codex Desktop: 26.810.6296.0
• Windows 11 Pro x64, build 26200
• Bundled CLI recorded by current threads: 0.148.0-alpha.9

Visible symptom

The screenshot shows:

• 28 entries in the subagent panel
• the four visible entries are still labeled Processing
• elapsed times are approximately 19 days
• Show 24 more is visible

These agents had already finished, but the UI continued to present them as actively processing.

Read-only local-state check

No database or session files were modified.

Across the local profile:

• thread_spawn_edges: 40 rows
• all 40 rows have status = 'open'
• all 40 child threads have archived = 0
• all 40 rows have been unchanged for more than seven days
• corresponding rollout terminal markers: 37 task_complete, 3 turn_aborted
• zero corresponding rollouts lacked a terminal marker

The screenshot is from one affected task, while the 40-row check is the aggregate across the local profile, so those two counts are not expected to match exactly.

This confirms that, on this installation, Processing does not represent current execution. The durable child/spawn state remains open after the rollout has reached a terminal state, and the Desktop UI appears to render or count that stale state as active work.

Expected behavior

• A terminal rollout should reconcile its child-thread and spawn-edge lifecycle state.
• Processing/Working should count only live running or pending agents.
• Completed, aborted, retained, or reusable historical agents should be shown separately from actively executing agents.

In-app feedback

Submitted through the Desktop app's feedback flow.

• Feedback session ID: 019f9dc8-4f95-7143-b711-e1bcd8beb593

The mismatch between live close/readback state and stale subagent UI state is useful as a lifecycle control case for codex-rescue. I’m field-testing whether it can inspect the persisted parent/child sessions and avoid inventing an unfinished action merely because the Desktop UI still shows a stale agent card.

If you still have one affected local workflow, could you run:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

A healthy/no-damage result is useful too. Rescue does not fix the Desktop subagent card UI; it checks durable local evidence and keeps source rollouts read-only.

Please share only sanitized output, versions and exit codes—no raw rollouts/SQLite, prompts, agent IDs, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue

A sub-agent finishes and returns its result, but the Subagents panel continues showing it as “Working.” The panel should immediately change to “Completed” or “Stopped” so I can tell whether anything is genuinely still running. This appears related to openai/codex issue #23930.

Adding another current Windows datapoint (2026-08-17):

• Codex Desktop: 26.810.7004.0
• Platform: Windows 11 x64, build 26200
• The sidebar showed 30 working / 4 done while the live agent backend exposed the parent plus exactly two running helpers.
• After both helpers were interrupted, live readback showed only the parent running and both helpers interrupted. The sidebar only dropped to 28 working / 4 done.
• This isolates 28 phantom "working" entries: the counter reacted correctly to the two genuinely active helpers but continued counting retained/historical agents as working.

Expected: Working should be derived only from live non-terminal agent turns; retained, completed, or interrupted agents should be shown as inactive/history.

A screenshot was captured showing 28 working / 4 done; it contains no workspace content. This matches the visual evidence already attached in the previous Windows 26.810 datapoint.

No fix soon for this old bug/behavior since day 1 of codex? @etraut-openai @chess-oai @jif-oai @tibo-openai @dylan-hurd-oai

Additional Linux datapoint observed on 2026-08-19.

Environment

• Platform: Linux 7.0.0-29-generic, x86_64
• Local Codex CLI: 0.146.1
• Codex Desktop app with Multi-agent/Subagents panel
• Read-only state inspection only; no SQLite or rollout files were modified

Observed behavior

1. The parent task's live agent runtime had no active subagents.
2. Attempts to close the old exact child handles returned agent ... not found, consistent with there being no live agent process to close.
3. For the six cards visible at the top of the Subagents panel, the corresponding persisted thread_spawn_edges.status values were all closed.
4. Despite that, the panel displayed five of those cards as is working, and also displayed Show 50 more. One closed card appeared without a working label.

This is a useful control case because the visible cards are not merely old open edges: the exact visible children are already persisted as closed, yet the UI still labels them as working. It appears that the panel's working label is being rehydrated from stale child/thread presentation state rather than derived from a live non-terminal turn or the durable spawn-edge lifecycle state.

Expected behavior

• is working should be shown only for a live pending/running turn.
• Closed/completed historical children may remain available as history, but should be labeled completed/closed/idle rather than working.
• Opening or reloading a parent task should reconcile visible child state with the live runtime and durable lifecycle state.

A cropped screenshot showing only the Subagents panel is available if maintainers need it. Thread IDs, local paths, and workspace details are intentionally omitted.

After checking the current Subagents lifecycle docs and current openai/codex behavior, I want to tighten the hypothesis here: completion is not the same as explicit close. Retained/completed agents may legitimately remain available for follow-up, so the bug is not simply that every terminal rollout must close its spawn edge.

The newer control cases isolate the actual problem more cleanly:

• Windows 26.810: the panel moved from 30 working to 28 working when the only two genuinely live helpers were interrupted, proving the counter can react to live state while retaining a stale historical baseline.
• Linux 2026-08-19: the live runtime had 0 active subagents, the exact visible child edges were already persisted as closed, yet 5/6 visible cards still said is working.
• My earlier macOS control case likewise reproduced after thread_spawn_edges was closed=549, open=0 and after multiple full app restarts.

Together this points to a presentation/liveness-classification defect rather than a live-agent leak: historical/retained/closed children can be projected as Working/Processing even when no live non-terminal turn exists.

A lifecycle invariant consistent with the documented model would be:

• live non-terminal turn → Working / Processing
• terminal but retained/reusable child → Done / Idle / Available
• explicitly closed/history-only child → not active and not dispatchable unless an explicit resume successfully restores a live agent

That framing preserves intended retention/follow-up semantics without making completion equivalent to close or archive.

Additional macOS reproduction: 17 completed children rehydrated as active after restart

Environment:

• ChatGPT/Codex Desktop 26.818.31338, build 6892
• macOS Darwin 25.5.0, arm64
• Long-running parent task using multiple bounded subagents

Observed sequence:

1. All 17 subagents had previously completed their assigned work.
2. Codex Desktop was fully restarted.
3. Immediately after restart, all 17 historical subagents were displayed as active/working again.
4. Opening each child card manually caused that individual status to refresh to its terminal state.
5. Children that had not yet been opened remained visually active.

Runtime cross-check performed while the Desktop UI showed the stale population:

• only the parent agent was actually running;
• one historical child was present as pending_init;
• the other 16 displayed children were absent from the live agent inventory.

No private thread or agent identifiers are included here.

This appears to isolate a restart/hydration defect rather than a live-agent leak: the parent view rehydrates historical descendants as active, then reconciles terminal state lazily only when each child is opened. It is consistent with the historical-state behavior reported in #37222.

Expected behavior:

• parent-task hydration should reconcile every descendant against the live runtime and latest terminal child state before rendering active counts;
• only children with a live non-terminal turn should be displayed as Working/Processing;
• opening child cards manually should not be required after every application restart;
• completed or closed descendants should remain terminal across restart, with an optional history/grouping or bulk-dismiss surface.

This matches a Windows variant: thread/read and the live registry reported terminal or missing child handles, while reopening the parent restored the cards as Active until each child was opened. That lazy per-child reconciliation is the presentation half of #37042 and #37916, not proof of live work.