[BUG] sessions/conversations dissapear and forking breaks in vscode plugin UX after using EnterWorktree tool

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Using the VSCode Claude extension:
When a session's working directory changes to a git worktree through the invocation of the EnterWorktree tool, its transcript is relocated to the ~/.claude/projects/ subdirectory named for the worktree path. Relocating storage on a directory change is documented, intended behavior But this relocation leads to unexpected and undesireable UI visibility and behavior changes: from the original vscode window(MacOS window. vscode sometimes also calls editor panes/tabs windows but that's not what I mean here) with the repo root folder open, the session becomes unreachable in three ways. (These are observed via the VS Code extension; I have not localized whether the defect is in the extension UI, its bundled CLI, or shared core. I suspect the issue may be the consequence of incoherent models of the various abstractions such as projects, sessions, windows, etc at play across the various interacting software components leading to the behaviors on display and resolving the issue likely will require developing a unifying theory in the sense Peter Naur describes in Programming as Theory Building. I understand how this is potentially challenging given the interacting software components(claude, git, vscode at a minimum) involed here and their varying provenance and ownership, so sincerely I wish you good luck)

1. Fork fails, deterministically from any non-initial message Forking(via the rewind button in the upper right corner of a user message) from the initial prompt in the session works; forking from any subsequent message fails with Failed to fork conversation: Session <id> not found. Fork in the vscode ui appears to look for the session inside the claude project associated with the vscode os window's(not tab/editor pane which vscode also sometimes calls a window) open folder, which the session got moved out of when the EnterWorktree tool was invoked.
2. Window reload renders the session display empty. reloading the window by pressing Cmd+Shift+P and selecting 'Developer: Reload Window' from the command palette results in the session tab being re-rendered as if the session had no history("Ready to code?…")
3. The custom title is stranded. renaming the session in the sidebar of the window it was created in doesn't change the name of the underlying session now located in the worktree project.

No data is actually lost (the full transcript is intact in the worktree project), but every UI path to the session from the top level repo directory window is broken. Per the docs, "session ID lookup is scoped to the current project directory and its git worktrees,". IIUC that makes this all "documented" behavior, but not a particularly happy or intuitive user experience(Anthropic is not Microsoft of the 90s. I'm sure you can do better than "it's documented therefore it's not a bug").

What Should Happen?

A session should remain discoverable, forkable, and rewindable from the window it was started in. A git worktree isolates concurrent code changes in a single git repo; it should not hide the session from the UI. Alternatively, entering a new worktree, and thus entering a new claude project could trigger the automatic opening or raising of a new vscode window with the worktree folder already open, and warp the session tab/pane into this new window, but while this would be a more legible/discoverable experience than the current behavior, it feels like a pretty surprising user experience, and surprising the user is generally not desirable. surprising but legible/discoverable is probably better than surprising and illegible/hidden(and in a way which resembles data loss to the user even if the data is still there and merely hard to discover in it's new location) which is how I'd characterize the current behavior, but it's not as desirable as intuitive and legible.

Error Messages/Logs

"Failed to fork conversation: Session <session-id> not found"

Steps to Reproduce

This can be reproduced using a synthetic throwaway repo.
macOS note: /tmp resolves to /private/tmp, and the project-dir slug uses the resolved path, so buckets appear as -private-tmp-wt-bug*.

1. run mkdir /tmp/wt-bug && cd /tmp/wt-bug && git init -q && git commit -q --allow-empty -m init
2. run code /tmp/wt-bug
3. open claude code sidebar and click "new session"
4. enter "this is the start of a new session named 'hal'" as an initial prompt
5. enter "while in this session, do not activate any additional skills(tool use is fine). stick to only what's already in your context and messages you receive from me." — I did this to prevent activation of the superpowers:using-git-worktrees skill and show that the behavior depended only on use of the builtin EnterWorktree tool, and not customizations present in my environment.
6. enter 'using a new git worktree please create a new file called dave.html containing the text "I'm sorry, I can't do that"' — Claude creates one with the built-in EnterWorktree tool (worktrees docs, no plugin required), moving the session's cwd into .claude/worktrees/<name>/. and storage into `~/.claude/projects/<worktree-slug>
7. enter "please rename this session 'Paradox'", so the session has both a pre-move and a post-move message.
8. Rename the session "9000" using the claude code sidebar — this updates the name in the sidebar, but not in the tab's label. I believe this is a distinct bug, and unrelated to the worktree bug this report is about. I haven't looked to see if it's been reported or reported it myself yet. closing and re-opening the tab, or reloading the window via the command palette will sync the tab name with the sidebar name whether you're using worktrees or not, but don't do either yet.
9. Inspect on disk:

```bash.

repo bucket: only a 1-line custom-title stub, no body

cat ~/.claude/projects/-private-tmp-wt-bug/<id>.jsonl

-> {"type":"custom-title","sessionId":"<id>","customTitle":"..."}

worktree bucket: the full transcript (same <id>), incl. pre-move records

wc -l ~/.claude/projects/-private-tmp-wt-bug--claude-worktrees-<name>/<id>.jsonl

69 /Users/<redacted>/.claude/projects/-private-tmp-wt-bug--claude-worktrees-dave/45996f7f-4c8e-4e75-9ac0-35e94fa114c1.jsonl

10. From the repo-root window, **fork from the initial message** → succeeds (new tab with initial prompt prefilled for editing).
11. **Fork from any subsequent message whether sent before or after the EnterWorktree tool was invoked ** → `Failed to fork conversation: Session <id> not found`.
12. **Developer: Reload Window** → the window which previously showed the entire session history renders empty like a newly started session. -- alternatively, closing the tab, and re-opening it from the sidebar entry in that same window will also reveal an empty session.

### Claude Model

Not sure / Multiple models

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

2.1.199

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Other

### Additional Information

**Workaround (confirms data is safe):**
```bash
cd <repo>/.claude/worktrees/<name>
claude --resume <id>                    # resume the session
claude --resume <id> --fork-session     # the fork the GUI couldn't do

Or open the worktree folder itself as the VS Code workspace. this can't be done via the gui since it hides dotfiles/folders when opening a folder in a new window.

additional observations:

• the worktree transcript references pre-move offloaded tool-results by absolute path back into the repo's project dir, so the two projects are entangled; - this was claude's observation and I haven't verified, so take with a grain of salt.
• issue #27678 ("Unified conversation history across worktrees and project paths") describes the same underlying project fragmentation problem but is closed/auto-locked; this is the new issue the auto-lock message directs users to file.
• https://code.claude.com/docs/en/worktrees#start-claude-in-a-worktree mentions that "As of v2.1.198, entering or exiting a worktree also relocates the session transcript to that directory’s project storage, the same way /cd does, so /desktop and --resume find the session there afterward." https://code.claude.com/docs/en/sessions#where-the-session-picker-looks says "From v2.1.169, moving a session with /cd relocates it to the new directory’s project storage, so it appears in that directory’s picker afterward. As of v2.1.196, a moved session stays out of the old directory’s picker even after a crash or forced exit. On earlier versions, it could also reappear in the old directory’s list after an exit that wasn’t clean when the old path contained special characters such as underscores." These changes are likely the source of this bug/behavior.