[Bug] Windows: Bash tool silently truncates commands over ~8K chars (each ' counts ~5) and collapses \\ to \ in quoted heredocs
Environment: Claude Code 2.1.286 (also observed on 2.1.227 through 2.1.286), Windows 11, Git Bash
1. Silent truncation of long commands
Commands longer than ~8,000 characters get cut off before bash receives them. Single quotes count about 5 times each, which suggests the command is escaped with single quotes and then hits the Windows command-line limit of 8,191 characters. Depending on where the cut lands, you get:
bash: -c: line N: unexpected EOF while looking for matching 'warning: here-document at line 1 delimited by end-of-file- or no error at all, with the file only partly written.
Across 3,227 heredoc commands in my local transcripts, scoring each command as length + 4 × (number of single quotes) separates the two groups exactly. Every success scored at most 7,834, and every truncation failure scored at least 7,927. All 192 commands longer than 8,000 characters failed.
Minimal repro: run a quoted heredoc (cat > f.txt <<'EOF' … EOF) that writes about 1,800 ' characters, which is only about 1,900 characters of real text. It gets truncated around line 32 of 36.
2. Backslash pairs collapse inside a quoted heredoc
cat > t.txt <<'EOF'
a:\ b:\\ c:\\\
EOFThe file ends up containing a:\ b:\ c:\\. Inside <<'EOF' the expected result is identical text. This silently corrupts regexes, JSON escapes and Windows paths. It also affects node -e '…' scripts that contain regexes with \\.
Impact
Agents and subagents that write files through heredocs, which the auto-mode note encourages, produce truncated or corrupted files. Often there is no error. Subagents can't fall back to Write for report-like files because it is blocked ("Subagents should return findings as text…"), so they have to split the content by hand.
Expected
Commands are passed in full and heredoc content arrives byte-for-byte. If there is a limit, the tool should report an explicit error instead of truncating silently.