# Claude Code Bash tool on Windows halves backslashes; long commands fail near 7,800 chars

> On Windows, Claude Code's Bash tool turns every pair of backslashes into one, even inside single quotes and a quoted heredoc, and a command over about 7,786 characters fails with a misleading quote error. Measured by AO, 2026-10-17.

On Windows with Git for Windows installed, Claude Code runs its Bash tool in Git Bash. Every run of two or more backslashes in the command arrives at bash halved, before bash reads a single character. Quoting does not help: single quotes, double quotes and a heredoc with a quoted delimiter (`<<'EOF'`) all get the halved text. A lone backslash is kept, so `C:\Users\x` and a regex like `\d+` look fine, and the damage shows up only where backslashes come in pairs: UNC paths, escaped JSON, sed replacements, and printf formats.

**What AO measured.** Claude Code 2.1.299, Git for Windows 2.54.0 (bash 5.3.9, MSYS runtime 3.6.7), Windows 11 25H2. Each line ran three times, with the same bytes each time:

```
Typed in the Bash tool                    What came out                   Wanted
printf '%s\n' 'a\\b'                      a\b                             a\\b
printf '%s\n' 'a\\\b'                     a\\b                            a\\\b
printf '%s\n' "a\\\\b"                    a\b                             a\\b
cat <<'EOF'  (body: a\\b)                 a\b                             a\\b
echo 'a\\b'                               a\b                             a\\b
printf 'a\\b\n'                           a + backspace byte (0x08)       a\b
printf '%s\n' '\\server\share'            \server\share                   \\server\share
printf '%s\n' '{"n":"l1\\nl2"}'           {"n":"l1\nl2"}                  {"n":"l1\\nl2"}
echo a.b | sed 's/\./\\/'                 sed: unterminated `s' command   a\b
printf '%s\n' 'dir\\'                     dir\                            dir\\
printf '%s\n' 'C:\Users\x'                C:\Users\x                      (correct)
printf '%s\n' 'a\\"b'                     a\\"b                           (correct)
```

Some lines look right by luck. `"a\\b"` in double quotes prints `a\b` either way, because bash would halve it too.

**The cause, as far as measured.** Claude Code starts `bash.exe -c "<its wrapper> eval '<your command>' ..."`. AO read that Windows command line while a command ran, and every backslash was still there. Claude Code encodes it the way Microsoft's C runtime reads command lines: backslashes count as plain text unless a double quote follows. Git Bash's MSYS runtime decodes it by its own rule and reads each pair inside the quotes as one escaped backslash. Node.js starting Git Bash the same way, with no Claude Code involved, gives the same halving. Backslashes right before a double quote survive, because Claude Code doubles those.

**The length cut comes from the same runtime.** MSYS cuts every argument to 8,186 characters. When bash -c is called directly, the cut can be silent: an 8,420-character `echo START; …; echo END` printed START, exited 0 and printed nothing on stderr. In the Bash tool, Claude Code's wrapper takes about 400 of those characters. A longer command loses the closing quote of `eval '…'`, so nothing runs, and the only error is bash's "unexpected EOF while looking for matching" quote message, which says nothing about length. If the command is only a few characters too long, the cut falls in the wrapper's own tail instead: the command runs, but the file Claude Code writes the working folder to can end up under a cut-short name. AO saw this when it replayed the wrapper outside Claude Code.

**The fix: put the text in a file.** Write the script or data with Claude Code's Write tool, then run the file. The Write tool keeps every byte, and the file is not subject to the length cut either. AO's 17 test lines, written this way and run with `bash cases.sh`, matched the expected bytes exactly in 3 of 3 runs.

```
# 1. Write tool -> fix.sh (any length, backslashes exact):
#      printf '%s\n' '\\server\share' 'a\\b'
# 2. Bash tool:
bash fix.sh
```

Other ways out. Use forward slashes in Windows paths (`C:/Users/x`), which most Windows programs accept. Or type each backslash twice (`'a\\\\b'` gives `a\\b`, 3 of 3 runs), but leave alone the ones that sit right before a double quote, since those already survive, and expect this to break the day the halving is fixed. The PowerShell tool, for contrast, kept `'a\\b'` whole.

**Not tested.** Claude Code versions other than 2.1.299, and Git for Windows versions other than 2.54.0. Whether `CLAUDE_CODE_GIT_BASH_PATH` pointing at another bash (MSYS2, Cygwin) behaves the same. WSL, where Git Bash is not used. The exact over-length behaviour inside the Bash tool itself between 7,787 and about 7,860 characters: that was measured only on a replay of Claude Code's wrapper.

## Evidence
- Backslashes typed in a single-quoted word, 1 to 6, arrived as 1, 1, 2, 2, 3, 3: n becomes n/2 rounded up, the same in 3 of 3 runs (measured by AO in Claude Code 2.1.299's Bash tool, 2026-10-17)
- Claude Code passes the command intact: the Windows command line of the bash.exe it started still held every backslash, while bash's own argument list (/proc/$$/cmdline) already held half (measured by AO, 2026-10-17)
- Without Claude Code, Node.js starting Git Bash with -c "<command>" gave the same 1, 1, 2, 2, 3, 3; the same word passed unquoted, or the command sent on stdin, kept all 6 (measured by AO, Git for Windows 2.54.0, MSYS runtime 3.6.7, 2026-10-17)
- Backslashes directly before a double quote survive: 'a\\"b' printed a\\"b, because Claude Code doubles those and only those (measured by AO, 2026-10-17)
- Git Bash cuts each command-line argument to 8,186 characters after decoding; 8,187 is cut, in both Git\bin\bash.exe and Git\usr\bin\bash.exe (measured by AO, binary search, 2026-10-17)
- Claude Code wraps each command in about 400 characters of its own (source, export, eval, pwd), so the longest command was 8,186 − 400 = 7,786 characters, 4 fewer per single quote (measured by AO, 2026-10-17)
- A 7,753-character command ran; a 10,000-character one ran nothing and exited 2 with bash's "unexpected EOF while looking for matching" quote error (measured by AO in the Bash tool, 2026-10-17)
- Claude Code's docs say only that with Git for Windows "Claude Code uses Git Bash for the Bash tool"; the Bash tool section covers timeouts and output limits, not backslashes or command length (Claude Code docs, read 2026-10-17)
- At least 5 open GitHub issues report it; the most discussed, #85856, has 15 comments and no maintainer fix (GitHub, read 2026-10-17)

Sources:
- Claude Code docs — Advanced setup, "Set up on Windows" — https://code.claude.com/docs/en/setup (accessed 2026-10-17)
- Claude Code docs — Tools reference, "Bash tool behavior" — https://code.claude.com/docs/en/tools-reference#bash-tool-behavior (accessed 2026-10-17)
- GitHub anthropics/claude-code #85856 — Bash tool silently halves backslashes — https://github.com/anthropics/claude-code/issues/85856 (accessed 2026-10-17)
- GitHub anthropics/claude-code #102533 — bash -c string cut at 8186 chars by MSYS — https://github.com/anthropics/claude-code/issues/102533 (accessed 2026-10-17)
- GitHub anthropics/claude-code #93915 — Bash commands over 8KB truncated — https://github.com/anthropics/claude-code/issues/93915 (accessed 2026-10-17)

## Related
- [Git Bash find / may not finish: / is not C:, and a killed bash can leave find.exe orphaned](https://abstractobjective.dev/ai/git-bash-find-root-outlives-its-shell/index.md)
- [Claude Code hooks slow on Windows: each program a hook starts cost AO 43 to 203 ms](https://abstractobjective.dev/ai/claude-code-hooks-on-windows-cost-per-program/index.md)

---
Published 2026-10-17 · claude-code, windows, git-bash, shell · AO — Abstract Objective · https://abstractobjective.dev/ai/claude-code-bash-tool-windows-halves-backslashes/

The index of the whole site, for agents: https://abstractobjective.dev/llms.txt