[BUG] VSCode: forking copies the conversation but never attaches the new tab to it - blank chat, and the fork is invisible in the session list (2.1.226)

Confirming the same behavior here. Clicking the fork icon (curved back-arrow) on a past message opens a new window, but that window is a completely fresh session with none of the original conversation's context — matches the "copy works, attach doesn't" diagnosis above. Reproduced across multiple different sessions, not isolated to one conversation.

Environment:

• Extension: anthropic.claude-code 2.1.226
• Claude Code CLI on PATH: 2.1.87
• VS Code: 1.132.0 (arm64)
• OS: macOS 26.6 (Darwin 25.6.0), arm64

The four forked .jsonl files are already there; the blank tab is the attach step failing, not the conversation copy. Opening the fork from the session list after a reload, or resuming its UUID directly, should let you use the existing conversation history while the extension fix is pending.

I built BasedGPT/claude-code-session-recovery for related VS Code session-list failures. Run python tools/diagnose.py first and follow the exact command it prints. If it routes you to recover_vscode_sessions.py, run the dry run to see what it would add, then keep VS Code fully closed before applying anything.

For one immediate check, look in ~/.claude/projects/<project>/ for the newest fork .jsonl and run claude --resume <that-uuid>. That confirms the transcript file is usable and keeps the extension's missing resume field separate from a real loss of conversation history.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

Confirming on 2.1.237 (Cursor, macOS 26.6 arm64, extension host log). I captured the exact moment the session id is lost, which I think narrows this from "forking is broken" to a single hop.

The id is present, then dropped 1.2 s later

Fork performed while completely idle; source is a long-running conversation. Timings from Claude VSCode.log:

09:46:51.817  fork_conversation      forkedFromSession: <SRC>, resumeSessionAt: <MSG>
09:46:52      <FORK>.jsonl written to disk — 68.1 MB, complete, session ids rewritten
09:46:52.701  new_conversation_tab   sessionId: <FORK>     <-- id IS present here
09:46:53.911  Spawning Claude ...    resume: undefined     <-- id is gone

For contrast, a normal session open in the same log a minute earlier:

launch_claude  ... "resume":"<SRC>","thinkingLevel":"default_on"

The launch_claude message the webview emits after a fork has no resume field at all. The extension host then forwards e.resume (undefined) into the spawn, so the blank session is a faithful consequence of an empty argument rather than anything going wrong in the host.

So the loss is between new_conversation_tab — which does receive the new session id — and the newly created tab's own launchClaude() call. From the shipped webview bundle:

startNewConversationTab(e,t) -> send({type:"new_conversation_tab", initialPrompt:e, sessionId:t})
launchClaude(e,t,i,n,o)      -> send({type:"launch_claude", channelId:e, cwd:i, resume:t, ...})

The id reaches the first call; the second is invoked with t undefined. Reproduced 2/2 today, and 23 times total since 2026-07-31.

Minor refinement to the "invisible in the session list" symptom

The report attributes the fork's absence from the session picker to the same root cause. I think that part is simpler: a session is only titled after its first user message (the log shows generate_session_title -> rename_session firing immediately after the first prompt). An unopened fork therefore carries no custom-title / ai-title entry for the same ordinary reason any untouched new chat doesn't. It's a consequence of the fork never being opened, not a second defect — though it is what makes the orphan unrecoverable through the UI.

Scale, and a data-loss risk worth flagging

23 orphaned forks accumulated here between 2026-07-31 and 2026-08-20, ~0.93 GB, all from one conversation. Each is complete and opens fine with claude --resume <uuid>.

The part that concerns me most: cleanupPeriodDays defaults to 30 days and deletes transcripts. An orphaned fork is written once and never touched again, so its mtime never advances — it is a prime cleanup candidate while being invisible in the UI for its entire life. A user who forks a conversation they care about can lose that copy silently, without ever having known it existed. Raising cleanupPeriodDays mitigates it, but the orphan shouldn't be created in the first place.

Happy to provide more log extracts if useful.

Follow-up to my comment above — two findings since, one of which gives a working manual recovery for orphaned forks.

Correction: last-prompt is the visibility key, not the titles

I attributed the fork's absence from the session list to the missing title entries. More precisely, it's last-prompt. Across 45 transcripts here:

| | last-prompt | ai-title | custom-title |
|---|---|---|---|
| sessions visible in the sidebar (19) | 19 | 6 | 15 |
| orphaned forks (25) | 0 | 0 | 0 |

last-prompt is appended each time a prompt is sent:

{"type":"last-prompt","lastPrompt":"...","leafUuid":"<uuid>","sessionId":"<id>"}

Its presence is what makes a session listable; the title entries only determine what the row is named (custom-title > ai-title > falls back to the raw lastPrompt text). The decisive case was a session I created with a single "." as the prompt: it has last-prompt, no title entry at all, and is listed — displaying "." as its name.

So an orphan is unreachable for the plain reason that no prompt was ever sent into it. It needs a message to become visible, and visibility to receive a message.

Manual recovery (verified working)

An orphan can be made visible and fully usable by appending two lines to its .jsonl. Take leafUuid from the last user message in that file:

{"type":"last-prompt","lastPrompt":"<text of last user message>","leafUuid":"<its uuid>","sessionId":"<orphan uuid>"}
{"type":"custom-title","customTitle":"RECOVERED_<whatever>","sessionId":"<orphan uuid>"}

Then Developer: Reload Window. Result on a 68 MB orphan here: it appeared in the sidebar under the given name, opened with full history, and answered a context-dependent question correctly. It is now a normal working session. Append-only, so it reverts byte-exactly with os.truncate(path, original_size).

claude --resume <uuid> also opens an orphan, but this brings it back into the extension UI, which is where users will look for it.

Restating the cleanup risk, now that recovery is known to work

Since orphans are fully recoverable, the cleanupPeriodDays default of 30 days is destroying something genuinely retrievable. An orphan's mtime never advances past its creation, so it is the first thing a time-based cleanup removes, while being invisible in the UI for its entire life. Users lose recoverable forks without ever knowing they existed.

Correction to my earlier figure: the final count here was 25 orphans, not 23 — two more from a second conversation that my initial content-based filter missed. Structural test (no last-prompt, never modified after creation) is the reliable way to enumerate them.