[BUG] Windows desktop app: inline file preview decodes %20 but not %26 in markdown file links (partial percent-decoding)
Summary
In the Windows desktop app, the inline file preview for markdown file links in chat percent-decodes %20 but not %26 (and likely other percent-escapes) before resolving the filesystem path. A relative link to a file whose path contains both spaces and an ampersand only previews if the spaces are encoded as %20 while the & is left raw — which is the opposite of standard URL encoding, where encodeURI/encodeURIComponent would produce %26.
Environment
- Claude Code desktop app on Windows 11 Enterprise (build 26200), CLI reports 2.1.211
- Verified 2026-07-22
- Working directory: a plain local directory (links are relative to it)
Repro
Target file (example): docs/a & b/notes.md (relative to the working directory — path contains a space-surrounded ampersand).
Have Claude emit these links in a chat response, then click each:
[notes](docs/a%20%26%20b/notes.md)— fully percent-encoded, what a standard URL encoder produces → fails. The preview shows "Couldn't read this file — It may have been deleted or moved, or it lives outside the working directory", and the path displayed in that error has the%20s decoded to spaces but the%26left literal:docs/a %26 b/notes.md. So the handler decoded%20and then looked for a directory literally nameda %26 b.[notes](docs/a%20&%20b/notes.md)— spaces as%20, ampersand raw → works, preview opens.- A path with spaces only, e.g.
[plan](docs/sprint%20plan.md)→ works.
Expected
The link handler should run the href through a full percent-decode (decodeURIComponent, with a try/catch for malformed input) before resolving the path, rather than special-casing %20. Any percent-escape a standard encoder emits (%26, %23, %28/%29, non-ASCII UTF-8 sequences, …) should resolve; only %20 appears to today.
Secondary observations (same environment)
- Angle-bracket-wrapped relative links —
[x](<docs/a & b/notes.md>)— render as clickable but silently fail to open the preview (no error state at all). file:///links to local files don't render as clickable links in the desktop app chat.
Related (not duplicates)
- #76328 and #76679 are the VS Code extension analog, but there the extension host decodes nothing (
%20included). The desktop app evidently has its own handler that decodes%20only — a different code path with a partial version of the same missing-decodeURIComponentbug.