[Windows Desktop 26.730] Completed historical subagents stay “Processing” after upgrade; terminal state is not reconciled

What version of the Codex App are you using?

• Current Windows package: 26.730.8199.0
• Current Desktop release from logs: 26.730.61639
• Current app-server: 0.147.0-alpha.1.2
• The affected persisted task was created on Desktop release 26.721.81911 (package 26.721.11231.0)

What subscription do you have?

ChatGPT account (exact tier omitted; not relevant to this local-state issue).

What platform is your computer?

Microsoft Windows 10 Pro 10.0.19045, x64.

What issue are you seeing?

A completed local task still shows all 7 subagents as “Processing” in the Subagents pane. Their displayed durations continue increasing (observed at about 5 days 22 hours) even though the parent task and every child task finished days earlier.

Local state inspection shows:

• parent task state: idle
• every child latest turn: completed
• every child: error = null
• every child has a persisted final answer
• an immediate wait/status check reports every child as inactive
• nevertheless, the parent-side Subagents pane renders all 7 children as active

This is a stale UI/state-reconciliation problem, not actually running work.

The original Desktop log contains the following fingerprint for the affected child conversation IDs:

Received turn/started for unknown conversation conversationId=<redacted-child-id>
Received turn/completed for unknown conversation conversationId=<redacted-child-id>

The persisted parent rollout contains sub_agent_activity records with only started / interacted kinds and no terminal/completed child activity. This explains why the parent-side pane can keep counting indefinitely.

After upgrading to 26.730 and reopening the task, the app successfully reads the persisted child threads and reports their latest turns as completed, but it does not reconcile/backfill the missing parent-side terminal activity. The log also contains:

Conversation state not found conversationId=<redacted-child-id> rendererWindowAppearance=avatarOverlay

Restarting the app and reopening the task does not repair the stale status.

What steps can reproduce the bug?

This was reproduced consistently when reopening one persisted task; I have not yet produced a minimal fresh-task reproduction on 26.730.

1. On an older Desktop build (the affected task used release 26.721.81911), run a local task that spawns multiple subagents.
2. Allow every child to complete and return a final answer.
3. Allow the parent task to complete.
4. Upgrade to Desktop 26.730.
5. Reopen the historical parent task and open the Subagents pane.
6. Observe that completed child tasks still show “Processing” and their elapsed durations continue increasing.
7. Restart and reopen; the stale statuses remain.

What is the expected behavior?

When a historical parent task is opened, the Desktop app should hydrate/reconcile each subagent entry from the child thread's authoritative latest-turn state.

If a child latest turn is terminal (completed, failed, cancelled, etc.), the parent-side activity should be backfilled or derived as terminal even when the older parent rollout is missing a completion event.

Incoming child events that arrive before conversation registration should also be queued/replayed instead of being permanently dropped as “unknown conversation”.

Why this is distinct from related reports

This appears related to #32737 and the Windows evidence in #32738, which describe subagent events being dropped as unknown conversations. It is also related to #23821.

The additional failure mode here is upgrade/history reconciliation: the current app can read the child threads and their completed latest turns, but reopening the historical parent still does not repair the parent-side “Processing” state. Fixing only live child registration may therefore leave already-corrupted persisted tasks permanently stale.

Impact

• Users cannot tell whether subagents are actually consuming work/concurrency.
• Elapsed durations become meaningless and grow indefinitely.
• Restarting or upgrading does not self-heal historical tasks.
• The UI contradicts the authoritative persisted child turn state.

Thread IDs, local paths, task content, account details, and the screenshot were intentionally omitted from this public report, but can be supplied privately if maintainers need them.