[Windows App] Task summary panel shows completed child pages as “Working” with timers still increasing

Open 💬 2 comments Opened Aug 16, 2026 by serdox
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Use a parent task that creates several child/subagent tasks.
  2. Let the children complete or interrupt them.
  3. Later, return to the parent or another project and open/pin the task summary panel in the right sidebar.
  4. Observe historical child pages displayed as Working.
  5. 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 open in thread_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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 11 days ago

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

  • #38725
  • #37729
  • #38805

Powered by Codex Action

serdox · 10 days ago

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

  • Installed Windows package: 26.810.7004.0
  • Renderer telemetry release: codex@26.810.52044
  • The supported thread reader loads the affected task successfully.
  • The task is idle; its recent turns are completed with no task-level error.
  • The affected task has 0 direct spawn-edge records.
  • Its older source task has 46 child records; all 46 resolve to existing thread rows and all 46 are archived. There are 0 missing child rows.
  • No SQLite data was modified.

Renderer error

The renderer error boundary records:

Error: Query result tracker read outside atom evaluation
name=ThreadSummaryPanel

The useful stack path is:

Xf.isEqual
Fa.isEqual
notifyThreadField
setConversation
handleThreadStreamStateChanged
threadStreamStateChanged

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 ThreadSummaryPanel state-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.