Desktop app file viewer cannot open links to files under additionalDirectories
Summary
In the desktop app (Code tab), markdown file links in assistant output open a viewer pane. The viewer only opens files under the session's primary working directory. Files under a directory added with additionalDirectories (or --add-dir) render as clickable links but the viewer shows "Couldn't read this file. It may be unreadable, or the session's connection may have dropped."
Environment
- Claude Code desktop app, Code tab, Linux host (WSL2), session running in a git worktree as the primary working directory
permissions.additionalDirectoriesset to a second repository on the same machine- Observed 15 Sep 2026
Steps to reproduce
- Start a session with primary directory
/path/repo-aandadditionalDirectories: ["/path/repo-b"]. - Have the assistant emit
[doc](/path/repo-b/docs/some.md)(absolute path). - Click the link.
Expected: the viewer opens /path/repo-b/docs/some.md, since repo-b is a configured working directory the session can read.
Actual: "Couldn't read this file".
Additional observations
- A relative link to a file that exists only in the primary worktree (not in the main checkout) opens fine, so the viewer resolves against the primary working directory, not the repo's main checkout.
- A symlink inside the primary directory pointing into
repo-bis also refused (consistent with the recent symlink-handling hardening). - Sending the same file with the file-sharing tool works, so the session itself can read it.
Request
Let the viewer open files under any configured working directory (additionalDirectories), or document the supported link form for them. Multi-repo setups where one repo holds shared tooling and specs, and the other holds the code, need clickable references across the two.
3 Comments
Same on macOS, Claude Code desktop, Code tab.
~/.claude/settings.jsonhaspermissions.additionalDirectoriescovering two roots, say/opt/notesand/opt/repos, with the session rooted in the first. Tools read and write both fine, but the file viewer shows "Couldn't find this file" for absolute links into the second root until the agent callsrequest_directory, which then prompts. The Changes pane also only shows the primary root's repo. Ask: have the viewer honouradditionalDirectoriesso there is one allow list, not two.+1 for me. There is a manual workaround, but it is a pain to do it in every session. I haven't found a way to make it happen automatically.
Here's how Claude describes the workaround:
Workaround: ask Claude to explicitly request access to the directory, once per session —
e.g. "get access to /path/to/dir". Claude calls its
request_directorytool against thatpath, and links into it become openable for the rest of that session.
Just having the directory listed in
permissions.additionalDirectoriesis not enough, nomatter how long it's been there — links into it still fail until
request_directoryiscalled live, in that session.
+1
Same on macOS (Code tab). permissions.additionalDirectories in the project's .claude/settings.json gives the tools access, but the Files pane still says "not found" for files there.
Workaround: grant the folder through the app's folder-access prompt. Files under it then open, but the prompt only offers "allow once", so it has to be repeated every session. Even with the grant, files under <repo>/.claude/worktrees/... still don't resolve, which blocks viewing Claude Code's own worktrees.
Ideally the Files pane would honour additionalDirectories / --add-dir, or the folder prompt would offer "always allow".