[BUG] PowerShell tool returns exit 1 with no output for all commands (regardless of allowlist matching)
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?
The PowerShell tool (Windows-specific tool that runs PowerShell commands directly, parallel to the Bash tool) consistently returns exit 1 with zero stdout/stderr output for any command, regardless of whether the command is registered in permissions.allow.
This makes the PowerShell tool effectively unusable on Windows. Even commands that exactly match a registered allow entry fail identically (no visible permission denial message either).
What Should Happen?
The PowerShell tool should:
- Return stdout / stderr from the executed command
- Return the exit code of the underlying PowerShell process
- Honor
permissions.allowPowerShell(...)entries (allow when matched, deny with a visible error message when not matched)
Error Messages/Logs
None visible. The PowerShell tool returns:
- Exit code: 1
- stdout: empty
- stderr: empty
No error message is shown to the user, even when a command would normally fail with a permission denial. This silent failure makes diagnosis difficult.
No relevant entries in Windows Event Viewer (Microsoft-Windows-CodeIntegrity/Operational, Microsoft-Windows-AppLocker/EXE and DLL) at the times of failed invocations.
Steps to Reproduce
- Open Claude Code (VS Code extension) on Windows.
- Invoke the PowerShell tool with any command. All of the following return exit 1 with no stdout and no stderr:
PowerShell tool: Write-Output "hello"PowerShell tool: Get-DatePowerShell tool: 1 + 1PowerShell tool: $PSVersionTable.PSVersion
- Even commands that exactly match a registered allow entry fail identically:
PowerShell tool: Get-Command bash -ErrorAction SilentlyContinue- (Registered in
permissions.allowasPowerShell(Get-Command bash -ErrorAction SilentlyContinue))
Control test (works correctly, confirms pwsh itself is healthy):
Bash tool: pwsh -NoProfile -Command 'Write-Output "hello"; Get-Date; $PSVersionTable.PSVersion'- Returns expected stdout (greeting + date + PSVersion 7.6.1) with exit code 0.
The bug is therefore isolated to the PowerShell tool implementation, not to PowerShell or the system environment.
Claude Model
Other
Is this a regression?
I don't know
Last Working Version
Unknown. The symptom appears to predate the current investigation; prior session notes also recorded the same exit 1 behavior, but the exact regression point (if any) is not known.
Claude Code Version
2.1.132
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
VS Code integrated terminal
Additional Information
Hypotheses (cannot verify, internal implementation):
- (a) Argument construction bug when spawning
pwsh.exefrom the tool host - (b) PowerShell tool host (.NET runtime / process spawn) bug — the process exits before producing output
- (c) Permission match logic 100% denies — but if so, an error message should still be visible to the user
Workaround:
Use the Bash tool with pwsh -NoProfile -Command "..." or pwsh -NoProfile -File path/to/script.ps1. The Bash → pwsh path works correctly. This is the only viable workaround currently.
Impact:
- PowerShell tool is completely unusable on Windows for any command
- Forces fallback to
Bash + pwsh, adding overhead and losing native PowerShell tool ergonomics - Allowlist entries for
PowerShell(...)are effectively dead (cannot be exercised)
Environment summary:
- OS: Windows 11 Pro
- pwsh: 7.6.1
- ~60
PowerShell(...)entries inpermissions.allow(mix of specific commands and wildcards)
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗