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

Summary

In the Codex app, completed or closed subagents can appear to remain visible/stuck in the UI for a long time even after the supported close/readback path reports that there is no live agent handle left.

Component

Codex app / Desktop on macOS.

I do not know the exact app version from the UI at the time of filing.

What happened

A workflow used several subagents for bounded helper work. After the helpers completed, attempts to close them by exact returned agent IDs produced a mix of:

a completed previous status,
a running or pending previous status followed by successful disappearance from readback,
or not_found for handles that were already gone from the live route.

Even after those close/readback results, the app UI could still make it look like subagents were present or stuck. In one child/subagent view, the UI showed a banner asking the parent to resume the sub-agent to continue the conversation, which suggests the child was closed, but the surrounding UI state still made it unclear whether a subagent was active, closed, or stale.

Expected behavior

After a subagent completes and is closed, the Codex app should make the lifecycle state unambiguous:

closed/completed subagent cards should update or disappear from active/open UI surfaces,
stale IDs should be shown as already closed rather than appearing stuck,
the parent thread should have a clear way to see that no live subagent remains,
and not_found after close/readback should not leave the user thinking an agent is still running or consuming an active slot.

Actual behavior

The live close/readback route can indicate that no live handle remains, while the UI still appears to show stale/open subagent state or a closed-child resume banner. This makes it hard to tell whether work is still running, whether slots are still occupied, or whether the UI is stale.

Impact

This is confusing during long-running work and makes it difficult to trust whether background/subagent work has actually stopped. It can lead to repeated close attempts and uncertainty about whether resources or subagent slots are still in use.

Request

Please clarify or fix the Codex app subagent lifecycle UI so the app reliably reflects completed/closed/stale states after subagent close/readback, especially when close returns not_found for an already-gone handle or when a child thread shows the parent-resume banner.

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

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:

Codex Desktop accepts prompt but UI stays stuck in Thinking; Stop fails and turn can become invisible after restart #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: Stale Codex subagents #23700, Codex Desktop: shutdown/nonexistent subagents appear to count toward spawn_agent thread limit #23219, The subagent is not rendering the correct status before it is opened #22744, Codex Desktop main thread can stay stuck thinking when a sub-agent remains active #23292, /agent can show unrelated main sessions as generic "Agent" sub-agents #23937, The main agent is not aware of subagents spawned before context compaction, and reports no way to list them by itself #24281, MultiAgentV2 subagents can acknowledge, time out, or shut down without executing the spawn task #23296, Codex Desktop accepts prompt but UI stays stuck in Thinking; Stop fails and turn can become invisible after restart #24287, and use subagent but final return No agents completed yet #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.

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

Spawn a subagent and let it finish.
close_agent it. It disappears from the Subagents panel.
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 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:

A parent task spawned three subagents.
All three completed normally. The backend status for each was completed.
A cleanup/interrupt was then requested for every child; each returned previous_status: completed.
A fresh agent-state readback subsequently contained only the parent task and no child agents.
The Desktop UI still showed “3 working” (“3 pracují”).
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

@codex no plans to fix this?

@codex

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

@codex

@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:

Count an agent as working only when it has a live, non-terminal turn.
Show an open edge with no active turn as idle/available or historical.
Exclude inactive retained agents from the active concurrency count.
Keep the existing open/closed persistence so follow-up and history behavior remain compatible.
Add a regression test for an open/retained child whose latest turn is terminal.
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.

Codex Desktop subagent panel showing stale Processing states for about 19 days

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

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.

@etraut-openai

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

The parent task's live agent runtime had no active subagents.
Attempts to close the old exact child handles returned agent ... not found, consistent with there being no live agent process to close.
For the six cards visible at the top of the Subagents panel, the corresponding persisted thread_spawn_edges.status values were all closed.
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:

All 17 subagents had previously completed their assigned work.
Codex Desktop was fully restarted.
Immediately after restart, all 17 historical subagents were displayed as active/working again.
Opening each child card manually caused that individual status to refresh to its terminal state.
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.

Navigation Menu

Repository navigation

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

Summary

Component

What happened

Expected behavior

Actual behavior

Impact

Request

1 remaining item

Environment

Results

Current data

The product ambiguity

A small, compatible fix

Environment

Visible symptom

Read-only local-state check

Expected behavior

In-app feedback

Environment

Observed behavior

Expected behavior

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Component

What happened

Expected behavior

Actual behavior

Impact

Request

Activity

github-actions commented on May 21, 2026

omarpinarecords commented on May 21, 2026

adpena commented on May 23, 2026

omarpinarecords commented on May 24, 2026

omarpinarecords commented on May 27, 2026

omarpinarecords commented on May 27, 2026

omarpinarecords commented on May 27, 2026

omarpinarecords commented on May 27, 2026

omarpinarecords commented on May 27, 2026

grnbtqdbyx-create commented on May 31, 2026

yaanfpv commented on Jun 4, 2026

ehendrix23 commented on Jun 30, 2026

1 remaining item

dnhrdt commented on Aug 9, 2026

Environment

Results

c4ph00k commented on Aug 10, 2026

arimaa-master commented on Aug 11, 2026

omarpinarecords commented on Aug 12, 2026

kmusard commented on Aug 12, 2026

Perfecto23 commented on Aug 13, 2026

Current data

The product ambiguity

A small, compatible fix

omarpinarecords commented on Aug 13, 2026

znbsf commented on Aug 15, 2026

Environment

Visible symptom

Read-only local-state check

Expected behavior

In-app feedback

praneeth-red commented on Aug 17, 2026

mugpet commented on Aug 17, 2026

omarpinarecords commented on Aug 17, 2026

alan-shangguan commented on Aug 18, 2026

Environment

Observed behavior

Expected behavior

omarpinarecords commented on Aug 19, 2026

idealson-nexources commented on Aug 21, 2026

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

pomazanbohdan commented on Aug 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions