[BUG] Windows: the Bash tool halves every pair of backslashes before bash reads the command

Status Open
Reported on v2.1.281
Maintainer reply None cached
Activity 1 comment · opened Sep 26, 2026

Environment

  • Claude Code 2.1.281 (desktop app, Code tab) — also reproduced with the CLI 2.1.162
  • Windows 11 (10.0.26200), Git for Windows 2.54.0 (MSYS 3.6.7, GNU bash 5.3.9)

Summary

On Windows, any run of n consecutive backslashes in a command sent through the Bash tool reaches bash as ⌈n/2⌉ backslashes. This happens before bash parses the command: it affects text inside single quotes and quoted heredocs, where bash itself never touches backslashes. The PowerShell tool is not affected.

The command that runs is therefore not the command that was written, silently.

Reproduction

Ask Claude to run, through the Bash tool:

printf '%s' '1[\] 2[\\] 3[\\\] 4[\\\\]' | od -c

Expected (single quotes, bash leaves backslashes alone): 1[\] 2[\\] 3[\\\] 4[\\\\]
Actual: 1[\] 2[\] 3[\\] 4[\\] — each pair collapses to one; a lone backslash is kept.

A lone backslash before other characters is preserved: \$, ` \ `, \", \n, \t` all arrive intact. Only pairs are affected.

The same probe through the PowerShell tool ([IO.File]::WriteAllText(..., '2[\\]')) keeps 2[\\].

Impact

Any script passed inline loses escapes. For example, a Python heredoc written with "\\n" (a literal backslash-n) receives "\n", a real newline. This produced SyntaxError: unterminated string literal, silently altered regexes, and a test file written with real newlines inside string literals. Because the heredoc delimiter was quoted, the natural (wrong) conclusion was that "heredocs eat backslashes".

What was observed

Process creation (WMI) shows the Bash tool wrapping each command as:

"C:\Program Files\Git\bin\bash.exe" -c "source <snapshot> ... && eval '<command>'"

(the Git for Windows launcher, which re-execs usr\bin\bash.exe). The exact layer that halves the backslashes — the construction of this command line, or its parsing by the MSYS runtime — was not isolated. Hook commands run through the same launcher but receive the command in their JSON payload before the halving: a PreToolUse hook sees the original \\.

Workaround in use

A PreToolUse hook on the Bash tool that denies commands containing two consecutive backslashes (Windows only), pointing to the Write/Edit tools or the PowerShell tool instead.

View original on GitHub ↗

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