CLAUDE_CONFIG_DIR not respected by VS Code shell-integration lock files

Resolved 💬 2 comments Opened May 5, 2026 by lezvieaj Closed May 7, 2026

## Environment

  • OS: Windows 11 Pro 26200
  • Shell: PowerShell 5.1 inside VS Code integrated terminal
  • Claude Code: native install (CLI only, no separate IDE extension installed)
  • Config dir override: CLAUDE_CONFIG_DIR=D:\claude (set permanently via user environment variables)

Observed behaviour

CLAUDE_CONFIG_DIR is honoured for almost everything:

  • agents/, agent-memory/, skills/, settings.json, CLAUDE.md, hooks/, templates/, plugins/, projects/, history.jsonl, commands/, tasks/, sessions/, telemetry/ — all live under D:\claude\ and are read/written there correctly.

But the VS Code shell-integration lock files are written to the hardcoded path:

  • %USERPROFILE%\.claude\ide\<port>.lock

even when CLAUDE_CONFIG_DIR=D:\claude is set. Result: D:\claude\ide\ stays empty, while a phantom %USERPROFILE%\.claude\ directory keeps reappearing with a single ide/ subfolder full of stale locks.

Reproduction

  1. Set CLAUDE_CONFIG_DIR to a non-default path on Windows:

``powershell
[Environment]::SetEnvironmentVariable("CLAUDE_CONFIG_DIR", "D:\claude", "User")
``

  1. Restart shell. Confirm with echo $env:CLAUDE_CONFIG_DIRD:\claude.
  2. Delete or rename %USERPROFILE%\.claude\.
  3. Open a new PowerShell terminal inside VS Code (so the CLI auto-detects VS Code shell integration).
  4. Run any Claude Code command (e.g. claude startup, or send a prompt).
  5. Inspect %USERPROFILE%\.claude\ide\ — it contains a freshly-written <port>.lock file.
  6. D:\claude\ide\ remains empty.

Expected behaviour

Lock files for VS Code shell integration should be written to ${CLAUDE_CONFIG_DIR}/ide/ when the variable is set, falling back to %USERPROFILE%\.claude\ide\ only when it isn't.

Workaround

A directory junction makes the hardcoded path resolve to the configured one:

# from any PowerShell (Developer Mode / admin not required for /J)
New-Item -Path "$env:USERPROFILE\.claude" -ItemType Directory -Force | Out-Null
cmd /c "mklink /J $env:USERPROFILE\.claude\ide D:\claude\ide"

After this, locks created at ~/.claude/ide/<port>.lock physically land in D:\claude\ide\<port>.lock. Functional, but a workaround — CLAUDE_CONFIG_DIR should cover this path natively.

Why it matters

Users who keep ~/ on a small SSD and move config to a larger / synced drive (Dropbox, Syncthing, secondary disk) end up with split state: most data on the configured path, but a stray ~/.claude/ subtree with junk locks that they can't clean up because it regenerates. It also makes documentation harder ("set CLAUDE_CONFIG_DIR and you're done" — except for this one path).

Likely fix location

The path is probably hardcoded in the VS Code shell-integration / IDE-detection module. The fix is a one-liner: change Path.home() / ".claude" / "ide" (or similar) to config_dir() / "ide" where config_dir() is the same helper used elsewhere in the codebase.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗