claude-code - 💡(How to fix) Fix [BUG] VS Code extension: webview panels (Local Sessions, Account & Usage) don't respect CLAUDE_CONFIG_DIR even though auth/settings/MCP do — partial multi-account support [1 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

The VS Code extension partially honors CLAUDE_CONFIG_DIR for multi-account/profile setups, which is worse than fully ignoring it because it gives the appearance of correct isolation while silently mixing data from different profiles in the UI.

Working correctly when CLAUDE_CONFIG_DIR is set per-project (via claudeCode.environmentVariables in .vscode/settings.json):

• ✅ Authentication (correct account email shown in sign-in panel)
• ✅ settings.json watching (logs confirm the right ~/.claude-<profile>/settings.json path)
• ✅ MCP server configs are profile-isolated
• ✅ CLI subprocess (claude --resume, /usage, etc. invoked from extension's terminal) all use the right profile

Broken when CLAUDE_CONFIG_DIR points at a non-default directory:

• ❌ Local Sessions panel shows "No sessions yet" even though ~/.claude-<profile>/projects/<encoded-cwd>/ contains valid .jsonl files and a populated sessions-index.json. This is true for both migrated sessions and fresh sessions created entirely under the non-default profile.
• ❌ Account & Usage panel displays usage data from the default ~/.claude/ profile regardless of which CLAUDE_CONFIG_DIR the project is configured for. Running /usage directly in the extension's CLI terminal returns the correct per-profile numbers, confirming this is a UI/webview bug, not an auth or API bug.

The pattern is consistent: backend functionality (auth, settings, MCP, spawned CLI) handles CLAUDE_CONFIG_DIR correctly; webview panels fetch and cache from a path or source that ignores it.

What Should Happen?

When CLAUDE_CONFIG_DIR is set (via claudeCode.environmentVariables or otherwise), all extension UI surfaces - including Local Sessions and Account & Usage - should read from that directory and that directory's authenticated account.

Error Messages/Logs

Extension log confirms `CLAUDE_CONFIG_DIR` is being respected for settings.json:

[DEBUG] Watching for changes in setting files C:\Users\<user>\.claude-other\settings.json, ...


The webview issues a `list_sessions_request`, but the response (whatever path it queries) is opaque at debug level:

[info] Received message from webview: {"type":"request","requestId":"...","request":{"type":"list_sessions_request"}}


No subsequent log line indicates which directory was scanned, what was returned, or whether a cache was hit.

Steps to Reproduce

1. Default profile already authenticated at ~/.claude/. Have some Claude Code session history in a workspace ~/foo/.
2. Create a second profile:

   mkdir ~/.claude-other
   CLAUDE_CONFIG_DIR=~/.claude-other claude
   /login    # authenticate with a different account

1. In ~/foo/.vscode/settings.json set:

   {
     "claudeCode.environmentVariables": [
       { "name": "CLAUDE_CONFIG_DIR", "value": "/absolute/path/to/.claude-other" }
     ]
   }

1. Reopen ~/foo/ in VS Code, open the Claude Code panel.

Observed:

• Auth panel correctly shows the second account
• Extension log confirms: Watching for changes in setting files /home/user/.claude-other/settings.json, ...
• Local Sessions panel: "No sessions yet" — but ~/.claude-other/projects/<encoded-cwd>/*.jsonl exist and claude --resume from the extension's terminal lists and resumes them fine
• Account & Usage panel: shows usage numbers from the default ~/.claude/ account, not the second account
• /usage typed into the extension's terminal: shows correct second-account numbers

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.126

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related issues:

• #24963 — feature request asking for CLAUDE_CONFIG_DIR support to be added (this report supplements it: support is partially already there)
• #28585 — closed as duplicate; describes the same multi-account scenario but doesn't establish that CLAUDE_CONFIG_DIR works for some surfaces and not others
• #44687 — multi-account feature request; calls CLAUDE_CONFIG_DIR a "partial workaround" without identifying which parts work vs which don't
• #38973 — closely-matching symptom ("No sessions yet" in sidebar) for post-update sessions, but a different root cause (version filtering, not config-dir handling)