Desktop app: file links outside the working directory render clickable but dead-end in 'Couldn't find this file'
Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 3 comments · opened Sep 16, 2026
Environment
- Claude Code 2.1.221, desktop app (macOS), Code tab
- macOS 26.6.2
Bug
In the desktop app, when the assistant renders a markdown file link whose path resolves outside the session's working directory, the link is displayed as clickable, but clicking it opens a dead-end dialog: "Couldn't find this file. It may have been deleted, or it lives outside the working directory." The file exists on disk; the dialog's "Show in Finder" button locates it fine.
Repro
- Open a desktop app session with working directory
~/proj/repo-a, where a sibling~/proj/repo-b/src/agent.tsexists (multi-repo workspace, per-repo sessions). - Have the assistant reference that sibling file as a markdown link, e.g.
[agent.ts](../repo-b/src/agent.ts). - The link renders as clickable; clicking it shows the "Couldn't find this file" dialog instead of the file.
Expected
Either of:
- Links that resolve outside the working directory are rendered as plain text (not clickable), since the viewer will refuse them anyway; or
- The viewer opens such files read-only when they exist (useful for multi-repo projects where sibling repos are part of one change).
The current combination (clickable link + refusal dialog whose first suggestion is "it may have been deleted") reads as a broken link/bug to the user even though both the model's path and the viewer's scoping are individually behaving as intended.
3 Comments
Confirming this also reproduces on Windows (Claude Code desktop app, Windows 11 Pro 10.0.26200) — not macOS-specific. Same symptom: a markdown link to a file outside the session's working directory renders as clickable, but clicking it shows "Couldn't find this file. It may have been deleted, or it lives outside the working directory." even though the file exists (confirmed independently with
Test-Path). Backslash-style absolute Windows paths trigger it the same way as the relative../case described above.This also affects me. I was working with a session whose working directory was one project, while also editing files in a sibling project directory (not nested inside it). File links to that second project (both relative
../paths and absolute paths) showed up in chat but couldn't be opened — same "couldn't find this file" behavior described above.Environment: Claude Code desktop app, macOS.
Same issue here, reached through a different entry point: a file the assistant sent with the file-card tool, not only a markdown link.
~/Claude Code.mddeliverable to~/Downloads/and sent it as a file cardls)~/Downloadsas an additional working directory mid-session fixes it, but the user has no way to know that from the dialogRequesting the second option above: open existing files read-only regardless of location. The Codex desktop app opens local files from any folder, so users read this as Claude being unable to open files. At minimum, the dialog should offer "Add this folder to the session" rather than suggesting the file was deleted.