[BUG] TaskList wipes from in-memory state on Stop events at plain turn boundaries (no /compact, no /clear) — disk taskdir intact
Summary
CC's in-memory TaskList state is being cleared on plain turn boundaries (Stop events) — no /compact, no /clear, no /resume, no claude agents reattach. The on-disk ~/.claude/tasks/{session_id}/*.json files are preserved correctly with their statuses, but CC's TaskList tool reports "No tasks found" and supervisor-state.json shows todos_in_progress: [] after every turn end.
Multiple users have reported related symptoms scoped to specific operations (/compact, resume, recap); we suspect a recently-aggressive Stop-event state reset is the common cause across all of them.
Version
claude-cli 2.1.139 (external CLI, Windows host, native binary)
Reproduction
- Start a fresh session:
claude TaskCreatethree tasks, e.g.:
- "Task A"
- "Task B"
- "Task C"
TaskUpdateone of them tostatus: in_progress- Submit ANY plain user turn (a single word like "ok"). Just one Stop event between turns.
- Re-query
TaskList.
Expected: all three tasks still visible with original statuses.
Observed:
TaskList→ "No tasks found"~/.claude/sessions/{sid}/supervisor-state.json→todos_added: [],todos_in_progress: []~/.claude/tasks/{sid}/10124.json,10125.json,10126.json→ still on disk, statuses preserved
Captured evidence
Live demonstration on this user's setup just minutes ago:
$ ls ~/.claude/tasks/0c302c78-3bf7-4e3e-84ac-fe84c0aeefb8/
10124.json 10125.json 10126.json ← all three intact, 10126 status=in_progress
$ # CC's view via TaskList tool
TaskList → "No tasks found"
$ # action-tracker hook reading supervisor-state.json
(State: 0 pending, 0 in_progress, 0 completed)
The wipe happens on Stop event — no other operation between turns.
Suspected root cause
Hypothesis (from related-issue threads):
- CC scopes tasks via an internal
CLAUDE_CODE_TASK_LIST_IDenv var (see #20664, #20424). Disk files persist under that ID, but CC's in-memory pointer to "which task-list-id to query" gets cleared on Stop events. - This is the same mechanism causing the
/compactreports (#47533, #54508) and the resume rendering bug (#50656) — the difference is that the Stop-event clearing is more aggressive in recent versions. - Users have noted the new recap / active-time display feature also exhibits the same clearing pattern, suggesting both share the Stop-event state-reset path.
Workaround we're using
A UserPromptSubmit hook (task-autorestore.py) reads disk + writes the live taskdir back to compensate. CC's in-memory TaskList still reports empty until the tool is called, at which point it reads disk. We had to write a second hook (session-migrate-tasks.py) for the claude agents reattach case because that re-keys the session_id.
We shouldn't need to maintain this glue.
Related (open, no Anthropic response on any)
- #47533 — Tasks lost during conversation compaction (downgraded to
enhancement— please reconsider; users treat this as a bug) - #54508 — CC tasks disappear from TUI after /compact (session ID not preserved)
- #50656 — Task list UI not rendered after session resume
- #20664 —
--fork-sessiondoes not inheritCLAUDE_CODE_TASK_LIST_ID - #20424 —
CLAUDE_CODE_TASK_LIST_IDsilently ignored in-pmode - #27919 — Task list UI stops advancing after auto-compact
Ask
- Acknowledge whether this is intended behavior or a regression.
- If regression: identify the version that introduced the Stop-event clearing.
- Either persist in-memory TaskList state across Stop events, or hydrate from disk on every TaskList read.
This issue has 8 comments on GitHub. Read the full discussion on GitHub ↗