[BUG] Claude Code IDE's WSL2 folder picker mis-resolves symlinks that Cursor/VS Code Remote-WSL handle correctly (architecture-specific, not a WSL limitation)

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?

Environment:

Claude Code version: originally found on 2.1.220; confirmed still present on 2.1.258 (current latest as of this report).
OS: WSL2, Red Hat Enterprise Linux 10.2 (Coughlan), kernel 6.18.33.2-microsoft-standard-WSL2
Setup: a symlink under $HOME points into the Windows filesystem mount, e.g. \~/OD -> /mnt/c/OD. All of my GitLab/Cursor project checkouts live under that symlinked path (\~/OD/GitLab/...).
Version update note: Originally reproduced on 2.1.220. Updated to 2.1.258, fully closed and restarted the IDE (see process-cleanup note below), and retested "add as project root" on ~/OD/.... Bug still present on 2.1.258 — the folder picker still treats OD as a file rather than navigating into it. Not fixed by this release.

What I did: Tried to add a folder reached via ~/OD/... (a symlink into the Windows filesystem mount) as a project root in the Claude Code IDE ("add as project root").

Expected: The IDE navigates into the symlinked directory and lets me add the target (or a subfolder of it) as a project root, the same way Cursor does with the identical path.

Actual: This isn't an error dialog — the IDE's folder picker treats OD as if it were an openable file rather than a directory to navigate into, so there's no way to descend into it through the picker. Cursor, given the exact same symlink, navigates into it normally and lets me pick a project root underneath it.

I have a reproduction that points at the likely root cause: accessing the same symlink from the Windows side via the UNC path (\\wsl.localhost\RHEL-10-container\home\user\OD, also reachable via the older \\wsl$\... alias) shows the identical symptom — Windows treats OD as a file, not as a directory to browse into. That UNC path is the Windows-side 9P protocol view of the Linux filesystem, and it's known to mishandle symlinks that point from the Linux side back out to a Windows-mounted path (/mnt/c/...).

To be clear about where I'm putting this bug: this is not a "WSL is quirky, nothing to be done" situation. Cursor, given the identical symlink on the identical machine, navigates into it correctly with no issue — and so does VS Code's Remote-WSL extension, using the same approach. Both of those tools avoid this class of problem entirely by running their WSL folder-browsing logic as a server process natively inside the Linux distro, rather than going through the Windows-side \\wsl$ export. That a competing product built on the same underlying platform (WSL2) does not have this problem is exactly why I'm filing this as a Claude Code IDE architecture issue, not a WSL/Windows limitation to shrug off. My working theory is that Claude Code's IDE folder picker is resolving WSL2 paths through that Windows-side \\wsl$ view instead of the native-in-distro approach the others use — that architectural choice is what needs to change.

Notably, this is IDE-picker-specific — a plain shell handles the same path with no issue:

$ readlink -f ~/OD
/mnt/c/OD
$ ls ~/OD/GitLab/Cursor/Project/Project-Dashboard
... (lists normally)
I also confirmed in a Claude Code terminal session (not the IDE picker) that the Bash tool reads, lists, and greps through files under the symlinked path with no issues — readlink -f, ls -la, find all resolve and traverse it correctly. So the gap is specific to the IDE's "add as project root" folder picker, not to WSL2 filesystem access in general.

Impact: This forced me to move where I store project files for AI-assisted work out of my normal symlinked location, just to work around the picker — a workaround I shouldn't need, given that a competing tool on the exact same machine and the exact same symlink has no issue at all.

Suggested fix direction: Stop resolving WSL2 folder-picker paths through the \\wsl$ UNC/9P view. Run the folder-browsing logic as a server process natively inside the WSL distro instead — the model Cursor and VS Code's Remote-WSL extension already use, which is why they don't hit this. This is a fixable architecture choice in Claude Code IDE, demonstrated by the fact that other tools on identical WSL2 setups don't have the problem.

What Should Happen?

Expected: The IDE navigates into the symlinked directory and lets me add the target (or a subfolder of it) as a project root, the same way Cursor does with the identical path.

Error Messages/Logs

There are no errors, just the Windows 11 "Pick an application to open this file" dialog box.

Steps to Reproduce

Create a Linux symbolic link within a user home directory (it does not need to point to the Windows file system as in this example). Then try to open a project folder from within the Claude Code IDE.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.258

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_