[BUG] Bash tool silently truncates commands over ~8 KB and reports it as a quoting error

A failure shape past the threshold that does NOT abort: truncated body, redirect RUNS, exit 0

Your report says "Nothing in the command runs," and that matches the shape we see most often. But a second shape exists past the same threshold, and it is the expensive one because it produces no failure at all. Two measured occurrences in one session (Windows 11 / Git Bash), same call shape, differing only in size:

| body | shell response | file state | exit |
|---|---|---|---|
| ~14.5 KB (179 lines), cat > FILE <<'NOTEBOOK' | `bash: -c: line 159: unexpected EOF while looking for matching ''` | **not created** | 2 |
| ~10.6 KB (~127 lines), cat >> FILE <<'XEOF' | bash: line 265: warning: here-document at line 133 delimited by end-of-file (wanted XEOF')`` | written, silently truncated mid-word | 0 |

A 10-line body through the identical call shape works. In the second row bash reaches end of input with the heredoc still open, treats what it has as the body, and executes the redirect: 58 of ~127 lines landed. That fits your wrapper hypothesis cleanly — where the cut falls decides the shape. Cut inside the wrapper's own quoting and you get the unbalanced-quote abort; cut past the redirect but inside the heredoc body and the command is still syntactically runnable, so it runs on a partial document.

The consequence worth designing around: the truncation eats its own self-check

The command ended …\nXEOF\necho OK; grep -c '' FILE. Because the heredoc never terminated, those verification lines were consumed as body. So the self-check never ran, and its absence emitted nothing — the natural defensive idiom (append, then immediately count or tail in the same call) is disarmed by exactly the failure it was written to catch. Combined with exit 0, nothing anywhere in the chain distinguishes this from a complete write except reading the file's tail in a separate call.

The tail is also the worst part to lose: in a report or notebook it is the conclusion and the evidence table, while the intact setup leaves the artifact looking substantial.

Same conclusion as yours on the transport, from a different control

Not the CreateProcess ~32 KB ceiling. A local subprocess.run(["bash","-c",cmd]) on that same machine comfortably passed 30,646-byte commands (requested 600 lines | cmd bytes 30646 | wrote 600) and only died near 40 KB with FileNotFoundError: [WinError 206] The filename or extension is too long. The failures above were at 10–15 KB, well inside that — so the cut is above the shell, consistent with your measurement that the PowerShell and file-write paths carry far larger payloads in the same session.

Supporting your recommendation #1 (reject rather than truncate) specifically because of the exit-0 row: a rejection is recoverable in one turn, whereas a silent partial write is discovered — if ever — hours later by someone re-reading the artifact.

Root cause: the MSYS2 runtime silently truncates the bash -c argument at ~8,186 characters (its glob() pattern buffer), and Claude Code puts the whole wrapped script in that argument

Reproduced today on Windows 11 with Claude Code 2.1.255 (Claude desktop 1.40609) and Git for Windows 2.48.1 (msys-2.0.dll 3.5.7). It is not in Claude Code's wrapper code and not in CreateProcess (a 20,000-char argv reaches a Python child intact). It is Git's bash.exe itself, and it reproduces with plain subprocess and no Claude Code in the loop.

Mechanism. On Windows the Bash tool runs bash.exe -c "<prefix> && eval '<command, apostrophes escaped as '"'"'>' < /dev/null && pwd -P >| <cwd-file>" (buildExecCommand in 2.1.255; the prefix is ~337 chars on my machine: source <snapshot> … && export TEMP=… && shopt -u extglob … && { \builtin unalias -- 'unsetenv'; … }). bash.exe is an MSYS2 program spawned by a non-MSYS parent, so the MSYS2 runtime rebuilds argv from the Windows command line and, unless MSYS=noglob, runs every argument that contains any of ?*["'(){} through globify() → glob(pattern, GLOB_TILDE | GLOB_NOCHECK | GLOB_BRACE | GLOB_QUOTE) (winsup/cygwin/dcrt0.cc). The -c string always contains ' and {, so it always takes that path. glob() copies the pattern into a fixed patbuf (winsup/cygwin/glob.cc):

#undef MAXPATHLEN
#define MAXPATHLEN 8192
…
bufnext = patbuf;
bufend = bufnext + MAXPATHLEN - 1;
…
while (bufend - bufnext >= MB_CUR_MAX) { … *bufnext++ = wc | prot; patnext += clen; }
*bufnext = EOS;

No error, no return code: the copy loop just stops. With GLOB_NOCHECK the truncated pattern is handed back as the argument, and bash receives the first 8,186 characters of its -c string (8,192 minus 1 minus the loop's MB_CUR_MAX headroom, measured exactly: a 8,221-char -c string arrived as 8,186).

What the model sees. Where the cut lands decides the shape. With the harness prefix, the budget for the command itself is about 7,770 characters, minus 4 per apostrophe (each ' becomes '"'"'):

| cut lands … | result |
|---|---|
| inside the command body | the wrapper's closing ' is gone → bash: -c: line N: unexpected EOF while looking for matching '`, where N is the line of the **last apostrophe before the cut** (bash reports the line where the unterminated quote opened). A random apostrophe in the body gets blamed, the model "fixes" quoting, and it fails again. |
| exactly on an apostrophe escape ('"'"') | the outer string ends balanced, so eval **runs the truncated script**: a heredoc loses its terminator (warning: here-document at line … delimited by end-of-file), the partial body is written, the self-check that followed the heredoc is swallowed as body text, exit 0. This is the exit-0 shape @oconnorjoseph measured above. |
| after the closing ', inside && pwd -P >| … | the command runs, then bash executes a mangled tail (/c/Users/user: Is a directory`, exit 1). |

Measured in the harness with 19 calibrated commands (every one printed ${#BASH_EXECUTION_STRING} when it survived): every -c string of 8,117 characters or less ran intact; every one of 8,221 or more was cut, regardless of content (quote-free, comment lines, heredocs, inline Python), deterministically. Replaying the identical strings from Python into the same bash.exe gave the same cut at the same offset, including the same "line 50" / "line 75" positions.

Minimal reproduction (no Claude Code involved):

import os, subprocess
BASH = r"C:\Program Files\Git\bin\bash.exe"   # identical results with usr\bin\bash.exe
def run(n, env=None):
    body = "echo len=${#BASH_EXECUTION_STRING} #" + "x" * n
    s = f"eval '{body}' < /dev/null && echo TAIL-OK"   # same shape as Claude Code's wrapper
    r = subprocess.run([BASH, "-c", s], capture_output=True, text=True, env=env)
    print(f"sent {len(s):5}  rc={r.returncode}  stdout={' '.join(r.stdout.split())!r:24}  stderr={r.stderr.strip()[:72]!r}")
for n in (8000, 8100, 8120, 8150, 9000, 30000):
    run(n)
print("-- with MSYS=noglob --")
for n in (9000, 30000):
    run(n, env={**os.environ, "MSYS": "noglob"})
print("-- but noglob breaks the wrapper's own apostrophe escaping --")
r = subprocess.run([BASH, "-c", "echo it'\"'\"'s fine"], capture_output=True, text=True, env={**os.environ, "MSYS": "noglob"})
print(f"rc={r.returncode} stdout={r.stdout.strip()!r} stderr={r.stderr.strip()[:80]!r}")

Output on this machine:

sent  8071  rc=0  stdout='len=8071 TAIL-OK'        stderr=''
sent  8171  rc=0  stdout='len=8171 TAIL-OK'        stderr=''
sent  8191  rc=0  stdout='len=8186 TA'             stderr=''        <- tail command truncated to `echo TA`, ran anyway, exit 0
sent  8221  rc=2  stdout=''                        stderr="/usr/bin/bash: -c: line 1: unexpected EOF while looking for matching `''"
sent  9071  rc=2  stdout=''                        stderr="/usr/bin/bash: -c: line 1: unexpected EOF while looking for matching `''"
sent 30071  rc=2  stdout=''                        stderr="/usr/bin/bash: -c: line 1: unexpected EOF while looking for matching `''"
-- with MSYS=noglob --
sent  9071  rc=0  stdout='len=9071 TAIL-OK'        stderr=''
sent 30071  rc=0  stdout='len=30071 TAIL-OK'       stderr=''
-- but noglob breaks the wrapper's own apostrophe escaping --
rc=2 stdout='' stderr="fine: -c: line 1: unexpected EOF while looking for matching `''"   <- argument split at the \" ; "fine" became $0

Why MSYS=noglob is not the fix on its own. It removes the truncation (30,744-char -c strings arrive intact), but in noglob mode the runtime no longer honours the \" escapes the spawner emits, so the '"'"' sequences the wrapper uses for apostrophes split the argument (last line above). Any command with an apostrophe would break instead.

Fixes that work, from the transport up:

1. Don't put the script on the command line on Windows. The spawn already uses stdin: "pipe": write the wrapped script to stdin and run bash -s (or bash <tempfile>, or bash -c 'eval "$CLAUDE_CMD"' with the script in an environment variable). Pipes, files and the environment block are not globbed. A 30 KB script then runs like a 3 KB one.
2. Until then, measure commandString.length after buildExecCommand and reject anything over ~8,100 characters with a clear error that names the limit and points the model at the Write tool — a rejection is recoverable in one turn; the silent partial write is discovered hours later, if ever.
3. The prefix counts against the same 8,186. Anything that grows it (the rg shim function, credential exports, CLAUDE_CODE_SHELL_PREFIX, a long snapshot path) shrinks the budget for every command, and if the prefix alone approached the limit every command would fail with the same line N regardless of content. That is the shape reported in #83243, #82376 and #68337; worth checking against this mechanism.

Cost on one machine: unexpected EOF while looking for matching appears in 20 session transcripts in the last 72 hours (35 hits), several of them multi-hour investigations that concluded "shell quoting is flaky". Related earlier reports: #32563, #48317.

Environment: Windows 11 Pro 10.0.26100, Claude Code 2.1.255 (build 2026-08-30, via Claude desktop 1.40609.1.0), Git for Windows 2.48.1.windows.1, msys-2.0.dll 3.5.7-882031da, bash 5.2.37.

Confirmed on Git for Windows 2.55.0 / msys 3.6.10 / Claude Code 2.1.255 (desktop), with two additions

Independent reproduction of @bochen2029-pixel's root cause on newer components: same 8,186-character cut of the -c string, no error at the cut. On this machine the wrapper (source <snapshot> … && eval '<command>' < /dev/null && pwd -P >| <cwd-file>) is 432 characters, so the command budget is about 7,750 characters, minus 4 per apostrophe (' → '"'"'). Calibrated in the harness with ${#BASH_EXECUTION_STRING}: a 7,737-character command (total 8,169) ran; 8,545 (total 8,977) was cut. CLAUDE_CODE_GIT_BASH_PATH pointed at usr\bin\bash.exe changes nothing (honoured per the debug log, truncates identically), and MSYS=noglob breaks the '"'"' escaping exactly as described above.

1. The trigger is the quoting the spawner applies, not any particular character in the prefix. Measured with a 12 KB single argument (bash -c 'echo ${#1}' _ <arg>), Node as the native parent:

| argument content | Node child receives | MSYS bash receives |
|---|---|---|
| letters only (passed bare) | 12000 | 12000 |
| contains spaces or tabs (spawner wraps it in "…") | 12000 | 8186 |
| ; > $ = # but no space (bare) | 12000 | 12000 |
| newlines, no spaces (bare) | 12000 | 99 (split at the newline) |

So stripping ' or { from the prefix would not help: any -c script contains spaces, gets quoted, and goes through globify(). Only a transport that is not the command line (stdin, file, environment block) avoids it.

2. The same glob step halves backslashes. Inside a quoted word globify() un-escapes \\ → \ and \" → " before glob() runs, so \\ written in a Bash-tool command reaches bash as \. Observed in the harness: printf '%s\n' 'p\\q' prints p\q, and a node -e '…"C:\\Program Files\\…"…' snippet reached node with single backslashes and died on \u. Moving the script to stdin fixes this as well.

3. Nothing else in the chain is involved. bash is spawned directly by claude.exe (no cmd.exe); Git\bin\bash.exe is the git-wrapper and passes the tail of the command line through verbatim (fixup_commandline allocates from wcslen(cmdline)); Node → Node passes a 30,000-character argument intact; bash -s with a 20 KB script on stdin arrives whole.

Minimal reproduction without Claude Code (Node):

const { spawnSync } = require("child_process");
const bash = "C:/Program Files/Git/usr/bin/bash.exe";
let s = "echo len=${#BASH_EXECUTION_STRING}\n";
while (s.length < 12000) s += "echo L " + "x".repeat(90) + " >/dev/null\n";
console.log(spawnSync(bash, ["-c", s + "echo TAIL-OK"], { encoding: "utf8" }).stdout);            // len=8186, no TAIL-OK
console.log(spawnSync(bash, ["-c", "echo ${#1}", "_", "x".repeat(12000)], { encoding: "utf8" }).stdout); // 12000 (bare argument)

Environment: Windows 11 Pro 10.0.26200, Claude Code 2.1.255 via Claude desktop, Git for Windows 2.55.0.windows.5, msys-2.0.dll 3.6.10-710e5275, bash 5.3.15.