[BUG] Desktop app: file tree shows a directory symlink as a file and cannot open files under it (regression)
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?
In the desktop app (Code tab), the project file tree renders a symlink that points to a directory as a plain file: file icon, no disclosure arrow, sorted among the root-level files instead of the folders. Opening a path under it, from the tree or from a file link in the chat, shows the File Pane message "Couldn't find this file. It may have been deleted or moved."
The link sits at the repo root and points outside the repo:
docs -> /Users/<me>/notes/<project>
The target directory and the file both exist. ls -la docs/plan/<name>.md and readlink -f resolve them, and the CLI reads and writes the same files through the link in the same session without any problem. Only the desktop file tree and File Pane refuse it.
The previous desktop build listed this link as a folder and opened files under it. Nothing changed on disk between the two builds.
Related reports:
- #91500 shows the same symptom (a directory symlink treated as a file) in the WSL2 folder picker.
- #90931 was a desktop-only regression where a directory started being opened in a mode that refuses to follow symlinks.
- #91613 documents that the File Pane's containment test is lexical, with roots = cwd + memory paths. If the new tree resolves the link to its real path before that test, a target outside cwd is refused and surfaces as "not found".
What Should Happen?
A symlink that points to a directory is listed as a folder in the file tree, and files under it open in the File Pane, as in the previous desktop build and as the CLI already does.
If the resolved target is outside the allowed roots on purpose, the pane should say that ("outside the workspace") rather than report the file as deleted or moved.
Or the app should ask permit for accessing the symlinked folder and adds it to the trusted workspace folders
Error Messages/Logs
Couldn't find this file
It may have been deleted or moved.
docs/plan/release-notes.md
Steps to Reproduce
- In any git repository, create a directory outside the repository and a symlink to it at the repository root:
``bash``
mkdir -p ~/outside/docs && echo hello > ~/outside/docs/note.md
ln -s ~/outside/docs docs-link
- Open the repository in the desktop app, Code tab, and open the file tree.
- Observe:
docs-linkis drawn with a file icon, no disclosure arrow, sorted with the root-level files. - Click
docs-linkin the tree, or ask the session to mentiondocs-link/note.mdand click the link it renders. - Observe: the File Pane shows "Couldn't find this file. It may have been deleted or moved."
- Compare:
ls -la docs-link/note.mdandreadlink -f docs-link/note.mdin a terminal resolve the file, and the CLI in the same session reads it.
Same result when the link target is elsewhere under the home directory and when the repository is a git worktree.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown exact build. The desktop build in use before the update to 1.46388.4 listed the link as a folder and opened files under it.
Claude Code Version
2.1.261 (Claude Code), desktop app 1.46388.4
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
Environment:
| | |
|---|---|
| Desktop app | 1.46388.4 (Code tab) |
| CLI | 2.1.261 |
| macOS | Darwin 25.6.0 |
| Repository | a git worktree under ~/.worktrees/, the link also fails in the main checkout |
| Link | docs -> /Users/<me>/notes/<project>, gitignored through the global ignore file |
The link target is a notes directory shared between several worktrees of the same repository, so the files under it are the ones the session writes plans and reports to. With the current build there is no way to open any of them from the app.
Screenshot of the tree and the "Couldn't find this file" pane: (attached below)
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗