[BUG] Task store is addressed by session ID, so a new session ID silently strands existing tasks on disk (files intact, TaskList empty)

Preflight Checklist

• [x] I have searched existing issues and this is not a duplicate (see the differential below)
• [x] This report is about a single bug
• [x] I am on the latest version (2.1.236, stable channel)

What's Wrong?

Differential first, since several open issues touch this same directory and none of them is this bug:

• Not #88346 — that one is the opposite symptom: task files being deleted with no tool call. Here nothing is ever deleted; every file survives, at the old address.
• Not #88129 — that is an enhancement request for an external-writer contract plus a UI repaint. This is the built-in tools losing sight of their own store.
• Not #90496 — that is a panel repaint bug. TaskList itself returns empty here, not just the UI.
• Not #90332 — that concerns the agent-team hub registering under a stale placeholder ID; different consumer, same underlying "the session ID moved" family.
• Prior art, closed and locked by the inactivity bot, never answered by anyone with write access: #20797 (the original report, plus three independent commenters confirming the mechanism) and #20900 (adjacent: asks for a SessionStart hook on clear-context, which would at least let a script migrate the store itself).

The bug. Tasks created with TaskCreate are persisted under ~/.claude/tasks/<sessionId>/. The session ID is part of the store's address, so anything that starts a new session ID leaves every existing task file sitting under the previous ID. TaskList, TaskGet and TaskUpdate only ever read the current session's directory, so the tasks become invisible — no error, no warning, just an empty list. Worse, updates made afterwards land in the new, disconnected directory, so the work ends up split across two directories with neither holding the whole picture.

Observed triggers, all of which mint a new session ID: accepting a plan with "clear context" (the path #20797 originally described), a compaction-driven restart, and an MCP disconnect/reconnect.

What Should Happen?

Either the task files move/attach to the new session ID when one replaces the old one, so TaskList keeps seeing them — or, at minimum, the CLI says plainly that a new session has started and the previous tasks are still on disk under the old ID.

Worth noting for scoping: nothing is lost here, only re-addressed. A fix is a directory move or merge, not data recovery.

Error Messages/Logs

N/A — this fails silently. There is no error to paste, which is part of why it goes unnoticed until the list is already empty.

Steps to Reproduce

1. Ensure the task tools are available. As of v2.1.233 they are opt-in on current-generation models: set CLAUDE_CODE_ENABLE_TODO_TOOLS=1.
2. In a session, create several tasks with TaskCreate.
3. Confirm they are on disk: ls ~/.claude/tasks/ — note the session-ID directory and the numbered *.json files inside it.
4. Cause a new session ID. Any of these does it:

• enter plan mode, then accept the plan with "Yes, clear context and auto-accept edits";
• let a long session hit a compaction-driven restart;
• disconnect and reconnect an MCP server.

1. Run TaskList in the resulting session.

Expected: the tasks from step 2 are listed.
Actual: TaskList returns empty. ls ~/.claude/tasks/ now shows a second session-ID directory; the original files are still present, intact, under the first one. TaskUpdate against a known task ID reports it as not found.

Frequency, from one long-running multi-agent workflow that depends on task tracking: the store was stranded four separate times — three times from a session-ID change and once from an MCP disconnect/reconnect. The common factor across all four is only that the session ID changed, which is wider than the single plan-mode path #20797 named. Recovery each time meant reading the JSON out of the old directory by hand, since nothing in the CLI can reach it.

Environment

• Claude Model: Not sure / Multiple models (session-layer bug, not model-dependent)
• Is this a regression?: No, this never worked
• Claude Code Version: 2.1.236
• Platform: Claude Code CLI
• Operating System: Windows 11 Pro
• Terminal/Shell: Windows Terminal (PowerShell)

Additional Information

Context that changes who is affected: as of v2.1.233 the task tools (TaskCreate/TaskGet/TaskUpdate/TaskList, and TodoWrite) are no longer available by default on Opus 4.8, Sonnet 5, Fable 5, Mythos 5 and newer models; setting CLAUDE_CODE_ENABLE_TODO_TOOLS=1 restores them. That shrinks the default-exposed population, but the people who deliberately opt back in are exactly the ones running long, multi-session, multi-agent work — the population that most needs a task store to survive a session-ID change. The mechanism itself is untouched by any changelog entry through 2.1.251.

On the prior reports: #20797 was closed not_planned by the inactivity bot with no fixing commit attached, then auto-locked seven days later. Three separate people had confirmed the mechanism in its comments beforehand. This report follows the lock bot's own instruction to file fresh and reference it.