[BUG] PowerShell tool returns exit 1 with no output for all commands (regardless of allowlist matching)

Resolved 💬 3 comments Opened May 7, 2026 by ctrlpanel-lab Closed May 7, 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?

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.allow PowerShell(...) 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

  1. Open Claude Code (VS Code extension) on Windows.
  2. 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-Date
  • PowerShell tool: 1 + 1
  • PowerShell tool: $PSVersionTable.PSVersion
  1. Even commands that exactly match a registered allow entry fail identically:
  • PowerShell tool: Get-Command bash -ErrorAction SilentlyContinue
  • (Registered in permissions.allow as PowerShell(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.exe from 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 in permissions.allow (mix of specific commands and wildcards)

View original on GitHub ↗

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