[BUG] In vscode workspace, Claude Code always starts in first project

My current workaround is having a hook/CLAUDE.md that routes to the right project. So annoying.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Is anyone going to look at this as I see it has been reported a few times but they all get automatically closed

Ok this is really annoying. This should be fixed somehow, by either opening with the root folder of the file that is currently open, or a dropdown where the user can select the root.

I am also running into this.

The Gemini CLI extension for VS Code will, upon opening, open a dropdown for you to pick which top-level folder in your workspace to use. The extension doesn't even have a UI, it's just a terminal window with some knowledge of what files you have open, and they managed to figure this one out.

same problem here. are you going to do something?

Same issue here. This is extremely annoying and might make me switch back to cursor. I have a multiroot with a service and ux that are closely paired so being able to work on them in conjunction from vscode in a single workspace greatly increases productivity so claude code not supporting that is a breaking feature thats missing.

I found a workaround with claudeCode.claudeProcessWrapper... create a sh script that cd in the dir you want Claude to start, then call Claude.

claude-wrapper.sh:
`#!/usr/bin/env bash
set -euo pipefail

cd /the/path/you/want
pwd >&2
exec claude "$@"`

In your vscode settings:
claudeCode.claudeProcessWrapper="/path/to/claude-wrapper.sh

Still an issue on v2.1.81. In a multi-root workspace, the extension hardcodes the first folder as the working directory.

Attempted workaround: using claudeCode.claudeProcessWrapper with a script that cds to the parent directory before execing claude. The wrapper runs and the cd succeeds (verified via logging), but the extension appears to send the working directory over the JSON stream protocol after spawning the process, so the cwd override has no effect.

This means sessions created from the CLI in the parent directory don't show up in /resume in the extension, and project-level context (CLAUDE.md, .claude/, memory) scoped to the parent directory isn't picked up correctly.

Would love a claudeCode.workingDirectory setting, or for the extension to respect terminal.integrated.cwd from the workspace file.

Can confirm this is still a problem for the Claude Code Extension for VS Code 1.113.0

Same issue and it is very basic i am surprised to see this in 2026

I have the same issue. I work with 20+ independent repositories under one VS Code workspace. Every Claude Code session defaults to the first folder regardless of which project I am working in. The reorder workaround is not practical when switching between 5 parallel sessions on different projects.
Please add a claudeCode.workingDirectory setting or make the panel detect the active file’s folder as the working directory. This is a blocker for anyone

Can confirm this is still a problem for the Claude Code Extension for VS Code 1.113.0

Yes with

Me did you find a solution or workaround

Can confirm this is still a problem for the Claude Code Extension for VS Code 2.1.112

The team i behind VS Code is probably focusing on solving this via "VS Code Agents" instead. VS Code Agents was just released with a preview version: https://code.visualstudio.com/updates/v1_116#_visual-studio-code-agents-insiders

VS Code Agents targets this precise use case with a GUI specifically tailored for working with parallel agents across multiple projects.

Current workaround remains launching claude manually via integrated vscode terminal.

Sharing a related pain point that stems from the same root cause:

Even if claude config living in a single working directory is acceptable, the problem is that a session has no concept of a VS Code workspace (.code-workspace file). VS Code workspaces let you group multiple unrelated repositories/folders into a named context — and that grouping is persistent across window reloads.

Since Claude Code sessions are tied to a directory rather than a workspace, any additional repos or folders that the agent needs to be aware of are lost when the session or VS Code window is reloaded. You have to manually re-add them every time.

Expected behavior: Starting a session from a VS Code workspace should restore the full set of workspace folders automatically, so the agent has the right context without manual re-configuration on every reload.

Sharing a related pain point that stems from the same root cause: Even if claude config living in a single working directory is acceptable, the problem is that a session has no concept of a VS Code workspace (.code-workspace file). VS Code workspaces let you group multiple unrelated repositories/folders into a named context — and that grouping is persistent across window reloads. Since Claude Code sessions are tied to a directory rather than a workspace, any additional repos or folders that the agent needs to be aware of are lost when the session or VS Code window is reloaded. You have to manually re-add them every time. Expected behavior: Starting a session from a VS Code workspace should restore the full set of workspace folders automatically, so the agent has the right context without manual re-configuration on every reload.

That makes total sense, Kiro does that exactly. It knows about every folder part of the workspace no matter where they are located on the disk. But Kiro agent is built in the IDE, wonder if a plugin have that capability.

Similar issue on Mac where a multi-root workspace is used in VSCode. Claude-Code only recognizes index 0 or root_1 below as the project folder -

{
"folders": [
{
"path": "/Users/xxxx/.local/share/vip/dev-environment/root_1" // Wordpress
},
{
"path": "/Users/xxxx/sites/root_2" // Custom plugins
}
],
....

The files or folders under /root_2/ are not indexed for @ suggestions.

Response from Claude-Code -

That's a Claude Code limitation — the @ file mention autocomplete only indexes the primary working directory (/Users/xxxx/.local/share/vip/dev-environment/root_1), not additional directories configured in the workspace.

The additional working directory (/Users/xxxx/sites/root_2 is accessible to me via tools (I can read/write files there), but it isn't included in the @ suggestion index.

One workaround is to add the workspace root directory itself to the workspace (File -> Add Folder to Workspace...) and move it to be first in the list, this way Claude will start at the workspace root

One workaround is to add the workspace root directory itself to the workspace (File -> Add Folder to Workspace...) and move it to be first in the list, this way Claude will start at the workspace root

That's a clever workaround and might work well for some setups. Though for many of us the assumption of a workspace root doesn't hold — the whole point of a .code-workspace file is often to group unrelated sibling projects that might live in completely different locations on disk with no shared parent that means anything.

Even when a common parent technically exists, putting it first just to trick Claude into starting there isn't ideal since it breaks per-project .claude/ config pickup. Claude would then be rooted at some arbitrary parent folder instead of the actual project you're working in.

The real fix should be: Claude Code detects which folder the currently active file belongs to and starts there, respecting that project's own .claude/ files. That's the behavior that would actually make multi-root workspaces work properly for everyone.