[BUG] Windows desktop app: inline file preview decodes %20 but not %26 in markdown file links (partial percent-decoding)

Status Open
Reported on v2.1.211
Maintainer reply None cached
Activity 0 comments · opened Jul 22, 2026

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:

  1. [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 %26 left literal: docs/a %26 b/notes.md. So the handler decoded %20 and then looked for a directory literally named a %26 b.
  2. [notes](docs/a%20&%20b/notes.md) — spaces as %20, ampersand raw → works, preview opens.
  3. 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 (%20 included). The desktop app evidently has its own handler that decodes %20 only — a different code path with a partial version of the same missing-decodeURIComponent bug.

View original on GitHub ↗