[BUG] Windows Git Bash: Bash tool brace-expands inside quoted strings and splits quoted paths containing spaces

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest: #41443 / #42400, both about the brace-expansion permission check, a different bug)
• [x] This is a single bug report
• [x] Using a recent Claude Code version on Windows 11 + Git Bash (running inside Cherry Studio's agent runtime)

What's Wrong?

Two distinct command-corruption behaviors in the Bash tool on Windows:

1. Brace expansion happens inside quoted strings, silently mangling regexes.

grep -a -o -E "github_pat_[A-Za-z0-9_]{16,}" app.log

is not executed as written. The {16,} is brace-expanded inside the double quotes (second alternative empty), so grep receives the pattern github_pat_[A-Za-z0-9_] plus a stray empty argument, and errors:

/usr/bin/grep: github_pat_[A-Za-z0-9_]: No such file or directory

Observed identically inside single quotes: 'version[^,}]{0,40}' becomes version[^,}]40. This corrupts any ERE/PCRE with {N,M} quantifiers — the classic fix grep -E "x{2,5}" fails on this platform.

2. Quoted paths containing spaces are split into multiple arguments.

grep -c pattern "/c/Users/me/AppData/Roaming/CherryStudio/Local State"

arrives at the shell as two arguments (...Local and State), producing /usr/bin/grep: State: No such file or directory. Single quotes behave the same. Backslash-escaping the space (Local\ State) works around it.

Impact

• Silent corruption (case 1) — regexes quietly change meaning instead of erroring loudly; a token-sweep with {16,} returned no matches at all while matches existed, wasting a full debugging session.
• Broken commands (case 2) — standard quoting idioms fail on Windows.
• Agents must learn non-portable workarounds (avoid {N,M} entirely, backslash-escape spaces) that don't match documented bash behavior.

Expected behavior

Quoted strings should reach bash verbatim — no brace expansion inside quotes, and quoted paths with spaces should remain single arguments (both hold in plain Git Bash on the same machine).

Steps to reproduce

1. On Windows with Git Bash: run grep -E "a{1,3}" README.md via the Bash tool → pattern mangled, "No such file or directory" for the remnant arg.
2. Run ls "/c/Program Files" via the Bash tool → two-argument split error.
3. Run both directly in Git Bash → both work correctly.

Related

• #41443 / #42400 describe the brace-expansion permission prompt check misfiring on quoted JSON — possibly the same naive quote handling, different symptom.