[Bug] Bash tool silently strips backslashes on Windows/Git Bash

Still reproduces on 2.1.245, which postdates both this report (2.1.243) and #88561 (2.1.224). Independently measured today on Windows 11 26200 / Git Bash 5.3.15 (MINGW64), defaultMode: "auto".

Same signature, confirmed by byte count rather than by eye:

| typed | arrives at bash |
| --- | --- |
| a\b | a\b |
| a\t | a\t (not a tab — so not a JSON decode) |
| a\\b | a\b |
| a\\\\b | a\\b |
| 8 backslashes | 4 |

Tool-by-tool fidelity, same machine, same session:

| tool | faithful? |
| --- | --- |
| Bash | no — halves every \\ pair |
| PowerShell | yes (1→1, 2→2, 4→4) |
| Write | yes |

One thing worth adding for anyone triaging by severity: the auto-mode interaction in this report's Impact section is not a corner case, it is the main way people meet this bug. Auto mode's standing instruction is to prefer sed/heredocs/short scripts over Read/Edit/Write, so on Windows every routine file write is routed through the one transport that corrupts backslashes. A user with defaultMode: "auto" hits this several times a session and reads it as "heredocs are broken"; a user without it may never hit it at all. That difference in exposure is probably why a Windows-wide transport bug has taken this long to get two reports.

The practical consequence is that the documented workaround — double every backslash — does not survive contact with a long session. It asks the model to keep an escaping rule in its head across every subsequent command, while the surrounding system prompt is actively steering it toward the defective tool. Mitigation that holds is structural: use Write for backslash-bearing content, or forward slashes, or a script file. Counting is not a fix, it is a rule waiting to be forgotten.

Confirming this on a different Windows setup, with two measurements I haven't seen in this
thread or the related ones.

Environment: claude.exe 2.1.247, entrypoint claude-desktop, Git Bash 5.2.37(1)
(MINGW64), Windows 11. Note that 5.2.37 is older than the 5.3.x reported here and in
#88561, and the behaviour is identical, so the Git Bash version looks irrelevant.

1. A PreToolUse hook receives the command verbatim

Registering a PreToolUse hook on Bash that just logs tool_input.command, then running:

printf '[%s]' '\' '\\' '\\\\' '\\\\\\\\' '\n' '\\n' 'C:\Users\me'

The hook logs that command with every backslash intact. What bash actually prints is:

[\][\][\\][\\\\][\n][\n][C:\Users\me]

So the loss happens strictly after hook dispatch and before the bash process starts. That
rules out the model output, the transcript, and the hook layer itself. This corroborates
@emel-purely's measurement in #85856 from an independent environment.

2. In the same wrapper string, quote-escaping is correct while backslash-escaping is not

Reading the real argv from inside the command:

printf 'RESULT=[%s]' '\\'; tr '\0' '\n' < /proc/$$/cmdline | tail -1

prints RESULT=[\], and the wrapper argv comes back as:

... && eval 'printf '"'"'RESULT=[%s]'"'"' '"'"'\'"'"'; ...' && pwd -P >| ...

Two things are true of that single string at the same time:

• every ' in my command was escaped correctly, to '"'"'
• my \\ had already been reduced to \

I think this is difficult to reconcile with the MSVCRT-vs-MSYS2 receiver theory in #85856.
A decoding mismatch on the receiving side would not be selective about which characters it
mangles, and in particular would not leave the single-quote escaping intact while dropping
backslashes. It looks more like a quoting routine inside claude.exe that handles quote
characters but not backslashes, running upstream of process spawn.

Workaround, for anyone blocked

The transform is exact and invertible: even-length backslash runs are halved, a lone
backslash survives. Since the command is still intact at the hook boundary, a PreToolUse
hook can pre-double the backslashes so the two cancel:

# PreToolUse, matcher: Bash
payload = json.load(sys.stdin)
cmd = payload.get("tool_input", {}).get("command", "")
if payload.get("tool_name") == "Bash" and chr(92) in cmd:
    print(json.dumps({"hookSpecificOutput": {
        "hookEventName": "PreToolUse",
        "updatedInput": {"command": cmd.replace(chr(92), chr(92) * 2)},
    }}))

With that in place, heredocs, sed -i 's/x/A\\nB/', awk '/\\/' and Windows paths all
behave as written. It is a workaround rather than a fix, and it has to be removed once this
is corrected upstream, or it will double backslashes that are no longer being halved.

Separate but adjacent defect

The same command-building path also corrupts non-ASCII. A single em dash (UTF-8 E2 80 94)
arrives at bash as C3 A2 E2 82 AC E2 80 9D, i.e. the UTF-8 bytes decoded as cp1252 and
re-encoded. Reproduce with printf '%s' 'X' | od -c substituting any non-ASCII character
for X. Happy to open that as its own issue if it isn't already tracked.

Same defect on Claude Code 2.1.233, Windows 11 Pro 26200, Git Bash (MSYS2 runtime), defaultMode: "auto". Two measurements that I think reconcile the argv findings above with the MSYS2 theory in #85856, plus a scale figure.

1. An MSYS2 runtime knob changes the outcome, so the halving happens in the MSYS2 command-line-to-argv step. The harness launches bash.exe -c "<preamble> && eval '<command>'": the whole script is ONE double-quoted element of the Windows command line. The MSYS2 (Cygwin) runtime rebuilds argv from that command line before bash's main() runs. Measured here, inside a double-quoted segment that step rewrites \\ to \ and \" to " and leaves every other backslash alone, which is exactly the signature in this thread (\t, \d, lone \ untouched). It is selective by design, and that is why the '"'"' quote-escaping survives while \\ does not: two different layers do those two things.

Receipt: with MSYS=noglob in the environment the halving stops, and the \" handling stops with it, so any command containing a double quote dies before it runs:

printf '%s\n' 'M\\N' | od -c     # MSYS=noglob: M \ \ N   (halving gone)
echo "x"                          # MSYS=noglob: unexpected EOF while looking for matching `"'

A receiver-side knob would not move a defect that lived in claude.exe's own quoting routine. So MSYS=noglob is not a workaround, but it does locate the bug.

2. Scale. Transcript telemetry across two Windows machines, 7 days to 2026-09-09: 433 Bash tool calls contained \\, and every one of them reached bash with a backslash removed. Typical silent outcomes: Python source written through a heredoc landed with a real tab where "\\t" was intended, and Windows paths lost half their separators.

Fix suggestion. Keep the script out of the Windows command line: write it to a temp file and run bash <file>, or feed it on stdin with bash -s. Either sidesteps the MSYS2 argv step entirely, and also removes the 8,191-character command-line cap that the eval '...' wrapper hits today. The pre-doubling hook above works, but it has to track the launch shape and it counts double against that cap.

Our own mitigation until then is a PreToolUse hook that rejects any Windows Bash call containing \\ and points the model at Write/Edit or the PowerShell tool, both of which pass backslashes intact.