Windows regression in 2.1.235: PowerShell tool fails from Git Bash with `--model haiku` (`pwsh exited with code 1`)

Summary

On Windows, Claude Code 2.1.235 fails every PowerShell tool call with
pwsh exited with code 1 — but only under a specific three-way combination.
2.1.168 is unaffected on the same machine with identical settings.

The failure requires all three of the following at once:

1. Claude Code 2.1.235
2. Launched from Git Bash (MSYS2 / MinGW64 shell)
3. --model haiku

Remove any one of the three and it always works.

Every PowerShell tool call fails before command execution during the
permission/classifier stage, including trivially safe ones like git --version.
Because Claude Code does not offer the Bash tool when it is launched from Git Bash
(true in both 2.1.168 and 2.1.235 here), the PowerShell tool is the only
shell-execution tool available in that configuration — so the session loses shell
execution entirely.

Environment

• OS: Windows 11 Pro 10.0.26200 (Japanese locale; ANSI code page 932)
• Claude Code: 2.1.235 (native install), compared against 2.1.168
• pwsh: 7.6.5, Microsoft Store install

(C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.5.0_x64__8wekyb3d8bbwe\pwsh.exe;
resolved through the WindowsApps execution alias. No C:\Program Files\PowerShell\7 install exists.)

• Git Bash: Git for Windows 2.38.1, MSYSTEM=MINGW64
• CLAUDE_CODE_USE_POWERSHELL_TOOL: not set (PowerShell tool is on by default)
• permissions.additionalDirectories: not present in any settings file
• permissions.allow: 1 entry (user settings) + 165 entries (user local settings)
• permissions.deny / ask: none
• Managed settings: none (neither managed-settings.json location exists; no

HKLM/HKCU SOFTWARE\Policies\ClaudeCode key)

• MCP servers configured in ~/.claude.json: 5

Both versions were run as isolated copies from a scratch directory so that the
installed binary was never modified, and so that only the version differed.

Repro

From a Git Bash prompt, in a disposable directory that contains no project or
local settings:

"/path/to/claude-2.1.235.exe" -p "Use the PowerShell tool to run exactly: git --version" --model haiku

Observed tool result (verbatim from the session transcript):

Command contains malformed syntax that cannot be parsed: pwsh exited with code 1: <mojibake>

The same command with claude-2.1.168.exe returns git version 2.38.1.windows.1.

Result matrix

Same disposable working directory, same prompt, same settings; one variable changed per row.

| Version | Launched from | --model | Result |
|---|---|---|---|
| 2.1.168 | Git Bash | default | pass |
| 2.1.168 | Git Bash | haiku | pass (3/3) |
| 2.1.168 | PowerShell | haiku | pass |
| 2.1.235 | Git Bash | default | pass |
| 2.1.235 | Git Bash | sonnet | pass |
| 2.1.235 | Git Bash | opus | pass |
| 2.1.235 | PowerShell | haiku | pass (2/2) |
| 2.1.235 | cmd.exe | haiku | pass |
| 2.1.235 | Git Bash | haiku | fail (14/14) |

Totals: 14/14 failures with all three conditions present; 15/15 successes whenever
any one condition was removed.

Notably, the PowerShell tool input emitted by Haiku and by Sonnet is byte-identical
({"command": "git --version", "description": "Check git version"}), so the model
is not producing a different command string.

Ruled out

Each of the following was tested as a single-variable change from the failing case,
and the failure persisted in every one:

• --safe-mode (all customizations disabled)
• Excluding user settings entirely via --setting-sources project,local

(verified effective: user hooks stopped firing and the transcript shrank from
81 KB to 29 KB) — this is the main difference from #55671

• A minimal environment (env -i with only PATH/HOME/USERPROFILE/SYSTEMROOT/TEMP)
• stdin as a pipe, and stdin as /dev/null
• Inserting a Read tool call before the first PowerShell call (rules out a

first-tool-call race)

• --debug, --output-format text, longer prompts, permission mode — each of these

alone does not cause the failure

I could not capture an over-long command line: polling Win32_Process every 10 ms for
cmd.exe / pwsh.exe / powershell.exe during a failing run captured only short
invocations (191–383 chars), all of them hook launches of the form
pwsh.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command "python -X utf8 ...".

Not bisected: I only have 2.1.168 and 2.1.235 locally, so I do not know which
intermediate release introduced this.

Diagnostic note

On this Japanese Windows installation, the underlying pwsh error is rendered as
mojibake in Claude Code. Re-decoding the surviving bytes as CP932 is consistent with
「コマンド ラインが長すぎます。」 ("The command line is too long"), but I have not
identified which subprocess emitted that text.

Possibly related

#55671 (Windows: PowerShell permission classifier fails 'command line too long' when
additionalDirectories list is large) — closed 2026-06-17 as not planned after going stale.

Similar: Windows, Microsoft Store pwsh, --model haiku, PowerShell tool, permission
classifier failing before the command runs, pwsh exited with code 1, and (after
decoding) the same "command line is too long" wording.

Different: that report's trigger was a large permissions.additionalDirectories list,
and pruning 38 entries to 4 fixed it. This install has no additionalDirectories
at all, and removing every file-based user setting does not help. A commenter on
that issue also reported it occurring with no unusually large config, and only in the
UI/extension session rather than the terminal one — which is a launch-context
dependency, similar in shape to the Git Bash dependency here.

So this may be the same underlying defect with a second, settings-independent trigger
path, or it may be a distinct regression introduced after 2.1.168. I have not
established which.

What I have not ruled out

--setting-sources does not appear to exclude ~/.claude.json, so MCP server
definitions (5 here) were loaded in every run, including the "no user settings" one.
I did not test with MCP servers removed.