Codex desktop shows completed subagents as active and processing indefinitely

Open 💬 5 comments Opened Aug 20, 2026 by josuehsilva

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.818.2872.0 (Windows package OpenAI.Codex_26.818.2872.0_x64)

What subscription do you have?

ChatGPT account; exact subscription tier is not displayed in the Codex App

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

In the Codex desktop app for Windows, completed subagents remain listed under Active with the status Processing indefinitely.

The panel currently shows Active · 18, even though those subagents already completed their work and returned final results. Some entries have been displayed as processing for several days.

Restarting and reopening the Codex app does not clear or correct the stale entries. The UI therefore suggests that background work is still running when it is not.

Two screenshots are attached showing the stale active count and the completed subagents still marked as processing.

What steps can reproduce the bug?

Open a long-running task in Codex desktop.
Start multiple subagents during the task.
Allow the subagents to complete and return their results.
Open the subagent activity panel.
Observe that completed subagents remain under Active with status Processing.
Close and restart the Codex desktop app.
Open the same task again; the stale active entries are still present.

Additional runtime evidence:

The active-agent runtime listing returns only the root agent.
Attempting to interrupt one of the displayed subagents by its canonical name returns not_found.
The task list shows only the current parent task, not the 18 displayed subagents.

This suggests the desktop UI is rendering persisted stale child-run records rather than live agent state.

What is the expected behavior?

Completed subagents should leave the active count and be shown as completed/closed, or be removed from the active list.

The Active counter should match the actual live agent runtime state. Restarting the application should not preserve completed agents as actively processing.

Additional information

Impact: the UI is misleading and gives users no working way to stop or clear the apparent background agents. It also creates concern that resources are still being consumed when no agents are actually running.

No project code, credentials, or private project data are included in this report.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 7 days ago

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

#38408
#38364
#38478
#38908
#39668

Powered by Codex Action

pomazanbohdan · 5 days ago

This is consistent with the same cross-layer defect: completed child rollouts remain visually Active/Processing although no live child is executing. The latest cluster evidence points to stale historical/activity projection (#37042 and #37916) plus resident/edge pressure (#39694), not a single UI counter bug.

NguyenAnh718 · 5 days ago

Independent reproduction on Windows confirms the same stale lifecycle projection.

Environment

Codex Desktop package: 26.818.2441.0
Windows x64
Executable Chromium product version: 151.0.7922.170
Observed: 2026-08-23

Observed contradiction

Environment → Subagents displayed: 13 working, 1 done
Authoritative current agent inventory contained only the root task plus one completed reviewer
Active non-root subagents: 0

The completed count was correct, while the working count remained stale. This followed a long-running task with repeated bounded subagent reuse and context compactions.

Expected invariant: working must be derived only from current non-terminal child-agent states and reconciled on completion, interruption/failure, compaction, task resume, and app rehydration. Historical spawn records should not be counted as live work.

A cropped screenshot reproducing the 13 working / 1 done state is available if maintainers need it; no project data is required to reproduce the discrepancy.

LarryBetz · 3 days ago

I am seeing a closely related Windows Desktop case where the stale state is shown in the originating voice-chat task itself, not only in the subagent panel.

Observed twice:

A voice-chat task delegated work to a child/background task.
The child completed its work.
The original voice-chat UI continued to show an old command as running and a growing “Working for …” duration.
A direct task-status check reported the original task as idle, so no work was actually still running.

Expected: once the originating task is idle and the delegated work is complete, the original task should stop displaying the stale command and active duration.

I have a screenshot, but am intentionally not attaching it because it includes private project and task names. The behavior occurred on Windows Desktop; exact app version was not captured.

LarryBetz · 2 days ago

Additional Windows Desktop evidence from a parent chat (not limited to the subagent panel):

After posting a chat, the main conversation area can become almost entirely stale trace placeholders: repeated “Ran a command” / “Listed chats” events and elapsed entries such as “Working for 50m…”, “47m…”, “45m…”, and so on. The input remains available, but the user is not shown the current action, current decision, current result, or a clear completion state. The Background processes panel also contains many stale, truncated process lines.

A direct task inspection showed an active in-progress turn with no active flags; the UI did not translate that into useful user-facing status. This has happened repeatedly in the same BookTracker voice-derived task.

Expected behavior: surface one concise current-status/progress explanation, make finished historical work clearly finished/collapsed, and avoid presenting stale elapsed timers as if they are the current state.

Screenshot withheld because it contains private project/task names and local paths.