[BUG] Windows: Bash tool silently corrupts written file content via command substitution and reports exit code 0

Preflight

• [x] I have searched existing issues. Closest matches: #76208 (same root mechanism, different failure mode — see below), #56361 (closed; slash-command preprocessor), #54222 (closed/not planned; backticks in a Skill glob). None covers silent corruption of written file content with a success status.
• [x] This is a single bug report.
• [ ] Version: reproduced on 2.1.221. Latest is 2.1.223 (2026-08-06). I checked the 2.1.222 and 2.1.223 changelogs: neither contains a fix for shell metacharacter handling in Bash tool arguments (the two Bash entries in 2.1.223 concern permission-prompt display, not command-string expansion), so this should still apply on latest.

---

What's Wrong?

On Windows, using the Bash tool to write file content — via python -c "...", heredocs, or cat >> file — lets the shell expand metacharacters in the command string before the payload reaches its target. Backtick-quoted segments, which are extremely common in Markdown and in code documentation, are consumed as command substitution and disappear from the file that gets written.

The expansion itself is correct POSIX behaviour and I am not asking for it to change. The problem is that the corruption is silent and the tool reports success: exit code 0, no warning, no diff. The agent concludes the write succeeded and moves on, leaving a corrupted file in the user's repository.

In my case this wrote a mangled line into a project tracking document, and also created a stray file named = at the repository root — a > inside the substituted text was parsed as a redirection. Neither was signalled. I found the stray file myself, several minutes later; the agent never noticed.

Relationship to #76208: that issue reports the same root mechanism (bash evaluating $(...) / backticks inside an agent-constructed double-quoted string) but a different failure mode: destructive command execution on macOS. It does not cover silent corruption of written content, and does not mention success reporting. This report is about the reporting/guardrail gap.

---

Steps to Reproduce

Run each of these through the Bash tool on Windows, and observe the output, the exit code, and the working directory afterwards.

1. Backticked text is silently dropped

python -c "print('avant `X.md` apres')"

Observed:

/usr/bin/bash: line 1: X.md: command not found
avant  apres
exit code: 0

Intended payload: `avant X.md apres
Actually produced: avant apres` — the backticked segment is gone.

2. Command substitution creates a stray file in the repository

python -c "print('critere: `ts_run >= 2026-08-06`')"

Observed:

/usr/bin/bash: line 1: ts_run: command not found
critere: 
exit code: 0

and a file literally named = appears in the current working directory: bash executed the backticked text as a command, in which > was parsed as a redirection. Nothing in the tool result indicates that a file was created.

3. Command substitution executes repository content

If the backticked segment names an existing file — very common when documenting paths, e.g. ` logs/run.csv — bash attempts to **execute that file**. With a CSV, every line is dispatched as a command: I got ~25 lines of command not found` followed by the script's own success message, which reads like a successful run.

---

Expected Behavior

Either the write should not be silently corrupted, or the tool result should make the corruption visible. Any one of these would have prevented the incident:

1. Warn when a Bash/PowerShell command string contains unescaped backticks, a heredoc, or an output redirection targeting a file, and point to the Write tool. Cheap, no behaviour change.
2. Report files created in the working directory as part of the tool result. The stray = would have been caught immediately.
3. Do not present as a clean success a run whose stderr contains command not found lines originating from command substitution rather than from the top-level command.
4. Document it. The Bash tool description already warns about /dev/null vs NUL and about PowerShell here-strings, but says nothing about command strings being metacharacter-expanded, nor that they must not be used to compose file content.

---

Environment

OS:               Microsoft Windows 11, version 10.0.26200.8973
Claude Code:      2.1.221  (latest at time of filing: 2.1.223)
Bash tool shell:  GNU bash 5.2.37(1)-release (x86_64-pc-msys) — Git Bash
PowerShell tool:  PowerShell 7.6.4 (exposed as a separate tool in the same session)
Python:           3.14.3

---

Additional Context

Frequency and impact, measured over one working session — the same defect hit four times in one night:

| attempt | outcome |
|---|---|
| cat >> report.md <<'EOF' heredoc | unexpected EOF while looking for matching — whole block lost |
| python -c string replacement (×2) | \e and \b consumed → pattern no longer matched → AssertionError |
| python -c editing a Markdown file | line written to disk with segments missing, no error |
| same, second occurrence | corrupted line plus a stray file named = at the repository root |

Every equivalent operation performed by writing a .py file first, with the native Write tool, and then executing it by path succeeded on the first attempt.

Why this matters specifically for an agentic product:

• The tool result is the agent's only feedback channel. Exit code 0 plus plausible stdout is indistinguishable from a real success, so self-verification never triggers.
• The writes land in user-owned files, not in a sandbox.
• On Windows the session exposes two shell tools with different quoting rules (Git Bash and PowerShell 7). Choosing the right escaping per call is a high-frequency, low-salience decision — exactly the kind that fails.