[BUG] Windows: PowerShell tool absent from schema when Git Bash is on PATH, despite pwsh.exe being present and detectable
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
On Windows, the native PowerShell tool is absent from the Claude Code tool schema when Git
Bash is present on PATH — even though pwsh.exe is installed and detectable, and even when
the session is launched from a PowerShell terminal. The session reports Shell: bash with
no warning, no log entry, and no indication that PowerShell tool registration was skipped.
This silently invalidates all PowerShell(...) deny rules in managed-settings.json. Admins
deploying PowerShell-specific policy controls have no way to know those rules are never
evaluated. On developer machines where Git for Windows is essentially ubiquitous, this
likely affects the majority of Windows fleet sessions.
What Should Happen?
Per the docs: "The Bash tool remains registered alongside the PowerShell tool." Both tools
should coexist when both bash and pwsh.exe are available, regardless of PATH order. The
PowerShell tool should surface on win32 independently of whether Git Bash is on PATH.
Error Messages/Logs
No error output — the failure is entirely silent. The PowerShell tool is absent from the
schema with no diagnostic, warning, or session log entry.
Steps to Reproduce
- Windows 11 machine with Git Bash installed and <git>\usr\bin on PATH
- PowerShell 7 installed (MSI at C:\Program Files\PowerShell\7\pwsh.exe)
- Launch Claude Code from a PowerShell terminal (parent process traces to powershell.exe)
- Observe: session reports Shell: bash, PowerShell tool absent from tool schema
To confirm Git Bash is the sole cause:
- Remove <git>\usr\bin from user PATH (C:\Windows\System32\bash.exe via WSL remains —
docker-desktop distro, no bash installed, exits 127)
- Relaunch Claude Code
- Observe: PowerShell tool now present and functional; WSL bash stub does not suppress it
because Claude Code probes bash for usability and skips a non-functional binary
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.148 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Root cause confirmed: Claude Code probes bash for usability during shell detection. Git Bash
passes the probe and wins, suppressing PowerShell tool registration entirely. The WSL
docker-desktop bash stub (System32\bash.exe) fails the probe and is correctly skipped —
confirming the issue requires a functional bash on PATH, not merely bash.exe existing.
No working workaround exists via settings:
- "defaultShell": "powershell" in user settings: no effect
- "defaultShell": "powershell" in managed-settings.json (highest-priority scope): no effect
Only fix is removing Git Bash from PATH, which is not acceptable in a dev environment.
Searched existing issues before filing — confirmed no duplicates:
- #59225 ("Windows: model is told Shell=PowerShell while hooks execute under bash"):
Same Git Bash PATH-race root cause, but covers hook execution running under bash while
the model is told Shell=PowerShell. Our issue is the PowerShell tool itself never
registering — different symptom, different impact.
- #55190 ("PowerShell tool docs do not mention supported Windows PowerShell 7 discovery
sources"): Covers documentation gap around pwsh.exe detection sources. Our issue is that
detection fails silently for the tool itself when Git Bash is present, not a docs gap.
- #62113 ("Desktop SSH: shell mis-detected as posix after update, breaks server --install
on PowerShell default shell"): SSH remote connection shell mis-detection regression.
Different surface (remote SSH vs local native session), different failure mode.
None of the above cover local PowerShell tool registration being suppressed by a functional
bash on PATH.
This issue has 9 comments on GitHub. Read the full discussion on GitHub ↗