Codex App: completed subagents remain in Active / Working after task_complete

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

• #34220
• #35052

Powered by Codex Action

I’m seeing the same issue frequently in Codex Desktop for macOS.

Even after subagents finish and return their results, many remain shown as Running / Working. Across repeated multi-agent tasks, these stale entries accumulate in the Active list, so the UI substantially overstates how many subagents are actually running.

Environment:

• Codex app version: 26.803.41515 (build 6321)
• macOS version: 27.0 (build 26A5388g, arm64)

This makes it difficult to tell whether work is still executing or whether concurrency is actually occupied. I can add a sanitized screenshot or Feedback session ID later if useful.

Confirmed on another macOS Codex Desktop installation. This appears to be the same stale Active/Working state.

Environment:

• Codex app: 26.730.61639 (build 6234)
• macOS: 13.5
• Architecture: arm64

Observed behavior:

• Multiple child agents had already returned their final results and completed normally.
• After restarting Codex and reopening the task, at least eight completed agents still showed Working, with displayed durations between roughly 8 and 10 hours.
• An authoritative runtime status check at the same time returned only the primary/root agent as running and no live child agents.
• The stale cards persisted instead of moving to completed/history state.

This makes it look as if old agents may still consume concurrency or modify the shared worktree, even though the runtime reports that they no longer exist.

Sanitized screenshot:

<img width="346" height="500" alt="Image" src="https://github.com/user-attachments/assets/a92730b0-909b-43aa-93b4-807e717185a5" />

Reproduced at substantially larger scale on a current macOS build.

Environment

• Codex Desktop: 26.814.41407
• macOS: 26.6.1
• Architecture: arm64
• Observed: 2026-08-19

Observed behavior

• The Subagents panel reports Active · 123.
• It lists historical subagents that completed or were interrupted as Working.
• Many displayed elapsed times are between approximately 8 days 4 hours and 8 days 13 hours, and the timers continue increasing.
• A much more recently completed child (roughly two hours old) is also still displayed as Working, so this is not limited to one old persistence format.
• Closing and reopening the panel did not reconcile the entries. Restarting/reopening Codex also did not clear the stale state.
• The underlying turns had already ended and returned their results to the parent task.

Runtime cross-check

A live collaboration-registry lookup was performed for representative entries shown as Working. Those exact agent paths returned:

{"agents":[]}

Earlier lifecycle inspection had recorded the same representative agents as terminal (completed or interrupted), not actively executing. The primary task was the only work still in progress.

This makes the panel disagree with the runtime registry in three visible ways:

1. Active count: 123 historical records are counted as active.
2. Status: terminal children are labelled Working.
3. Duration: their elapsed-time counters continue advancing long after execution ended.

Expected behavior

• Only currently executing or genuinely waiting live agents should contribute to the Active count.
• Completed, interrupted, failed, or otherwise terminal agents should move to Done/history or display their exact terminal state.
• Elapsed execution time should stop at the terminal lifecycle timestamp.
• On panel hydration, task restoration, and application startup, the UI should reconcile persisted subagent activity against authoritative runtime/terminal turn state.
• If the current state cannot be resolved, the entry should be labelled unknown/stale and excluded from Active rather than guessed to be Working.

Impact

At this scale the panel is not operationally trustworthy. It creates the false impression that 123 agents may still be consuming usage, occupying concurrency, or retaining the ability to modify a shared workspace. Users cannot distinguish actual execution from historical records without performing a separate runtime-registry inspection.

This appears consistent with the stale status/hydration paths discussed in #37042 and #37916. The continuously increasing timers suggest the renderer may be starting a client-side elapsed-time calculation from historical start data after incorrectly hydrating the record as active, rather than receiving ongoing execution activity.

No continuing model activity was detected for the representative entries checked. No repository names, task contents, local paths, thread identifiers, or private project information are included in this report.

Additional reproduction on the current native Windows build. I am commenting on the existing issue rather than opening a duplicate, as requested by the Codex App issue template.

Environment

• Codex Windows package: 26.818.5229.0
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Observed: 2026-08-24

Runtime/UI mismatch

At one point, the Subagents panel displayed:

Active: 26

An authoritative live-agent lookup performed at the same time contained only three live child agents: one coordinator and two current reviewers.

Representative historical entries displayed as Working had already returned their final results. Explicit interrupt attempts against those displayed canonical agent paths returned:

{"previous_status":"not_found"}

The cards nevertheless remained under Active and their elapsed timers continued increasing.

Reproduction pattern

1. Use a long-running parent task with multiple bounded implementation and review waves.
2. Allow children to return final results.
3. Reactivate some children for follow-up corrections or reviews.
4. Open the Subagents panel.
5. Observe historical completed turns still displayed as Active/Working.
6. Compare the panel with the live-agent registry or attempt to interrupt a representative stale entry.
7. Observe that the runtime no longer contains that agent.

Scope of this evidence

This report demonstrates a UI/runtime state mismatch. It does not demonstrate that the stale entries continue consuming model tokens, CPU, or concurrency capacity.

Read-only persisted-state cross-check

After the initial report, I performed a read-only audit of the local lifecycle metadata and corresponding rollout endings:

• All 27 child edges persisted for the affected coordinator are still stored as status = open.
• The corresponding 27/27 child rollout files end with event_msg/task_complete.
• At the root-task level, all 5 direct child edges are also still stored as open.
• The corresponding 5/5 rollouts end with event_msg/task_complete, including the coordinator itself.
• The persisted spawn-edge table contains only parent ID, child ID, and status; it has no terminal timestamp to reconcile elapsed-time rendering.

This confirms a stale persisted spawn-edge state: terminal rollout evidence and the stored edge status disagree.

I did not find a persisted watched_status field in the relevant state schemas or global application state. Therefore, I am not claiming that watched_status was the exact runtime input used to render this occurrence. The runtime precedence mechanism discussed in #37916 remains a plausible adjacent mechanism, while the stale open edges are directly verified here.

The additional value relative to existing reports is:

• reproduction on native Windows package 26.818.5229.0;
• a quantified 26 displayed vs 3 live mismatch;
• direct not_found lifecycle-control evidence.

No repository names, prompts, local paths, thread identifiers, credentials, rollout files, or customer data are included. A cropped screenshot containing only the Subagents panel can be provided if maintainers request it.