[BUG] TaskList wipes from in-memory state on Stop events at plain turn boundaries (no /compact, no /clear) — disk taskdir intact

Resolved 💬 8 comments Opened May 11, 2026 by deafsquad Closed Jul 11, 2026

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

  1. Start a fresh session: claude
  2. TaskCreate three tasks, e.g.:
  • "Task A"
  • "Task B"
  • "Task C"
  1. TaskUpdate one of them to status: in_progress
  2. Submit ANY plain user turn (a single word like "ok"). Just one Stop event between turns.
  3. Re-query TaskList.

Expected: all three tasks still visible with original statuses.
Observed:

  • TaskList → "No tasks found"
  • ~/.claude/sessions/{sid}/supervisor-state.jsontodos_added: [], todos_in_progress: []
  • ~/.claude/tasks/{sid}/10124.json, 10125.json, 10126.jsonstill 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_ID env 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 /compact reports (#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-session does not inherit CLAUDE_CODE_TASK_LIST_ID
  • #20424 — CLAUDE_CODE_TASK_LIST_ID silently ignored in -p mode
  • #27919 — Task list UI stops advancing after auto-compact

Ask

  1. Acknowledge whether this is intended behavior or a regression.
  2. If regression: identify the version that introduced the Stop-event clearing.
  3. Either persist in-memory TaskList state across Stop events, or hydrate from disk on every TaskList read.

View original on GitHub ↗

This issue has 8 comments on GitHub. Read the full discussion on GitHub ↗