[BUG] Windows: PowerShell tool absent from schema when Git Bash is on PATH, despite pwsh.exe being present and detectable

Resolved 💬 9 comments Opened May 26, 2026 by timbrigham-oc Closed Jul 3, 2026

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

  1. Windows 11 machine with Git Bash installed and <git>\usr\bin on PATH
  2. PowerShell 7 installed (MSI at C:\Program Files\PowerShell\7\pwsh.exe)
  3. Launch Claude Code from a PowerShell terminal (parent process traces to powershell.exe)
  4. Observe: session reports Shell: bash, PowerShell tool absent from tool schema

To confirm Git Bash is the sole cause:

  1. Remove <git>\usr\bin from user PATH (C:\Windows\System32\bash.exe via WSL remains —

docker-desktop distro, no bash installed, exits 127)

  1. Relaunch Claude Code
  2. 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.

View original on GitHub ↗

This issue has 9 comments on GitHub. Read the full discussion on GitHub ↗