[BUG] Claude Code Windows Shell Compatibility Issue

Resolved 💬 3 comments Opened Dec 27, 2025 by buck Closed Dec 30, 2025

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?

When Claude Code executes PowerShell commands via the Bash tool on Windows, bash is pre-processing the command strings and attempting to expand variables (like $_, $var) before PowerShell receives them. This causes PowerShell commands with variable references to fail with errors like:

extglob.Status : The term 'extglob.Status' is not recognized as the name of a cmdlet...
extglob.Name : The term 'extglob.Name' is not recognized as the name of a cmdlet...

What Should Happen?

PowerShell commands should be passed to powershell.exe without bash pre-processing variable substitutions. The command string after -Command should be treated as opaque until PowerShell receives it.

Error Messages/Logs

extglob.Status : The term 'extglob.Status' is not recognized as the name of a cmdlet...
extglob.Name : The term 'extglob.Name' is not recognized as the name of a cmdlet...

Steps to Reproduce

Fails - PowerShell with Where-Object filtering

powershell.exe -Command "Get-Service | Where-Object {$_.Status -ne 'Running'}"

Result: Bash expands $_ before PowerShell sees it, causing extglob.* errors

Fails - PowerShell with property access

powershell.exe -Command "Get-Process | Where-Object {$_.Name -like '*growl*'}"

Result: Same issue - bash interprets $_ as a bash variable

Works - Simple PowerShell without variables

powershell.exe -Command "Get-Process growl -ErrorAction SilentlyContinue"

Result: Success - no variable expansion needed

Works - PowerShell with backtick escaping

powershell.exe -Command "Get-Service | Where-Object {\`$_.Status -ne 'Running'}"

Result: Success when AI uses backtick escaping, but this is inconsistent/fragile

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.0.76

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Impact

  • Basic PowerShell queries with filtering/object properties consistently fail
  • The AI has to work around the issue with workarounds that are less efficient
  • Makes Windows troubleshooting significantly harder
  • Degrades user experience on Windows compared to Unix systems

Additional Context

This issue was encountered while trying to:

  1. Query Windows services by status
  2. Find processes by name pattern
  3. Filter service lists by StartType property

All of these are common Windows system administration tasks that should work reliably.

Suggested Fix

The Bash tool on Windows should either:

  1. Automatically escape PowerShell variables before passing to the shell
  2. Use a different invocation method that prevents bash variable expansion
  3. Provide a separate PowerShell tool for Windows that bypasses bash entirely
  4. Properly quote/escape the command string to prevent bash interpretation

Timeline & Root Cause

This is a regression in Claude Code, not an environment issue.

  • Git for Windows (git-bash) is a required dependency for Claude Code on Windows
  • Claude Code has been working with Git Bash for months without this issue
  • User reports this problem "seems new" - appeared recently
  • Git Bash itself hasn't changed
  • Conclusion: A recent Claude Code update changed how it invokes commands through the Bash tool, introducing this variable expansion bug

The issue is likely in how Claude Code constructs or escapes command strings before passing them to the shell, not in the shell itself.

View original on GitHub ↗

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