[MODEL] Uses PowerShell here-string (@'...'@) inside the Bash tool on Windows, silently corrupting a git commit message
Type of Behavior Issue
Used the wrong tool/approach (applied PowerShell-only syntax inside the Bash tool).
What You Asked Claude to Do
On Windows, I asked Claude to "commit and push" three changed files in a git repository (a doc edit plus a version bump and a changelog entry). A multi-line commit message was appropriate (subject + body).
What Claude Actually Did
Claude invoked git commit through the Bash tool, but passed the multi-line message using PowerShell here-string syntax:
git commit -m @'
<subject line>
<body>
'@Bash does not treat @'...'@ as a here-string. It parsed @ as a literal character, then a single-quoted string, then another literal @. The resulting commit message had a stray @ line prepended and appended:
@
<subject line>
<body>
@The command exited 0, so nothing flagged the corruption. It was only caught on a manual git log -1 review afterwards, then fixed with git commit --amend (using the PowerShell tool that time) before the push. Had it not been noticed, the malformed message would have been pushed to the remote.
Expected Behavior
On Windows, where both a Bash tool and a PowerShell tool are available in the same session, Claude should match the multi-line-string idiom to the tool it actually calls:
@'...'@here-strings are PowerShell-only — use them only with the PowerShell tool.- In the Bash tool, use
-F <file>, repeated-mflags, or a proper bash heredoc for multi-line commit messages.
It should never apply PowerShell-only syntax inside the Bash tool. Ideally it should also self-verify the commit message (e.g. git log -1) when the message is multi-line or quoting-sensitive, since the failure here was silent (exit 0).
Files Affected
N/A — the corruption landed in the git commit message, not in a file on disk.
Can You Reproduce This?
Sometimes — the underlying tool behavior is 100% deterministic; the model's choice to use the wrong idiom is intermittent.
Steps to Reproduce
Deterministic part — in the Bash tool on Windows, run:
git commit -m @'
subject
body
'@Result: the commit message gets a stray @ line at the top and bottom (verify with git log -1 --format=%B), and the command still exits 0.
Model part: on Windows with both shells available, ask Claude to make a git commit with a multi-line message; it will sometimes route the PowerShell @'...'@ idiom through the Bash tool.
Relevant Conversation
- Asked Claude to "commit and push".
- Claude called the Bash tool:
git commit -m @'<newline>subject<newline><newline>body<newline>'@. git log -1 --format=%Bshowed a leading@line and a trailing@line wrapping the intended message.- Claude self-corrected with
git commit --amendvia the PowerShell tool (correct here-string usage there), confirmed a clean message, then pushed.
Impact
Low — caught and fixed before the push. Would be higher if it went unnoticed, since exit 0 gives no signal and a malformed message would reach the remote.
Claude Code Version
2.1.161
Platform
Windows 11
Model
Claude Opus 4.8 (claude-opus-4-8)
Additional Context
Related existing issues (adjacent, not duplicates):
- #64224 — Feature: first-class GitCommit action (bypass Bash argv for commit messages). This bug is a concrete motivation for it.
- #64253 — Windows + Git Bash: experiment silently force-enables the PowerShell tool, causing wrong-shell retries. Same "dual-shell confusion on Windows" theme, different mechanism.
- #62813 — Bash tool hangs on heredoc inside command substitution.
- #59577 — Permission-suggestion UI generates a malformed rule for git commit heredoc patterns.
- #61121 — Bash tool incorrectly escapes
!.
Common root: passing quoting/escaping-sensitive multi-line content through Bash argv on Windows, where two shells with different idioms coexist. A docs note in the Bash tool description ("@'...'@ is PowerShell-only; in bash use -F/-m") would likely prevent this class of mistake.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗