Windows paths printed outside code blocks lose backslashes (`\_` eaten as a markdown escape)

What happens

Claude's replies are rendered as GitHub-flavored markdown. A Windows path printed as plain
text loses every backslash that precedes a markdown-escapable character. \_ is the common
case, because leading-underscore directory names are normal on Windows.

Claude prints:

D:\proj\data\_scratch\out\A0_raw_leveled.wav

The user sees:

D:\proj\data_scratch\out\A0_raw_leveled.wav

The \ before _scratch is gone. The path does not exist and does not open. Nothing warns
either side — Claude believes it printed a valid path, the user gets a dead one.

Same class of breakage for \*, \#, \[, \(, \. — any \ + punctuation pair.

Why it matters

• Silent corruption. There is no error, and the path looks almost right, so it reads as a

Claude mistake rather than a rendering one.

• It hits every session on Windows that names a file outside a code block, which is the

normal way to hand a result to the user.

• It survived a whole working session here: every path given to the user was unusable, and

the user only caught it when pasting one back.

Reproduce

1. Run Claude Code on Windows.
2. Ask it to print a path containing a directory that starts with an underscore, outside a

code fence and outside backticks, e.g. D:\proj\data\_scratch\file.wav.

1. The rendered output drops the backslash before _scratch.

Expected

Paths printed as plain text should survive rendering verbatim. Either the renderer should not
treat \ + punctuation as an escape in text that is a filesystem path, or the CLI should
escape backslashes before rendering.

Workaround

Wrap paths in backticks. This is only a workaround: it requires Claude to remember it on every
single path, and any user instruction asking for bare, unformatted paths conflicts with it.

Environment

• Claude Code in the VSCode extension, Windows 11 Pro 10.0.26200
• Model: Opus 5