Bash tool silently collapses `\\` to `\` in command text, corrupting regex and paths

Confirming on a second shell: this reproduces identically under MSYS2 bash, so it is not specific to Git for Windows. Claude Code 2.1.231, Windows 11 — still present two versions on from the report.

Swapping CLAUDE_CODE_GIT_BASH_PATH between the two shells and running the same probe through the Bash tool gives byte-identical results:

S='a\\\\b'; printf '%s' "$S" | od -c

| shell | uname | bytes received |
| --- | --- | --- |
| C:\msys64\usr\bin\bash.exe | MSYS_NT-10.0-26200 | a \ \ b (4 chars) |
| C:\Program Files\Git\bin\bash.exe | MINGW64_NT-10.0-26200 | a \ \ b (4 chars) |

Since single quotes cannot remove a backslash, the collapse has already happened before bash parses anything — consistent with the transport diagnosis above.

Three further data points:

Only the pair collapses. \$, \n and \q all arrive intact — \n stays as backslash-n rather than becoming a newline — which rules out a JSON or C-style unescape as the mechanism.

MCP tool arguments are unaffected. Passing pair:a\\b single:a\nb dollar:\$X as an argument to an MCP tool and reading what the server received gives all four backslashes intact. So it is the Bash tool's command composition specifically, not tool argument transport generally.

The wrapper is visible from inside. BASH_EXECUTION_STRING shows the command is spliced into a larger script before execution:

source <shell-snapshot>.sh 2>/dev/null || true && export TEMP='…' TMP='…' && <command>

so the escaping happens while that string is composed, which matches the observed behaviour being identical across shell binaries.

On the silent-corruption point in the report: a count assertion in front of any replacement turns it from silence into a stop. Every occurrence encountered here failed loudly for that reason alone — assert s.count(old) == 1 before writing.

Data point: the Linux answer to "whether macOS and Linux shells are affected is untested"

Not reproducible on Linux at 2.1.241. Ran your exact probe plus an od -c variant through the Bash tool on Ubuntu (GNU bash, x86_64-pc-linux-gnu):

$ printf '%s\n' 'a\\b'
a\\b

$ printf '%s' 'a\\b' | od -c
0000000   a   \   \   b
0000004

Four characters, both backslashes intact. Your table's collapsing row does not occur here, so on the evidence so far this is a Windows-side transport defect rather than a universal one. macOS is still untested by me.

Independent confirmation of the quoted-heredoc case, and the same negative control for it

A separate reporter on Windows 11 / Git Bash hit this while writing throwaway analysis scripts, and the heredoc body is where it cost the most, because the resulting error accuses the generated file's content at a line nobody wrote:

• a JS regex class authored as /[.*+?^${}()|[\]\\]/g landed on disk as /[.*+?^${}()|[\]\]/g — the class then swallows the / and Node reports SyntaxError: Invalid regular expression: missing /;
• the same body re-authored in Python: .replace('\\','/') landed as .replace('\','/') — SyntaxError: unterminated string literal.

Both misdirect toward rewriting the regex rather than suspecting the write channel, which matches the sed-word-boundary shape in your report: the corrupted form stays plausible, so nothing errors at the layer that did the damage.

The same body through the same tool on the Linux box above round-trips byte-exact:

$ cat > hd-test.txt <<'ZZZ'
double: \\ single: \ regex: /[a-z\\]/g apostrophe: don't backtick: `x`
ZZZ
$ cat hd-test.txt
double: \\ single: \ regex: /[a-z\\]/g apostrophe: don't backtick: `x`

On the workaround list

Worth flagging the cost of workaround 1 (double every literal backslash) for anyone writing it into standing instructions: it is correct only while the transport is broken, and inverts into a doubled-backslash bug the day this is fixed — on a channel that surfaces no version signal either way. Workarounds 2 and 3 (Write tool; put it in a script file and execute that) don't have that property, and we have standardised on those.

Still reproduces at 2.1.250, Windows 11 Home 10.0.26200, Git Bash — five versions on from the report.

printf '%s' 'A\\bB' | od -An -c     ->   A \ b B     (expected: A \ \ b B)

The PowerShell tool, same machine and same literal, is unaffected (len=5, bytes 65,92,92,66... i.e. both backslashes intact), which matches your isolation of the transport layer.

A failure mode not yet in this thread: string literals in interpreted languages

The report covers regex and paths. It also corrupts string literals, and there the mangled result is not merely a different-but-valid pattern — it is a control character.

A heredoc'd Python line:

needle = "\\begin{thebibliography}"

arrives at Python as "\begin{thebibliography}", which Python then parses as an escape sequence. The variable ends up holding a literal 0x08 backspace:

len(needle)= 22
'\x08egin{thebibliography}'
found: False

So a substring test against a LaTeX file returned False instead of erroring, and an edit script reported "anchor not found" against a file that plainly contained the anchor. Silent, and it looks like a logic bug in the script rather than a transport defect — I spent two failed tool calls and a wrong diagnosis ("quoted heredocs strip backslashes") before the \\-specific mapping in this issue explained it.

Worth noting for anyone landing here from a mangled-escape symptom: the collapsing is invisible in the tool's own echo of the command, so the first suspicion always falls on the script.

Workaround

Beyond writing the file to disk and executing it, raw strings survive intact, because single backslashes pass through untouched:

r"\begin{thebibliography}"     # correct
chr(92) + "begin{thebibliography}"   # also correct, if raw strings are awkward

That avoids the write-to-disk detour for the common case of embedding LaTeX, Windows paths, or regex in a heredoc'd script.