[Windows App] Task summary panel shows completed child pages as “Working” with timers still increasing
Environment
- App: ChatGPT/Codex Desktop
26.810.7004.0 - Platform: Windows 11 Pro, build
26200, x64 - Authentication: ChatGPT subscription
- Surface: right-side task summary panel / pinned summary view
What issue are you seeing?
Completed historical child/subagent pages are shown as Working in the right-side task summary panel, and their elapsed timers continue increasing even though those children finished days or weeks earlier and no longer represent active work.
This is reproducible across multiple local projects. Opening or pinning the task summary makes old child pages appear live. The timer is therefore not a reliable indication of current execution.
Steps to reproduce
- Use a parent task that creates several child/subagent tasks.
- Let the children complete or interrupt them.
- Later, return to the parent or another project and open/pin the task summary panel in the right sidebar.
- Observe historical child pages displayed as Working.
- Leave the panel open and observe their elapsed timers continue counting.
Expected behavior
- Completed, interrupted, archived, or otherwise non-live children should display a terminal/inactive state.
- Their elapsed timers should stop.
- The summary panel should derive current activity from live lifecycle state, not a stale persisted relationship.
- If persisted and live state disagree, the UI should reconcile or clearly label the child as stale.
Actual behavior
Historical child pages continue to display Working with increasing timers.
A read-only inspection of state_5.sqlite found the same stale lifecycle invariant described in related reports:
thread_spawn_edges:
closed = 24
open = 60
The 60 persisted open edges are divided across two historical projects:
Project A: 48 open edges
48/48 child threads archived
latest child update: 2026-07-18
Project B: 12 open edges
latest child update: 2026-08-08
These dates and archived states do not match the summary panel's current Working labels or continuously increasing timers.
The counts were obtained read-only with:
SELECT status, COUNT(*)
FROM thread_spawn_edges
GROUP BY status;
SELECT
t.cwd,
COUNT(*) AS open_edges,
SUM(CASE WHEN t.archived = 1 THEN 1 ELSE 0 END) AS archived_children,
datetime(MAX(t.updated_at), 'unixepoch', 'localtime') AS newest_update
FROM thread_spawn_edges e
LEFT JOIN threads t ON t.id = e.child_thread_id
WHERE e.status = 'open'
GROUP BY t.cwd;
No database rows were modified.
Impact
- Users cannot trust the summary panel to identify active work.
- Old timers create the impression that agents are still consuming time or resources.
- The stale state persists even when affected child threads are archived.
- This may lead users to repeatedly attempt cleanup or avoid using subagents.
Related issues
- #23930 — closed/completed subagent cards remain visibly stuck after no live handle remains.
- #33700 — completed/interrupted descendants remain persisted as
openinthread_spawn_edges. - #25341 — child threads can retain stale open spawn edges and pollute UI listings.
This report is separate because it reproduces on Windows and specifically affects the pinned/right-side task summary's Working status and continuously increasing elapsed timer.
I can provide additional sanitized read-only queries or app logs if maintainers identify the most useful lifecycle event to capture. No thread IDs, titles, prompts, repository names, or local paths are included in this public report.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional failure mode: summary panel error boundary after restart
I reproduced a second failure mode in the same Windows environment as this report.
After restarting Codex, a newer continuation task in the same project opens and works normally, but its right-side Thread summary panel shows an error state with Try again. Selecting Try again does not recover the panel.
Read-only validation
26.810.7004.0codex@26.810.52044idle; its recent turns arecompletedwith no task-level error.Renderer error
The renderer error boundary records:
The useful stack path is:
The same error is recorded repeatedly when conversation stream state is refreshed. This indicates that the panel's reactive query/equality path is being evaluated outside its expected atom context during conversation hydration/state replacement.
Interpretation
This does not appear to be a missing transcript, a corrupt task, or an unresolved child row. It is a client-side
ThreadSummaryPanelstate-management failure. The retry action remounts the same component against the same broken state, so it fails again.This is distinct from the original stale Working labels, but it appears to be in the same restart/hydration family: archived child state is reconstructed after restart, and the summary panel can either display stale lifecycle projections or crash its error boundary entirely.