[BUG] Windows desktop client file browser does not display symlinks over SSH

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?

## Summary

The Claude Code Windows desktop client's file browser/tree view does not display symbolic links when connected to a remote Linux host via SSH. Only real directories and files are shown — symlinks are completely
invisible, making it impossible to navigate to symlinked project directories through the UI.

## Environment

• Client: Claude Code Windows desktop app
• Remote host: Ubuntu Linux (SSH as non-root user)
• Filesystem: /opt/ contains ~50 symlinks and 2 real directories

## Reproduction Steps

1. SSH into a Linux host from the Claude Code Windows desktop client
2. Navigate to a directory that contains symlinks (e.g. /opt/)
3. Observe the file browser/tree view

## Actual Behavior

Only 2 entries shown in the file browser: folder1/ and folder2/ (the only real directories). All ~50 symlinks are completely hidden.

## Expected Behavior

Symlinks should be displayed in the file browser, ideally with a visual indicator (e.g. arrow icon or italic text) distinguishing them from real directories/files. Clicking a symlink should navigate to its
target.

## Notes

• The CLI tools (Bash ls -la, Read, etc.) all correctly see and follow the symlinks — this is purely a file browser UI issue
• The symlinks are valid and resolvable (confirmed via readlink -f and stat)
• All symlinks are owned by root, permissions 0777 (lrwxrwxrwx) — this is not a permission issue
• Related: #16507 (Glob tool doesn't follow symlinks) — may share a root cause if the file browser uses Glob internally
• Related: #24964 (Cowork folder picker rejects symlinks/junctions on Windows)

## Impact

On this system, symlinks are the primary organizational mechanism — nearly every project directory under /opt/ is a symlink into /opt/folder1/. The file browser being blind to symlinks makes it essentially
non-functional for project navigation.

What Should Happen?

Symlinks should be displayed in the file browser tree view, just like regular directories and files. Clicking a symlink to a directory should navigate into its target contents. Ideally symlinks would have a visual indicator (such as an arrow icon or suffix) to distinguish them from real directories, but at minimum they must be visible and navigable.

Error Messages/Logs

No error messages. The symlinks are silently omitted from the file browser — there is no warning or indication that entries are being filtered out.

Steps to Reproduce

● 1. On a Linux host, create a directory with symlinks:
mkdir -p /tmp/real-dir
echo "hello" > /tmp/real-dir/test.txt
mkdir -p /tmp/test-browse
mkdir /tmp/test-browse/real-folder
ln -s /tmp/real-dir /tmp/test-browse/symlinked-folder
▒ Claude Code

1. From the Claude Code Windows desktop client, connect to the Linux host via SSH

1. Open the file browser and navigate to /tmp/test-browse/

1. Observe: only "real-folder" appears. "symlinked-folder" is missing entirely.

1. Confirm the symlink is valid from the terminal:

ls -la /tmp/test-browse/
# Shows both real-folder/ and symlinked-folder -> /tmp/real-dir

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.1.4498 (24f768)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

● In my case, /opt/ contains ~50 symlinks and only 2 real directories. The file browser shows only the 2 real directories, making it essentially non-functional for navigation. The CLI tools (Read, Bash ls, etc.)
all follow symlinks correctly — this is isolated to the file browser UI.

Possibly related issues:

• #16507 — Glob tool does not follow symlinks (may share root cause if file browser uses Glob internally)
• #24964 — Cowork folder picker rejects symlinks/junctions on Windows
• #25317 — eGrep tool missing --follow flag for symlinks