[BUG] Windows Bash tool halves runs of backslashes even inside single quotes / quoted heredocs

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, the Bash tool (Git Bash) halves every run of two or more backslashes in the command before bash sees it — regardless of shell quoting. Single quotes and quoted heredocs (<<'EOF') do not protect them.

This silently breaks regexes and string literals in inline scripts (e.g. node -e, heredoc-fed scripts): \\ becomes \, and \\b becomes \b, which a JS string literal then turns into a backspace control character.

Observed counts (backslashes written → backslashes received by bash):

| written | received |
|---|---|
| \ | \ (1) |
| \\ | \ (1) |
| \\\ | \\ (2) |
| \\\\ | \\ (2) |
| \\" | \\" (preserved, only directly before ") |

Same result for <<'EOF', <<EOF, <<"EOF", node -e '...', node -e "...", and inside subagents. Not affected: the Write tool (file contents are exact), a script written with Write and then run with bash file.sh, and the PowerShell tool.

Where it breaks

The Windows process command line of the spawned bash still has the correct count, but bash's own argv does not:

• Win32_Process.CommandLine of the bash process contains 'P\\Q' and "R\\\\S" as sent.
• /proc/$$/cmdline inside that bash shows P\Q and R\\S.

So the loss happens when the Cygwin/MSYS runtime parses the Windows command line. The -c argument is quoted with MSVCRT rules (backslashes doubled only before "), but the Cygwin runtime collapses \\ → \ everywhere inside a double-quoted argument. (This is inferred from the observations above; I did not check the runtime source.)

A likely fix is to avoid passing the script through the Windows command line (e.g. feed it via stdin or a temp file), or to escape backslashes according to the Cygwin parsing rules.

What Should Happen?

The command should reach bash byte-for-byte, so that shell quoting rules alone decide how backslashes are interpreted. printf '%s' '\\' | wc -c should print 2.

Error Messages/Logs

$ printf '%s' '\\' | wc -c
1

Steps to Reproduce

1. On Windows, use Claude Code with the Bash tool (Git Bash).
2. Ask Claude to run exactly: printf '%s' '\\' | wc -c
3. Output is 1 (expected 2).

Quoted heredoc variant:

cat > t.txt <<'EOF'
A \\ B
EOF
od -c t.txt

od shows a single backslash between A and B.

To see where it is lost, run from the Bash tool:

cat /proc/$$/cmdline | tr '\0' '\n' | grep -a MARK; : MARK 'P\\Q'

and compare with the bash process's CommandLine from Get-CimInstance Win32_Process.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.285 (Claude Code), Claude desktop app (Code tab)

Platform

Anthropic API

Operating System

Windows 10 Pro 10.0.19045

Terminal/Shell

Bash tool: GNU bash 5.3.9(1)-release (x86_64-pc-cygwin), Git Bash

Additional Information

Workaround: write scripts containing backslashes to a file with the Write tool and execute the file, or use the PowerShell tool. Doubling backslashes manually is fragile because it breaks once this is fixed.