[BUG] Resuming from Agent View forks the session (new id), freezes the original, and empties the task-list panel (per-session taskdir not inherited)

Preflight

Searched existing issues. This is closely related to the area:agent-view fork cluster but is a distinct variant — see Related below. The new information here is that the fork drops the per-session task store while preserving full conversation history.

Environment

• Claude Code 2.1.206
• Windows 11, Windows Terminal
• --resume / background session

Summary

Accidentally opening the Agent View and then resuming the session forks it instead of reattaching. You end up with two sessions for one task: the original freezes a few messages back (orphaned, only clearable with Ctrl+X), and a new session with a new session-id carries the full history forward — but its task-list (todo) panel is empty.

Unlike #72012 (where the reopened session is an empty stub with history lost), here the forked session retains full conversation history — you can scroll back to the same message as the original. The thing that's lost is the task panel state, because the new session-id never gets a task directory.

Steps to reproduce

1. In an active session with a populated task list (Ctrl+T todo panel), press Left arrow — opens the Agent View.
2. Press Esc.
3. Resume the session.

Actual

• The session appears duplicated in the Agent View.
• The original freezes a few messages back — unresponsive, only clearable via Ctrl+X (stop + delete). It stays listed as if live.
• A new session with a new session-id is created, with the full history intact.
• The new session's task-list panel is empty.

Expected

Resuming reattaches to the same session-id and continues it, task panel intact. No fork, no frozen twin, no dropped task state. (Or, if a new id is unavoidable, the task store should be carried to the new id and the orphan retired so it isn't offered for resume.)

Root cause (disk-level evidence)

Task state is stored per session at ~/.claude/tasks/<session-id>/<taskId>.json.

• Original session <original-id>: full task store present — every task file, updated right up to the fork.
• Forked session <new-id>: no ~/.claude/tasks/<new-id>/ directory was ever created.

So the fork inherits no task store. The data is never lost — it persists on disk under the original id; the new session just points at a directory that doesn't exist. This is a load/inheritance failure on fork, not data loss, which also makes it fully recoverable.

The same <original-id> vs <new-id> split shows up in ~/.claude/projects/<project>/: both have a .jsonl transcript, with the fork's much smaller than the original's.

Impact

An easy accidental keypress (Left arrow) silently empties the working task list, spawns a confusing duplicate, and leaves a frozen session needing manual Ctrl+X cleanup.

Workaround

Recover the tasks by reading ~/.claude/tasks/<original-session-id>/*.json and recreating them in the new session (the highwatermark/id counter and every task's subject/description/status are all intact on disk).

Related

• #70373 — same fork-orphan mechanism (new id, original frozen but still listed), but triggered by backgrounding with in-flight subagents; focused on subagent orphaning rather than the task panel. Likely the same root fork behavior.
• #72012 — same "reopen from Agent View → new session-id" family, but there history is lost to an empty stub; here history is preserved and the task store is what's dropped.
• #58137 — task list wipes with the on-disk taskdir left intact (matches the disk evidence here), but a different trigger (Stop events at turn boundaries).