[BUG] /ide rejects valid JetBrains lockfile from WSL2 - "ps -p" can't see Windows PID, falsely treats live IDE as orphaned

[structured-clarity]

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?

/ide fails to connect to a JetBrains IDE (Rider) when Claude Code is run from inside a WSL2 distro (from Rider's terminal), even though the IDE's lockfile contains the correct, matching workspace path. The failure is not a path-format mismatch - verified directly, see Error Messages/Logs - but appears to be a lockfile liveness-validation bug: when runningInWindows: true, the CLI's process-liveness check likely uses ps -p <pid>, which cannot see a Windows PID from inside WSL2, causing a valid lockfile to be treated as orphaned and rejected.

This is the same underlying mechanism reported in #14421 (closed via stale-bot, never fixed) and is related to but distinct from #62012, which describes a path-normalization bug between /mnt/<drive>/... and <DRIVE>:\... notation in a pure-PowerShell context with no WSL2 process boundary involved. In my case the workspace paths match byte-for-byte (confirmed directly below), ruling out path normalization as the cause here.

What Should Happen?

When validating a lockfile with runningInWindows: true, the CLI should use Windows-appropriate process checking (e.g. tasklist.exe) rather than ps -p, which cannot see Windows PIDs from a WSL2/Linux process. A valid, live IDE connection with a matching workspace path should be detected and connected via /ide, regardless of whether Claude Code itself is running as a native Windows process or inside WSL2.

Error Messages/Logs

Lockfile (`/mnt/c/Users/<user>/.claude/ide/*.lock`), written by the JetBrains Rider plugin:


{"workspaceFolders":["/mnt/d/<project-path>"], ... "runningInWindows":true, ...}


`pwd` from the WSL2 shell where `claude` is run:


/mnt/d/<project-path>


Identical strings — no trailing slash, no case difference. Despite this, `/ide` reports:


Found 1 other running IDE(s). However, their workspace/project directories do not match the current cwd.
   ● JetBrains Rider: /mnt/d/<project-path>

Additional evidence ruling out other causes:

• curl from inside a Docker container (one layer further removed than plain WSL2) to the Windows-host SSE port succeeds and returns an HTTP response, confirming the port is reachable.
• Manually setting CLAUDE_CODE_SSE_PORT and ENABLE_IDE_INTEGRATION=true to the correct port did not resolve the connection.
• The identical lockfile, read by claude running as a native Windows process (plain PowerShell, no WSL2), connects to Rider successfully every time.

Steps to Reproduce

• On Windows, open a project in JetBrains Rider with the Claude Code [Beta] plugin installed and active.
• Confirm the plugin has written a lockfile to %USERPROFILE%\.claude\ide\<pid>.lock, containing "runningInWindows":true and a workspaceFolders entry in /mnt/<drive>/... notation.
• Open a WSL2 terminal (e.g. Ubuntu) in Rider's terminal and cd to the same project directory via its /mnt/<drive>/... path.
• Confirm via pwd that the path matches the lockfile's workspaceFolders entry exactly.
• Run claude, then /ide.
• Observe: the IDE is listed but selecting it is rejected with "workspace/project directories do not match the current cwd," despite the paths being identical.
• For comparison: run claude from a plain Windows PowerShell terminal (not WSL2) in Rider's terminal in the same directory, then /ide — this connects successfully using the same lockfile.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

v2.1.195

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Also reproduced one layer further removed, running claude inside a Docker container launched from WSL2 (container has host.docker.internal networking and a bind-mounted ~/.claude config directory pointing at the same Windows-side config). Same failure mode. Network reachability to the Windows-host SSE port was confirmed working via curl from inside the container, which rules out a firewall/NAT explanation and points specifically at the lockfile validation logic itself, not network-layer access.

Related issues, for context - these are not duplicates of this report:

• Bug: IDE lock file deleted in IntelliJ IDEA integrated WSL terminal #14421 - describes the same ps -p-vs-Windows-PID mechanism in detail (IntelliJ IDEA + WSL2 integrated terminal), including the suggested tasklist.exe fix. Closed by stale-bot without a fix.
• [BUG] JetBrains lockfile with runningInWindows: true and /mnt/<drive>/ path fails cwd match on Windows CLI #62012 - describes a related but distinct path-normalization bug (/mnt/<drive>/... vs <DRIVE>:\...) in a pure-PowerShell context with no WSL2 involved. Worth keeping separate since the root cause and fix differ from this report.

[github-actions]

Found 2 possible duplicate issues:

1. /ide fails on Windows Server 2019 via RDP: process ancestry check breaks IDE connection after extension reload #52858
2. [BUG] Claude Code plugin will not connect to the Windows version of Jetbrains Rider #2273

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

[structured-clarity]

I don't think either of those linked issues describe this exact scenario, nor point at the masked-pid issue being the cause. The gist is being able to run Claude in WSL, or even a container to sandbox it properly, and still talking to Rider/IntelliJ.