[FEATURE] VS Code extension: include git-worktree sessions in the session list (it hardcodes includeWorktrees: false)

Preflight Checklist

• [x] I have searched existing issues and feature requests to ensure this is not a duplicate
• [x] This is a single feature request (not multiple requests bundled together)

Priority: High - Significant impact on productivity

Feature Category: Other (closest fit — this is about the VS Code extension's session list; the dropdown has no IDE/extension option)

Problem Statement

When a Claude Code session's working directory moves into a git worktree, the VS Code extension permanently loses sight of that session after a window reload or VS Code restart.

The mechanism: Claude Code stores each session under a project directory derived from its cwd (~/.claude/projects/<slugified-cwd>/). When the cwd moves from the repo root into a linked worktree, the transcript relocates to that worktree's project directory. The extension's session list only reads the project directory of the folder currently open in VS Code (its own cwd), so the relocated session is no longer listed there.

This is not a data-loss bug — the transcript is intact on disk. It is purely a discoverability gap in the extension's list.

The pain point is window count. The only way to reach a relocated session in the extension UI is to have that worktree open as the folder in VS Code. So N such sessions require N windows, plus the window on the repo root I was already working in — one window per worktree, purely to see a list. I typically run up to about seven concurrent sessions, each in its own worktree, so this is a routine cost rather than an edge case. Two of my sessions became unreachable from the extension this way:

• #1606 #1607 #1608 Workflow initialization and supervisor state issues
• #1610 Fix workflow-init EnterWorktree permission prompting regression

(Those are issue numbers in my own repository, used here only as session titles.) Each session now lives under its own worktree's project directory (~/.claude/projects/<slug-of-that-worktree-path>/) rather than the repo root's, and neither is listed from the repo-root window.

Note this is distinct from the existing "history disappears" reports (#24172, #29017, #12872) and from the mapped-drive / subst path issues (#63527, #78466, #34125). Those are about history being lost or the list being entirely empty. Here the list works fine — it just excludes worktrees by construction, and only sessions whose cwd moved are affected.

Proposed Solution

The extension already has everything it needs; one call site opts out of it.

In the extension bundle (extension.js, observed on v2.1.218 and v2.1.219), listSessions() calls the shared session-enumeration helper with includeWorktrees pinned to false:

async listSessions(){ let e = await Pme({ dir: this.cwd, includeWorktrees: !1, ... })

The helper itself defaults the same option to true (includeWorktrees ?? !0) and, when enabled, runs git worktree list --porcelain, walks each worktree's project directory, aggregates the sessions, and dedupes by sessionId (keeping the newest lastModified). So the aggregation path is already built and reachable — the extension simply declines it.

Requested change: have the extension pass includeWorktrees: true, or expose it as a setting (e.g. claude-code.includeWorktreeSessions, defaulting to true) for users who prefer the narrow list.

Ideally the listed row would indicate which worktree/branch a session belongs to, since the aggregated list spans worktrees. The enumeration already carries gitBranch and the project path per session, so the data is on hand.

The session docs describe the CLI picker as able to widen to all worktrees of a repository with Ctrl+W, so exposing comparable reach in the extension would also bring the two surfaces closer together.

Alternative Solutions

Patching the extension locally (verified, but not durable). Flipping the single occurrence of includeWorktrees:!1 to includeWorktrees:!0 and reloading the window makes the worktree sessions appear immediately, with no other change. !1→!0 preserves byte length, so nothing shifts in the minified bundle. Both sessions listed above became visible from the repo-root window this way, confirming the aggregation path works correctly as-is.

Naturally, the patch is discarded on the next extension upgrade — which in my case arrived 14 minutes later, silently reverting the behavior.

Use Case Example

1. I work with a worktree-per-task workflow: each task gets its own linked worktree and feature branch, driven by tooling that relocates the running session's cwd into the worktree.
2. A session starts at the repo root (C:\foobar\agents), then moves into a linked worktree (C:\foobar\worktrees\<task>) to do the work.
3. I reload the VS Code window (or restart VS Code) with the repo root open as the folder.
4. Today: the session is gone from the extension's session list. Returning the cwd to the repo root makes it reappear — so the only way to reach it in the UI is to have already left the worktree, or to open a separate window for that worktree.
5. With this change: the session stays listed in the repo-root window and can be resumed in place.

Additional Context

Environment: Windows 11, VS Code extension anthropic.claude-code v2.1.218 and v2.1.219, CLI v2.1.136.

Both the current behavior and the patched behavior were observed on Windows only; I have not tried this on macOS or Linux, so I can't say whether it reproduces there.

I did not test the CLI's behavior directly, so I can't speak to it from experience. For what it's worth, the packaged CLI binary contains no includeWorktrees:!1 and the docs above describe worktree-crossing resume as supported, which suggests the CLI is probably unaffected and that this is specific to the extension's call site.

Measurements, from re-implementing the extension's enumeration logic against my repo root (C:\foobar\agents, which has 57 worktrees registered — mostly finished ones I have not pruned, not 57 active sessions) and checking whether a known relocated session was included:

| Condition | Sessions enumerated | Relocated session present |
|---|---|---|
| includeWorktrees=true (helper default) | 246 | yes |
| includeWorktrees=false (extension hardcode) | 238 | no |

On cost: git worktree list --porcelain took 53–73 ms across 57 worktrees, well under the helper's own 5000 ms timeout, so enabling this should not be a meaningful startup expense even on a repo with an unusual number of worktrees.

Two smaller points that may matter to whoever picks this up:

• Because the enumeration dedupes by sessionId, a session being live in another VS Code window is not a reason to hide it — the same session can legitimately appear in more than one list.
• I could not find a setting to change this: the extension's package.json and its settings schema expose no toggle for worktree inclusion.

Full investigation notes, including the reproduction and the verification of the local patch: https://github.com/nirecom/agents/issues/1617