Your Claude Code tasks vanished but the files are still there: the session-ID task store trap

There's a nasty one that shows up in long agent workflows, and it looks exactly like data loss when it is not. Someone on the Claude Code tracker had it happen four times in one multi-agent run: tasks they had created were just gone. TaskList came back empty. TaskGet said not found. Nothing they did in the UI or CLI brought the list back.

The files were still on disk the whole time. The store just stopped looking at them.

What actually happened

Claude Code saves tasks as numbered JSON files under a folder per session:

~/.claude/tasks/<session-id>/

On Windows that is %USERPROFILE%\.claude\tasks\<session-id>\. The session ID is the 36-character hex string that identifies one conversation. TaskList, TaskGet and TaskUpdate only ever read the folder for the session you are currently in.

So when something mints a brand new session ID, the tools start reading a brand new, empty folder. The old folder is never consulted, merged or migrated. No error, no warning. You just get an empty list, and anything you create afterwards lands in the new folder, so your tasks split across two directories with neither holding the full picture.

The session ID changes more often than you'd think:

• accepting a plan with clear-context
• a compaction restart
• an MCP server disconnect and reconnect

Any of those can silently strand your task store.

First, confirm the files are actually there

Before doing anything, check the files exist. This is also how you spot which directory is the orphaned one:

ls ~/.claude/tasks/

You'll see one folder per session, each a long hex ID. The one holding numbered .json files is your old session. The empty one is your current session.

Recover by moving the files

If you have not created new tasks in the new session yet, just copy the orphaned files into the current session folder:

cp ~/.claude/tasks/<old-session-id>/*.json ~/.claude/tasks/<current-session-id>/

Then run TaskList again. The tasks should be back, and TaskUpdate works against their IDs again.

Do this before creating any new tasks. If you already created some, writes are split across two dirs and you'll need to merge carefully or fall back to the manual route.

The manual route, when the copy is not enough

Read the JSON files out of the old directory and recreate the tasks by hand in the new session:

cat ~/.claude/tasks/<old-session-id>/*.json | jq

Then TaskCreate each one in the current session. It's tedious, but it is the one path that always works, since nothing in the CLI can reach the stranded files for you.

Better: avoid the new session ID in the first place

The cleanest fix is not letting the session change. Instead of starting fresh after a compaction or context clear, resume the old session so the store follows the old ID:

claude --resume

That keeps the session ID stable and your task list intact. The catch is you have to know the session changed before it happened, which is usually after the fact.

Where this stands

The task layout and the recovery recipe are confirmed by multiple independent reporters on both Linux and Windows, and the fix is mechanically sound: it's a directory-addressed store, so moving the files is the correct manual repair. The project has not acknowledged the bug in either report as of this writing (one earlier report was closed by the inactivity bot with zero maintainer engagement), so treat this as a known sharp edge rather than something fixed.

Worth doing once: if you run long multi-agent workflows, peek at ~/.claude/tasks/ after any context clear or MCP reconnect before you trust an empty TaskList. Two seconds of ls beats re-creating a week of tasks by hand.

The upstream thread is anthropics/claude-code issue #90731 if you want to track it.