[BUG] Windows: the Bash tool halves every backslash pair in a command before Git Bash parses it (heredocs and single quotes included)

Status Open
Reported on v2.1.286
Maintainer reply None cached
Activity 1 comment · opened Oct 6, 2026

Environment

  • Claude Code 2.1.286, Claude desktop app (Code tab), Windows 11 Enterprise 10.0.26100
  • Bash tool backed by Git for Windows: GNU bash 5.3.15(2)-release, MSYSTEM=MINGW64
  • Primary shell PowerShell 7; the PowerShell tool is NOT affected

What happens

Every pair of backslashes in a Bash tool command arrives in bash as a single backslash. It happens before bash parses the command, so bash quoting cannot protect against it: single quotes and quoted heredoc delimiters (<<'EOF') are affected too. A lone backslash passes through unchanged.

Minimal reproduction

Ask Claude to run this exact command with the Bash tool:

printf '%s|' 'one\x' 'two\\x' 'four\\\\x'; echo; echo 'unc: \\server\share'

Expected output (bash semantics: single quotes are literal):

one\x|two\\x|four\\\\x|
unc: \\server\share

Actual output:

one\x|two\x|four\\x|
unc: \server\share

The same command through the PowerShell tool, Write-Output 'one\x|two\\x|four\\\\x', prints the input unchanged.

A heredoc with a quoted delimiter loses them too:

python - <<'EOF'
s = "X\\\\Y"
print(repr(s), len(s))
EOF

Expected: 'X\\\\Y' 4 (two backslashes). Actual: 'X\\Y' 3 (one). Python received the source text "X\\Y".

Where it seems to come from

The process the tool starts is /usr/bin/bash -c source <snapshot> ... && { ... }, launched from a Windows (non-MSYS) process. The MSYS2 runtime builds argv from the Windows command line with its own quote and backslash rules. Inside a double-quoted argument, those rules turn \\ into \ (and \" into "). Plain bash escapes like echo "q\"q" still work, which suggests the command is escaped for " on the way in but not for \. Escaping backslashes the way MSYS2 parses them (doubling \ inside the quoted -c argument) would fix it.

Impact

  • Silent corruption of any command containing \\. Regexes written into files by patch scripts land under-escaped; for example a JavaScript "\\d" becomes "\d", which is just "d".
  • Corrupted bytes in files: a Python "\\b" becomes a backspace character (0x08) in the generated file.
  • Wrong paths and strings: UNC paths and JSON escapes are altered.

Nothing errors; the command just runs something other than what was written. In our project it caused several silent defects over two weeks before we found the cause.

Workaround we use

A PreToolUse hook on Bash that refuses any command containing a backslash pair. It tells Claude to use 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 ↗