[Windows] Plugin hooks' commandWindows field silently ignored - forces Git Bash, causes MSYS2 crash (errno 1 add_item)

Environment

• Claude Code CLI 2.1.247
• Windows 11
• Git for Windows 2.55.0.windows.3 (Git Bash)
• Node v22.23.2

Summary

Plugin hook definitions that include a commandWindows field (PowerShell script, alongside a POSIX command field) are silently ignored — Claude Code always executes "type": "command" hooks through Git Bash on Windows regardless of commandWindows. This isn't documented anywhere (the hooks docs only mention command + shell).

Because two popular plugins (caveman, ponytail) ship hooks with commandWindows (presumably written against an assumed/earlier API), every UserPromptSubmit (and SessionStart) fires through Git Bash instead of PowerShell. With 2+ plugins registering concurrent UserPromptSubmit hooks, this reliably triggers MSYS2's fork()/DLL-rebase race:

UserPromptSubmit hook error
Failed with non-blocking status code: 0 [main] bash (15856) C:\Program Files\Git\bin\..\usr\bin\bash.exe: *** fatal error - add_item ("\??\C:\Program Files\Git", "/", ...) failed, errno 1
UserPromptSubmit hook timed out after 20s — output discarded.

This happens on effectively every prompt submit when 2+ hook-registering plugins are enabled.

Repro

1. Install two Claude Code plugins that each register a UserPromptSubmit hook of "type": "command" with a commandWindows field (e.g. caveman + ponytail).
2. Submit any prompt.
3. Observe intermittent-to-consistent bash.exe: *** fatal error - add_item ... errno 1 and/or hook timeout.

Expected

Either:

• Document that commandWindows is not a real field (so plugin authors stop shipping it), and/or
• Actually support commandWindows as a per-platform override, matching what several plugin authors already assumed existed.

Workaround

Add "shell": "powershell" to each hook object and use the plugin's existing commandWindows script content as command. Confirmed this stops the crash.

Related

• #22700 (closed) — same underlying "hooks forced through bash on Windows" symptom, different angle (PATH detection).
• #23766 (closed) — hooks freezing Windows, possibly the same MSYS race under a different trigger.

Neither issue discusses the commandWindows field being unsupported, which is the root cause here — plugin authors are shipping a field that looks like documented API surface but does nothing.