[BUG] Bash tool becomes permanently broken mid-session — every command fails with the same bash -c wrapper parse error, regardless of content

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment:

OS: Windows 11 Home (10.0.26200)
Shell: Git Bash (Git for Windows, MSYS2-based), installed at C:\Program Files\Git
Claude Code running in a long-running conversation session
Summary:

Partway through a long working session, the Bash tool stopped executing any command at all. Every subsequent Bash call — regardless of content, including trivial ones like echo hi and whoami — failed with the same class of error, always pointing at the same internal line number in Claude Code's own bash -c wrapper, not at anything in the command I actually sent.

Errors observed (all from the same broken session, different calls):

/usr/bin/bash: -c: line 120: unexpected EOF while looking for matching ''
/usr/bin/bash: -c: line 124: syntax error: unexpected end of file from {' command on line 123
/usr/bin/bash: -c: line 123: unexpected EOF while looking for matching `"'
One partial error also leaked a fragment of the internal wrapper script:

: && shopt -u extglob 2>/dev/null || true && { \builtin unalias -- 'unsetenv'; \builtin unset -f -- 'unsetenv'; } >/dev/null 2>&1 || true && eval 'cd "..." && git log --oneline -5' <'
What led up to it:

Before it broke, this session had run an unusually large volume of Bash tool calls in one continuous conversation — many long-running background test runs (several minutes each), multiple diagnostic scripts reading real multi-megabyte files, and dozens of sequential git add/file operations. Shortly before the tool broke completely, one specific call using a heredoc (cat >> file << 'EOF' ... EOF) with contraction-heavy prose (lots of 's, n't, etc. inside the body) failed with the "unexpected EOF while looking for matching" error in isolation. I worked around that one by switching to a different file-editing tool — but a short time later, every Bash call in the session started failing the same way, including calls with no quotes or heredocs at all.

Notable detail — partial execution despite the error: in at least one case (git add <file>), the tool reported this same wrapper error, but the file was actually staged successfully (confirmed via a follow-up git status). So the wrapper sometimes fails/reports an error after the real command already ran, not before — suggesting the parse failure is in some trailing/cleanup part of the wrapper, not the command dispatch itself.

What did NOT fix it:

Restarting the Claude Code app
Restarting the entire PC
Waiting and retrying multiple times
What DID fix it:

Starting a brand-new chat session. Bash worked immediately and normally there (confirmed by successfully running git push from the new session).
Ruled out as a cause:

Checked ~/.bashrc, ~/.bash_profile, ~/.profile — none exist on this machine.
Checked Git for Windows' own /etc/profile and /etc/bash.bashrc — both are stock, unmodified files with no syntax issues.
So this appears to be corrupted internal state scoped to a single long-running Claude Code conversation/session (not the OS, not the user's shell config, not the git repo), possibly triggered by a high volume of Bash tool calls and/or the one heredoc call with heavy embedded quoting, though I can't confirm the exact trigger — only that the failure was 100% reproducible within that session and 100% absent in a fresh one.

Impact: Once triggered, the affected session becomes unable to run any shell command for the rest of its lifetime — no workaround was found short of abandoning the session and starting a new one.

What Should Happen?

Expected behaviour:

The Bash tool should execute the literal command passed to it and return its real output/exit code, unaffected by unrelated prior tool calls in the same session. Specifically:

A trivial command (echo hi, whoami, git status) should never fail due to a parse error in Claude Code's own wrapper script — only due to something in the command itself or a genuine environment issue.
If one call (e.g. the heredoc with heavy embedded quoting) causes a parse problem, that failure should be isolated to that single call — it should not corrupt the wrapper for every subsequent call in the session.
If a command actually executes successfully server-side (as happened with the git add case), the tool should report success, not surface an error for output that occurred after the real work was already done.
Recovery, if the wrapper does get into a bad state, should be possible without abandoning the entire conversation — e.g. the harness should detect and reset a broken shell wrapper automatically, rather than requiring the user to start an entirely new session.
Actual behaviour:

Once triggered, the wrapper failure was total and permanent for the remainder of the session — every subsequent Bash call failed identically regardless of content, with no way to reset or recover short of starting a brand-new conversation.

Error Messages/Logs

Error message/logs:

Earliest failure (one heredoc call, before full breakage — this call had a multi-line body with many apostrophes/contractions inside a << 'EOF' block):

Exit code 2
/usr/bin/bash: -c: line 117: unexpected EOF while looking for matching `''
Shortly after, on an unrelated plain command (git status / git log --oneline -5, no heredoc, no special characters):

Exit code 2
/usr/bin/bash: -c: line 120: unexpected EOF while looking for matching `''
Exit code 2
/usr/bin/bash: -c: line 120: syntax error near unexpected token `newline'
A git add <single-file> call that reported this error but the file was actually staged successfully anyway (confirmed via a follow-up git status --short showing it staged):

Exit code 1
/usr/bin/bash: line 120: /c/Users/Ronald/AppData/Local/: Is a directory
An ls call on a long path under AppData\Local\Temp\claude\... — printed the real directory listing first, then still errored:

[directory listing printed correctly]
/usr/bin/bash: line 120: /c/Users/Ronald/AppData/Local/Temp: Is a directory
Later in the session (after the user restarted the Claude Code app, and separately after a full PC restart) — every call, including trivial ones, failed identically:

Exit code 2
/usr/bin/bash: -c: line 124: syntax error: unexpected end of file from `{' command on line 123
Commands that produced this exact output: git push, echo test, echo test2, pwd, git status.

After a further attempt (line number and quote character shifted again):

Exit code 2
/usr/bin/bash: -c: line 123: unexpected EOF while looking for matching `"'
Commands that produced this exact output: git status, echo test, whoami.

One partially-leaked fragment of the internal wrapper itself, captured from a background-task error output earlier in the session:

: && shopt -u extglob 2>/dev/null || true && { \builtin unalias -- 'unsetenv'; \builtin unset -f -- 'unsetenv'; } >/dev/null 2>&1 || true && eval 'cd "C:\Users\Ronald\Documents\Claude Projects\Service Department Development Kit" && git log --oneline -5' <'
(this is the only place the wrapper's own source leaked into a visible error — the trailing <' with nothing after it looks like a truncated stdin redirection, possibly the actual root cause of the "unexpected EOF" family of errors above)

Steps to Reproduce

Steps to reproduce:

I don't have an isolated minimal reproduction — the failure appeared after an extended single conversation with heavy Bash tool usage, and I can't confirm which specific step was necessary vs. incidental. The sequence that preceded it:

Work in one continuous Claude Code chat session for an extended period (multiple hours), issuing a large number of Bash tool calls, including:
Several foreground calls (npm run lint, npm run typecheck).
Many long-running background calls (npm run test, individual vitest run <file> invocations), several taking 3-6 minutes each, run via the tool's background/async mode and polled for completion.
A few one-off diagnostic scripts (npx tsx script.ts) reading real multi-megabyte files from disk.
At some point, run a command that appends a large multi-line block of prose to a file via a Bash heredoc, e.g.:
cat >> somefile.md << 'EOF'
... several paragraphs of prose containing many contractions/apostrophes
(didn't, wasn't, doesn't, isn't, etc.) and inline markdown code spans
with backticks ...
EOF
This single call failed with:

/usr/bin/bash: -c: line 117: unexpected EOF while looking for matching `''
(This looked like an isolated, one-off failure at the time — switching to a different file-editing approach for that specific edit worked fine, and several more ordinary Bash calls succeeded normally afterward.)

Continue the same session with more ordinary Bash calls (e.g. a sequence of individual git add <file> calls, one per file, several dozen calls in a row).
At some point later in that same session (not immediately after step 2 — several more successful calls happened in between), Bash calls start intermittently failing with the same class of error, on commands that have nothing unusual about them (no heredocs, no special characters) — e.g. a single git add <one file> or git commit -F <path>.
Eventually, every Bash call in the session — including trivial ones like echo hi, whoami, pwd — fails identically, permanently, for the rest of that session's lifetime.
Confirm the breakage is total: retry the same trivial command multiple times, always the same error.
Confirm restarting the Claude Code app does not fix it (same session, same error).
Confirm restarting the OS does not fix it (same session, same error).
Confirm starting a brand-new chat session (not resuming/restoring the old one) does fix it — Bash works immediately and normally there.
If a maintainer wants to try to reproduce this directly, the closest lever I can point to is: a single conversation session with a large volume of Bash tool calls (dozens+), including several long-running background ones and at least one heredoc call with heavy embedded quoting/apostrophes — though I can't confirm the heredoc call is actually causal rather than coincidental, since several ordinary calls succeeded both before and immediately after it.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code CLI version: 2.1.211

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_