[BUG] VS Code extension ignores CLAUDE_CONFIG_DIR environment variable

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/4739
2. https://github.com/anthropics/claude-code/issues/12719
3. https://github.com/anthropics/claude-code/issues/13840

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is not a duplicate of the listed issues:

#4739 is locked and cannot be commented on
#12719 and #4739 focus specifically on /ide command failure
This issue is broader: the VS Code extension ignores CLAUDE_CONFIG_DIR entirely (auth, config, credentials), not just for IDE detection

The root cause may be related, but the scope and impact are different.

+1, as for me:

Is this a regression?

Yes, I was using this workaround as a bash variable until last month

Root cause analysis (Extension v2.1.70)

I traced the session listing through the minified extension.js and found the exact call chain:

1. listSessions() → oP({dir: this.cwd}) → ve() → es(dir)
2. es() → ps(dir) → path.join(MU(), hashedDir)
3. MU() = path.join(IG(), "projects")
4. IG() = process.env.CLAUDE_CONFIG_DIR ?? path.join(os.homedir(), ".claude")

IG() correctly reads process.env.CLAUDE_CONFIG_DIR — but the extension host process never receives this variable:

• terminal.integrated.env.osx only applies to terminal processes, not the extension host
• claudeCode.claudeProcessWrapper only takes effect when spawning the Claude CLI process, not when the extension itself lists sessions
• claudeCode.environmentVariables also doesn't propagate to the extension host's own process.env

So the Claude process runs correctly with the custom config dir (via the wrapper), but the session picker UI always reads from ~/.claude.

Workaround

Close all VSCode instances, then launch from terminal:

CLAUDE_CONFIG_DIR=~/.claude-work code ~/git/my-project

This way the extension host inherits the variable. Does not work if another VSCode instance is already running (merges into existing instance).

Suggested fix

Add a claudeCode.configDir setting that the extension reads for both spawning the Claude process and its own internal operations (session listing, plans, file history). This would make all existing env-based workarounds unnecessary.

Also affects plugins (installed_plugins.json) — not just VS Code extension.

When using CLAUDE_CONFIG_DIR to separate work vs personal accounts, plugins installed for one account still show up on the other account because ~/.claude/plugins/ is hardcoded.

The /mcp dialog shows them as "needs authentication" on the wrong account — harmless but noisy. There's no per-account plugin scoping.

Related closed issues: #972, #15071

When will this be fixed?

I would also like this to be fixed

Adding my +1 for this. I need to be able to separate my work & personal Claude accounts on the same computer. For now, I'm overriding VS Code startup script to give VS Code a fake home folder when starting up (one for work, one for personal). This works, but it comes with the symptom of having anything external that's executed from VS Code use that fake home folder (ie. opening a browser link is like I'm opening the browser for the first time).

Still not fixed？

EDIT (corrected): the test below verifies only the spawned agent path. The extension host still ignores CLAUDE_CONFIG_DIR on Windows (session list/switch, settings.json, MCP/plugin persistence all default to ~/.claude), so this is not macOS-only or fixed — the host-side half of this issue still reproduces. See my follow-up below and @pasrom's root-cause analysis. Original kept for context.

---

Windows 11: works via the claudeCode.environmentVariables setting (ext 2.1.178)

On Win 11 (extension 2.1.178, CLI 2.1.177) the claudeCode.environmentVariables setting does point the spawned Claude session at a non-default CLAUDE_CONFIG_DIR:

"claudeCode.environmentVariables": [{ "name": "CLAUDE_CONFIG_DIR", "value": "C:\\Users\\<me>\\.claude-alt" }]

To rule out a leaked shell variable, I opened the repo in a throwaway instance (code --new-window --user-data-dir <temp> <repo>) with no CLAUDE_CONFIG_DIR in the environment and a fresh profile; /status then came up under the account in the custom dir, not ~/.claude. The setting was the only possible source.

Since the issue is labeled platform:macos and the report was on 2.1.63, this suggests the bug is macOS-specific and/or was (partly) fixed by 2.1.178 — might be worth a maintainer scoping. (I only verified the setting path, not the shell-export path.)

@kdsrc this only partially works. I am also on Windows 11, though using WSL.

• Switching between sessions does not work, it will show up empty when switching to an older session.
• Plugins and MCPs will not survive the VSCode session, I would need to reinstall every time with a new VScode session.

Correcting my comment above: on Windows 11 (ext 2.1.181) claudeCode.environmentVariables only reaches the spawned Claude CLI, not the extension host. The agent ends up on the right account, but everything the host does - session-history list, settings.json, MCP/plugin install & persistence (.claude.json), file-history, plans - reads process.env.CLAUDE_CONFIG_DIR from the host process, which never receives it and falls back to ~/.claude. That host-side half is the core of this issue, still reproducing on Windows - and it's why older sessions open empty and plugins/MCP don't persist across sessions.

The fix is small, and it's the one already proposed in this thread: a claudeCode.configDir setting the extension reads for both the spawned process and its own host-side operations. Give the host process the right config dir and all of the above bind to the correct account.

I've verified that it works: a small VS Code extension that gives the extension host the correct config dir resolves history, settings and MCP/plugin state, with no change to the agent path. So the host side is genuinely a one-setting fix. Happy to share details if useful - feel free to reach out.