Desktop app: file links in replies break silently on moved files, absolute paths, and spaces
Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 0 comments · opened Sep 16, 2026
Surface: Claude Code desktop app (macOS), Code tab.
Problem: The app renders markdown links like [label](relative/path.md) or [label](path.md:42) as clickable file links resolved against the session working directory. The link is rendered without any check that the target exists, so it fails silently in three common cases:
- The file is moved or renamed by a parallel session between the reply being written and the user clicking. Example: a reply linked
docs/research/2026-09-15-quarterly-notes.mdwhile another session moved it todocs/notes/Quarterly notes.md. - The model emits an absolute path or a path outside the working directory.
- The path contains an unencoded space.
Clicking does nothing useful and there is no error, so the user cannot tell whether the file is gone, the path is wrong, or the click failed.
Requested:
- Validate link targets at render time (or on click) and show a visible state for missing files, ideally with a same-basename suggestion when the file was moved.
- Resolve absolute paths under the cwd, and percent-decode targets so spaces work.
- Optionally expose the resolved path on hover.
Workaround: I wrote a Stop hook that blocks the turn when the final message has a broken link. It would be better handled in the app.