[BUG] Claude Code VS Code extension on WSL remote doesn't respect local CLAUDE.md / .claude/settings — causes concurrent-session working tree corruption

Preflight Checklist

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

What's Wrong?

When Claude Code runs as a VS Code extension on Windows with the WSL Remote extension, the session does not appear to load repo-level behavioral constraints from the WSL filesystem where the repo actually lives:
CLAUDE.md at repo root (custom rules, restrictions on destructive git operations)
.claude/settings.json local overrides
.claude/skills/ custom skills
This means the VS Code extension session operates with weaker/default constraints than a Claude Code CLI session running inside the same WSL distro on the same repo.The practical consequence is severe when multiple Claude Code sessions coexist on the same working tree (one via CLI in a WSL terminal, one via the VS Code extension on the Windows side): the VS Code session can perform destructive git operations (git reset --hard, git checkout, cherry-pick between branches) that wipe uncommitted work from the CLI session without warning. The CLI session's CLAUDE.md explicitly forbade such operations without user confirmation, but those rules do not apply to the concurrent VS Code session.In my case, ~338 lines of uncommitted in-progress work were wiped during a long-running refactor. Recovery was only possible via git fsck --lost-found finding the auto-stash dangling commit that git creates before destructive checkouts.

What Should Happen?

When the VS Code extension is opened on a folder that lives in a WSL-mounted path, Claude Code should:
Detect the WSL filesystem context and resolve the repo path accordingly
Load CLAUDE.md, .claude/settings.json, and .claude/skills/ from the repo root, just as the CLI does when run inside WSL
Honor all repo-level behavioral rules (no destructive git without confirmation, etc.)
Additionally, and independently of the WSL issue: Claude Code could detect when another Claude Code session is already active on the same working tree (e.g., via a lockfile in .git/ or a well-known socket) and warn the user before performing operations that could affect uncommitted state.

Error Messages/Logs

No error was raised. The destructive sequence appeared in git reflog after the fact:d6f5c476 commit: <unrelated commit from the VS Code extension session>  (23:16:50)
d6f5c476 reset: moving to HEAD                                          (23:17:03)
aa6d7a3d checkout: moving from feat/<my-branch> to main                  (23:17:03)
04fb838a cherry-pick                                                    (23:17:03)The CLI session had uncommitted work on feat/<my-branch>. Git auto-stashed it before the checkout (dangling commit b881cd5f), but the stash was silently dropped by the subsequent operations, leaving no stash list entry. Recovery required git fsck --lost-found + manual cherry-pick of the dangling stash commit.

Steps to Reproduce

Windows 11 with WSL2 (Ubuntu distribution)
Clone a repo into WSL filesystem: git clone <url> /home/<user>/workspace/repo
Create /home/<user>/workspace/repo/CLAUDE.md with explicit rules, e.g.:

# Repo rules

• Never run git reset --hard without explicit user confirmation in the chat
• Never run git checkout that would discard uncommitted changes
• Always commit work-in-progress before switching branches

Terminal A: In a WSL terminal, cd /home/<user>/workspace/repo and start Claude Code CLI. Start a multi-step refactor that accumulates uncommitted changes (edit files, do not commit).
Windows side: Open VS Code. Use the "WSL: Open Folder in WSL" command to open the same repo at /home/<user>/workspace/repo.
In VS Code, launch the Claude Code extension.
Ask the VS Code extension to perform any work on a different branch (e.g., "implement feature X on branch feat/other-thing"). It will typically checkout main, cherry-pick commits, or reset state to complete the work.
Observe:

The VS Code extension does not mention or acknowledge the CLAUDE.md rules
It performs the destructive git operations without asking for confirmation
The CLI session in Terminal A finds its working tree wiped on next file read
The uncommitted work is only recoverable via dangling commit forensics

Minimal reproduction without the second session: step 4-6 are enough to demonstrate that the VS Code extension does not load CLAUDE.md — ask it "what rules are in this repo's CLAUDE.md?" and it will not know, whereas the CLI session in Terminal A answers correctly.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.111 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Why this is high severity:

Silent data loss of uncommitted work, recoverable only via git forensics knowledge most users don't have
Repo-level behavioral constraints (CLAUDE.md) are the primary safety mechanism users configure for high-stakes projects. If they silently don't apply in one interface, users have no way to know their safety net has gaps.
The WSL + VS Code setup is extremely common among developers on Windows

Suggested fixes in order of impact:

Detect WSL-mounted paths in the VS Code extension and load CLAUDE.md / .claude/ from that filesystem (highest impact, fixes root cause)
Add a cross-session lockfile mechanism (e.g., .git/claude-session.lock) so Claude Code sessions can detect each other on the same working tree and at minimum warn before destructive operations
Document the current limitation prominently in VS Code extension docs so users of sophisticated repos (with CLAUDE.md, skills, etc.) know to stick with CLI-in-WSL for now

Workaround I'm using in the meantime:

Single Claude Code interface per repo at a time (CLI-in-WSL only for repos with CLAUDE.md)
Git worktrees to isolate sessions when I need multiple active (git worktree add ../repo-fix feat/branch)
wip(...) commits every 10 minutes during long refactors to minimize exposure

Related observation:
Even without the concurrent session angle, the VS Code extension failing to load WSL-mounted CLAUDE.md is a standalone bug. A session that doesn't know about the user's repo rules can't respect them. This issue would benefit from being split if you prefer — (a) WSL filesystem not read, and (b) cross-session safety on shared working trees — but they share the same root cause of not seeing the repo's true state, so I'm reporting them together.