›_ Codex Issues
Codex Issues / #38478

Codex Desktop: completed subagents remain shown as running/processing in the summary panel

Open 💬 3 comments Opened Aug 14, 2026 by aaaaaaaaat
💡 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)?

Codex Desktop 26.803.61601

What subscription do you have?

ChatGPT Plus

What platform is your computer?

macOS, Apple Silicon (arm64)

What issue are you seeing?

The subagent status shown in the Codex Desktop summary/task panel can become stale.

When a task uses multiple subagents, some subagents finish normally and their results are already available, but the summary panel in the upper-right/right-side area may continue to show those same subagents under the active section with a status such as 处理中 / processing for many hours.

In the observed case, a subagent named Audit content had already completed and appeared in the 完成 / completed section, but the same Audit content entry was still present in the active section and continued to show 处理中 with an elapsed time of more than 12 hours.

This creates contradictory UI state:

  • the subagent result is already complete and accessible;
  • the completed list correctly contains the subagent;
  • the active summary still says the same subagent is running/processing;
  • the elapsed runtime keeps increasing even though the subagent has already finished.

This appears to be a Desktop UI/state synchronization or lifecycle reconciliation problem rather than the subagent actually still executing.

What steps can reproduce the bug?

The issue is intermittent, but the observed pattern is:

  1. Open Codex Desktop on macOS.
  2. Start a task that causes Codex to spawn multiple subagents.
  3. Allow one or more subagents to finish normally.
  4. Confirm that the completed subagent result can be opened and that the task appears under the completed section.
  5. Open or inspect the summary/task panel in the upper-right/right-side area.
  6. Observe that one or more already-finished subagents can still remain in the active section with status 处理中 / processing.
  7. Leave the app open for some time.
  8. Observe that the stale elapsed time continues increasing even though the subagent has already completed.

A particularly clear inconsistent state is when the same subagent name is simultaneously visible in both:

  • the active/processing list, and
  • the completed list.

What is the expected behavior?

Subagent lifecycle state in the summary panel should reconcile immediately when a subagent reaches a terminal state.

Expected invariants:

  • A completed subagent must be removed from the active/processing section.
  • The elapsed runtime for a completed subagent must stop increasing.
  • The same subagent should not simultaneously appear as both active and completed.
  • Reopening the task, switching tasks, or rehydrating the Desktop UI should preserve the terminal state instead of restoring a stale running state.
  • If the backend lifecycle state and UI cache disagree, the terminal backend state should be authoritative.

Additional information

This is related to subagent lifecycle problems such as #19197, but the observed failure mode here is different.

#19197 focuses on subagents that may actually remain orphaned/stuck and continue to count against subagent limits. In this report, the subagent output is already complete and visible, while the Desktop summary UI continues to display a stale processing state.

The behavior suggests a missing or failed reconciliation between the subagent terminal event and the summary/task-list state, possibly during task hydration, cached UI state updates, or lifecycle event propagation.

Screenshots from the affected session show:

  • Audit content listed as 处理中 for more than 12 hours in the active section;
  • the same Audit content also listed under 完成 / completed;
  • other subagents in the same task still shown as processing for long periods.

This makes the summary panel unreliable for determining whether subagent work is actually still running.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 14 days ago

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

  • #38364
  • #37916
  • #37729
  • #37222
  • #38408

Powered by Codex Action

caredhieacid · 14 days ago

Reproduced on the current macOS build on 2026-08-14.

Environment

  • ChatGPT/Codex Desktop: 26.810.41047 (build 6570)
  • Bundled runtime: codex-cli 0.148.0-alpha.9
  • Platform: macOS 15.6 (build 24G84), Apple Silicon / arm64
  • Model/mode: GPT-5.6 Sol with Ultra

I have repeatedly observed completed child agents remain presented as still running/in progress after they have returned their final result and the parent task has already received or used that result. From the user's perspective these are “ghost-active” agents: the work is terminal, but the Desktop status continues to communicate live execution.

Ultra makes this failure particularly damaging because it proactively delegates to multiple child agents. There are two related UX/control problems:

  1. Ultra can fan out aggressively even when the task does not appear to benefit from that amount of delegation.
  2. Once children exist, the Desktop UI is not a reliable source of truth for whether they are actually alive, completed, or still consuming resources.

The second point is the concrete lifecycle/status bug tracked here. It prevents users from knowing whether the parent is genuinely waiting, whether usage is still being consumed, or whether interrupting the task is safe.

Expected invariants:

  • A child that has emitted a terminal result must immediately leave the active list.
  • Terminal backend state must override cached/hydrated UI state.
  • A completed child must never keep an increasing “running” duration.
  • The parent should wait only on genuinely live children.
  • Ultra should expose clearer delegation controls or a bounded spawn policy so unnecessary fan-out does not amplify lifecycle failures.

中文补充：Ultra 会主动创建较多子 agent，但子 agent 明明已经返回最终结果，桌面端仍经常显示“进行中/处理中”。这让用户无法判断它究竟还在工作、仍在消耗额度，还是仅仅 UI 状态没有收敛。终态应当立即成为唯一可信状态，而不是继续显示“假活”。

I am happy to help test a fix, provide a minimized reproduction, or contribute a patch if the relevant Desktop lifecycle/UI component is open to external contributions.

nokiyliao · 8 days ago

I reproduced this on the bundled codex-cli 0.148.0 runtime and did a source-level investigation. There appears to be a more specific lifecycle-model cause behind the hydration/cache symptom described above:

The Desktop projection conflates an open subagent relationship with a currently running child execution.

thread_spawn_edges.status = open is intentionally retained after a child turn becomes terminal so the parent can preserve child history and send a later follow-up. Runtime residency can be reclaimed without closing that relationship. Therefore, open is not evidence that an execution is currently running.

In the affected state I observed:

  • hundreds of persisted open spawn relationships;
  • corresponding child rollout histories containing structured terminal lifecycle events and completion coordinates;
  • completed children still projected as active;
  • elapsed time derived from the original relationship/turn start and continuing against the current clock.

This also explains why restarting or rehydrating the UI can restore the false running state: the durable relationship is still open even though its latest execution interval is terminal.

Suggested model boundary

Please preserve the open spawn edge as relationship/follow-up state, but project execution state separately, for example:

  • unknown
  • running
  • completed
  • errored
  • interrupted
  • last_started_at
  • last_completed_at
  • duration_ms

Only current live execution evidence should promote a child to running. A persisted start event without live execution evidence should not be enough after rehydration.

For terminal executions, the UI timer should freeze at authoritative duration_ms, or at completed_at - started_at when no authoritative duration is available. A later follow-up should create a new execution interval and must not resume the original timer.

The frontend should also defensively treat terminal execution coordinates as authoritative even if stale relationship metadata remains open.

Regression cases

  1. Completed child + open edge => completed, frozen duration, excluded from active count.
  2. Errored/interrupted child => terminal state and frozen duration.
  3. Genuinely live child => processing with an increasing timer.
  4. Completed child followed by a new turn => new interval/timer only.
  5. Open relationship without live execution evidence => not counted as running.
  6. Mixed running/completed children => exact active count.
  7. Child history and follow-up remain available after terminal projection.
  8. Completion notification, execution-slot release, deduplication, and resident-runtime reclamation remain unchanged.

I validated this model locally with focused protocol, history-projection, mixed-count, follow-up-interval, completion-notification, slot-release, and terminal-reclaimer tests. I have not deployed or modified the Desktop application or its persisted state.