Repository navigation
fix: symlink/junction directories invisible in directory picker and @file #28526
Description
Description
Symlinked directories (Linux ln -s) and Windows junction points (e.g., OneDrive Desktop) are invisible in the directory picker, @file picker, and file listing. Navigating to ~/OneDrive/Desktop/ shows empty contents.
Root Cause
packages/core/src/filesystem.ts:74 — readDirectoryEntries classifies symlinks and junction points as "symlink" because Node's isDirectory() returns false for reparse points. Downstream filters in src/file/index.ts skip type !== "directory", silently losing all symlink entries.
Steps to Reproduce
- On Windows with OneDrive: navigate to ~/OneDrive/Desktop/ in the directory picker → empty
- On Linux: ln -s /mnt/data/Projects ~/Projects, navigate → empty
- @file picker also doesn't show symlinked directories
Proposed Fix
In readDirectoryEntries, when isSymbolicLink() is true, stat() the target. If the target is a directory, return "directory" instead of "symlink". This fixes ALL consumers (picker, @file, File.list, ripgrep indexer) without changing any downstream filters.
Related Issues
- Symlinked directories not visible in project picker (opencode serve) #10365 — Same bug (Linux), auto-closed unfixed
- Does OpenCode not recognize the reference paths of symbolic links? in windows 11 #16342 — Windows symlinks not recognized (open)
- fix(opencode): resolve symlinks to directories in project picker #10366 — PR with fix (auto-closed, unreviewed)
- fix: handle symlink directories in file listing #11351 — PR without linked issue (rejected)
Platform
Windows 11, Linux, macOS (all symlink types)
Terminal
Windows Terminal
Activity
fix(filesystem): resolve symlink/junction targets to directory type i…
github-actions commentedon May 20, 2026
This issue might be a duplicate of existing issues. Please check:
@filepicker (same@filesymptom on Windows)If your issue is distinct or adds new context, please clarify how it differs from the above.
sghng commentedon Jun 4, 2026
Second this. Really looking forward to the fixes getting merged. I can also share my use case: I symlink a dir inside my Obsidian vault into the project repo, i.e.
./notes -> ~/obsidian/projects/my-new-app/, that way the agent works in the codebase natively, while also updating notes in Obsidian vault. This also serves as a memory layer.fix(filesystem): resolve symlink/junction targets to directory type i…
danielxxomg commentedon Jun 4, 2026
@sghng Thanks for sharing the use case. That helps clarify the expected behavior.
This PR fixes the classification issue in
readDirectoryEntries, so symlinks to directories should now show up correctly in the directory picker when browsing from the home directory.That said, symlinks pointing outside the project root, like an external Obsidian vault, are still intentionally blocked by the security check in
entry(). That part is meant to prevent symlink escape issues.Supporting external symlinks safely would probably need a separate discussion, maybe with explicit user consent or a trusted-path mechanism.
danielxxomg commentedon Jun 4, 2026
@sghng Your Obsidian vault use case got me thinking — the classification fix in #28532 makes symlinks visible in the picker, but external symlinks are still blocked by the security check in
entry().I opened #30788 to discuss allowing those external symlinks with explicit user consent, using the existing
external_directorypermission flow instead of adding a separate trust system.So the idea would be to route escaped symlink targets through the same Allow once / Allow always / Reject flow that already exists for external paths.
Would love your input there if you have thoughts on the approach.
fix(filesystem): resolve symlink/junction targets to directory type i…
jianbinJava commentedon Jun 6, 2026
问题仍然没有修复, v1.16.2 版本仍然存在.(Windows 11 环境)
danielxxomg commentedon Jun 6, 2026
The fix for this is in PR #28532 — it's been ready for a while but hasn't been merged yet. It resolves the root cause in
readDirectoryEntriesby stat()-ing the symlink target to detect if it's a directory.There's also a companion PR (#29102) that adds
follow: trueto the file scan, which handles the@filementions case.Both are waiting on maintainer review. Hopefully they land soon — this has been affecting a lot of Windows/OneDrive users.
adamrybak commentedon Jul 7, 2026
any update on this?
BadLemon5267 commentedon Jul 17, 2026
Same as with WSL server projects, there's a symlink (created by ln -s) in ~, but it's invisible.
github-actions commentedon Sep 17, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.