*This is a repost of #65162 which was closed due to inactivity. The issue just happened to me again, so I inserted my Claude Code version.* ### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) for similar behavior reports - [x] This report does NOT contain sensitive information (API keys, passwords, etc.) ### Type of Behavior Issue Claude ignored my instructions or configuration ### What

[MODEL] Uses PowerShell here-string (@'...'@) inside the Bash tool on Windows, silently corrupting a git commit message

Status Open

Reported on v2.1.241

Maintainer reply None cached

Activity 0 comments · opened Aug 23, 2026

This is a repost of #65162 which was closed due to inactivity. The issue just happened to me again, so I inserted my Claude Code version.

Preflight Checklist

[x] I have searched existing issues for similar behavior reports
[x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

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 -m flags, 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.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (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.

Claude Model

Opus

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=%B showed a leading @ line and a trailing @ line wrapping the intended message.
Claude self-corrected with git commit --amend via the PowerShell tool (correct here-string usage there), confirmed a clean message, then pushed.

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.241

Platform

Anthropic API

Additional Context

Related existing issue (closed due to inactivity): #65162

View original on GitHub ↗