[BUG] Local command output rendered as Markdown: \_ in Windows paths collapses, /export shows a wrong path

Status Open
Reported on v2.1.234
Maintainer reply None cached
Activity 1 comment · opened Aug 18, 2026

Environment

  • Claude Code 2.1.234, terminal UI
  • Windows 11 Pro (10.0.26200)

Bug

Output of local commands (e.g. /export) is rendered as Markdown, so backslash-escape sequences inside Windows paths are swallowed. A path segment separator \ followed by a directory name starting with an ASCII punctuation character that Markdown escapes (most commonly _) disappears from the displayed path.

Repro

  1. Work in a project whose absolute path contains underscore-prefixed directories, e.g. the export target resolves to D:\foo\_bar\_baz\out.txt (note: _bar, _baz are directories).
  2. Run /export <relative path into that tree>.

Displayed result line:

⎿  Conversation exported to: D:\foo_bar_baz\out.txt

Each \_ was interpreted as a Markdown escaped underscore, so the separators vanish and the path collapses into one non-existent directory name.

Expected

The literal path: D:\foo\_bar\_baz\out.txt.

Impact

The status line is misleading: the file lands in the right place, but the displayed path points somewhere that does not exist, so the user cannot tell where the export went, and copy-pasting the displayed path fails. Any Markdown-escapable punctuation at the start of a Windows path segment triggers it (\_, \-, \., \#, \+, \(, ...), \_ being the common real-world case.

Suggested fix

Render local-command result output (or at least detected file paths) as literal text/inline code instead of raw Markdown, or Markdown-escape the string before rendering.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗