Bash tool: 'unexpected EOF' at wrapper line numbers (line 70-73) for structurally valid commands - structure-dependent, not length

Summary

The Bash tool intermittently fails structurally valid commands with bash: -c: line 7x: unexpected EOF while looking for matching ' (or executes a truncated path fragment, e.g. line 73: /de: No such file or directory from a much longer path). The reported line number does not exist in the user command — commands involved were 1–15 lines — so it appears to index into the harness-generated wrapper (... && eval '<command>' < /dev/null && pwd -P >| '<snapshot path>'), not the user's input. The error text blames the user command's syntax, which sends the agent chasing phantom quoting bugs; in one logged session this consumed roughly a dozen turns before the full wrapper happened to print and reveal the mismatch.

Environment

• Claude Code 2.1.207 (VS Code extension host), Windows 11 Home 10.0.26200
• Bash tool shell: Git Bash (POSIX sh)

Field data (45 days of local transcripts, one machine)

• 382 occurrences of the unexpected EOF / truncated-fragment class across ~100 sessions.
• Length is not the trigger: failing commands had median length 471 chars (min 2), while 790 commands over 2,000 chars (max 6,668) succeeded in the same window.
• Failures cluster on (a) multi-line inline commands with quoting, and (b) bash <file>.sh invocations where the script had CRLF line endings — e.g. line 73: /de: No such file where /de is the head of a longer path mangled mid-token.
• The same commands shortened or moved into an LF script file reliably succeed, which is the workaround we now use.

Repro status

Not yet deterministic — apologies. Two minimal probes on 2.1.207 pass:

echo 'line one
line two with '\'' embedded quote
line three'

VAR="multi
line value" && echo "$VAR" | grep -c line && echo "done: $(echo nested "quotes 'inner'" )"

The failing instances in transcripts are longer real-world commands; happy to run an instrumented repro against a debug build or share sanitized failing command bodies if useful.

Ask

1. When the wrapper (not the user command) fails to parse, say so in the error — or map the reported line number back to the user command. The current message actively misattributes the fault.
2. Harden wrapper generation for multi-line and CRLF-contaminated inputs (the eval '<command>' quoting appears to be the seam).