[FEATURE] Let claude-vscode.editor.open target a working directory (git worktrees)

Preflight Checklist

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

Problem Statement

The VS Code extension can open a Claude session in a tab, but that session's working directory is always the window's first workspace folder. There is no way to open a session anywhere else — and this makes the git worktree workflow unsafe.

I maintain a VS Code extension that manages worktrees: each change gets its own worktree and branch, and a session is opened to work on it. The session receives a prompt naming that worktree, but it starts in the main checkout, on the main branch.

I measured this rather than assuming it, by asking the launched sessions where they actually were:

• 4 of 4 sessions opened this way began in the main checkout on main, while their prompt announced a worktree. Two said they would have committed there had they not been asked to check.
• A session can move itself with cd, but it does not survive the turn: the directory holds for the rest of the turn it was set in, and is back at the main checkout on the next one. Measured three times, including turns triggered by a human with no other change (same model, same date, no cross-session message).
• The Primary working directory: ... notice arrives attached to the result of the first command of a turn, never before it is chosen. So at the moment a session picks its first command, a stale cd is indistinguishable from a live one.

The practical consequence is a session that edits and commits in the wrong tree, silently, and only learns of it afterwards. The only mitigation available today is prompt text asking the session to re-anchor every single command — prevention by discipline, on exactly the long-running sessions that worktrees exist for.

Proposed Solution

An optional working directory when opening a session:

claude-vscode.editor.open(sessionId, initialPrompt, viewColumn, { cwd })

The session would start in cwd and stay there, the way a claude launched from a terminal already does. The same option on claude-vscode.primaryEditor.open and claude-vscode.sidebar.open would be equally useful.

A narrower version would solve the problem just as well if a free-form cwd is undesirable: accept a directory only when it is inside the current workspace, or inside a git worktree of the same repository.

Alternative Solutions

• vscode.openFolder(uri, { forceNewWindow: true }) — works, and is what Claude Code's own worktree flow does, but it costs a full VS Code window per worktree. With several agents working in parallel that is unusable, and it is the reason I did not ship it.
• vscode.window.createTerminal({ cwd, shellPath, shellArgs }) running the CLI — genuinely correct, stays in the same window, and needs no new API. But it gives a terminal panel instead of the tab UI, and means maintaining a second launch path alongside the first.
• Reordering workspace folders so the worktree is first — changing folder index 0 restarts every extension host, including the one performing the launch.
• Prompt instructions telling the session to cd and re-anchor every command — what I do today. It does work when followed: one real 90-minute session, three branches, five commits, nothing misplaced. But it held, in that session's own words, "only because I repeated it every time".

Additional Context

claude-vscode.editor.open is a registered VS Code command, which makes it a natural integration point for extensions that manage repositories. My extension probes for it at runtime and falls back to the clipboard when it is absent.

A cwd option would be the smallest change that makes worktree workflows correct by construction instead of by instruction, and it would benefit any extension that opens a session on something other than the window's root — monorepo tooling and multi-root workspaces have the same problem.

Environment: Claude Code VS Code extension 2.1.251, Windows 11.