[FEATURE] Add --worktree support for parallel sessions in VS Code (same as Agent View in VSCode does)

[JohannesMilke]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

The VSCode plugin for Claude is not yet supporting the option to create worktrees.
Please add VS Code extension: Add --worktree support for parallel sessions

Allow each Claude Code conversation tab/window in VS Code to run in a separate Git worktree, like the CLI does with claude --worktree <name>. This enables multiple agents to work on the same codebase simultaneously without conflicts, and create separate PRs per feature.

Currently all VS Code sessions operate on the same main branch. The CLI already supports this perfectly—the extension just needs to expose it.

Proposed Solution

Be able to choose for each session in VSCode Claude if it should work in a separate worktree or not.
And show when a session is completed or still processing.

Alternative Solutions

No response

Priority

Critical - Blocking my work

Feature Category

Interactive mode (TUI)

Use Case Example

No response

Additional Context

No response

[kcarriedo]

The gap here is real: the CLI worktree flag (claude --worktree <name>) gives you filesystem isolation per session, but the VS Code extension has no equivalent, so all extension tabs share the same working tree. For anyone running parallel feature work through the extension, that means agents can step on each other's changes without warning.

A short-term workaround: open separate VS Code windows (not tabs), each pointing to a manually created worktree directory. The extension treats each window as its own session and does not try to merge context between them. It is more friction than a first-class --worktree flag in the extension UI, but it gets the isolation behavior without waiting for the feature.

Would be worth clarifying in the issue whether the request is for (a) automatic worktree creation per extension tab/conversation, or (b) a setting to point an existing extension window at a specific worktree path - the implementation path differs enough that it is worth separating.

[shurkanTwo]

+1

[kcarriedo]

The CLI and extension parity gap is real. The CLI worktree flow (claude --worktree <name>) plus a small shell wrapper to manage worktree lifecycle is usable today, but it requires you to leave VS Code entirely for the parallel session management, which defeats most of the point for people whose review workflow lives in the editor.

One pattern that partially bridges this until native support ships: use VS Code multi-root workspaces where each root points to a separate git worktree directory. You lose the Claude Code session-status panel, but you can run a separate Claude Code terminal in each root and the worktrees stay isolated. It is manual overhead but it does prevent the branch collision problem.

The session status display (processing/completed) you mentioned in the proposal is the piece I find most valuable beyond just worktree isolation. Even without worktree support, knowing which of your parallel sessions has finished and which is still running would meaningfully reduce the context switching cost of managing multiple agents.

[bcherny]

Thanks for the request. The VS Code extension doesn't have a per-session worktree toggle yet, but you can get isolation today: in any extension conversation, ask Claude to "work in a worktree" and it will create one under .claude/worktrees/ and move that session into it, so parallel conversations don't step on each other. Docs: https://code.claude.com/docs/en/worktrees

Leaving this open for a first-class option in the extension UI.

🤖 Generated with Claude Code