[BUG] PowerShell tool always exits 1 ("The command line is too long") on Windows when context is large

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, every call to the PowerShell tool fails with Exit code 1 and no stdout/stderr — even trivial commands like echo hi, Write-Output "hi", or exit 0. The Bash tool works fine in the same session, and pwsh invoked via Bash also works fine, so the user's PowerShell install is not the problem.

Extension log reveals the cause:

[DEBUG] PowerShell parser: pwsh exited 1: The command line is too long. (attempt 1)
[DEBUG] PowerShell parser: pwsh exited 1: The command line is too long. (attempt 2)
[DEBUG] PowerShell parser: pwsh exited with code 1, stderr: The command line is too long.
[DEBUG] PowerShell tool error (10ms): Shell command failed

The wrapper appears to invoke pwsh -Command "<payload>" with a payload that exceeds Windows' CreateProcess command-line limit (~32,767 chars). This happens even when the user-facing command is 7 chars (echo hi), so the oversize payload is being injected by the wrapper itself (env, snapshot, or wrapping script). Failure is immediate (~10 ms), confirming pwsh rejects the command line before executing anything (no side effects observed; Out-File doesn't create the target file).

Bash tool isn't affected — likely uses a different invocation path that avoids the Win32 limit.

Impact: Windows users with non-trivial CLAUDE.md / MEMORY.md / many MCP servers (the deferred-tools list alone is huge) cannot use the PowerShell tool at all.

What Should Happen?

The PowerShell tool should execute the command and return stdout/stderr/exit code, identical to how the Bash tool behaves. Session context size should not affect tool invocation.

Suggested fixes:

1. Pass the script via a temp .ps1 file and pwsh -File <path> — no command-line size limit.
2. Pipe via stdin: pwsh -NoProfile -NonInteractive -Command - and write the payload to stdin.
3. If a wrapping preamble is needed, dot-source a fixed helper script on disk instead of inlining it.

Error Messages/Logs

Steps to Reproduce

1. Open Claude Code in VSCode on Windows in a project with a large CLAUDE.md/MEMORY.md and several MCP servers connected (so the deferred-tools list is large).
2. Ask Claude to run echo hi via the PowerShell tool.
3. Observe: tool returns Exit code 1, no stdout/stderr.
4. Ask Claude to run via Bash instead: pwsh -NoProfile -NonInteractive -Command "Write-Output hi" → returns hi, exit 0.
5. Inspect %APPDATA%\Code\logs\<latest>\window1\exthost\Anthropic.claude-code\Claude VSCode.log → see "The command line is too long".

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.133

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment:

• Claude Code version: 2.1.133
• OS: Windows 11 Pro 10.0.26200
• Shell: PowerShell 7.6.1 (pwsh.exe, store install — symlink to C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.1.0_x64__8wekyb3d8bbwe\pwsh.exe)
• Frontend: VSCode extension Anthropic.claude-code
• Model: Claude Opus 4.7

Workaround: call pwsh -NoProfile -NonInteractive -Command "<command>" via the Bash tool — works perfectly.

Diagnostics ruled out:

• No PowerShell $PROFILE exists on this machine (not a profile issue).
• No hooks config touches PowerShell.
• pwsh.exe symlink resolves correctly and runs fine when invoked from Bash with the same payload size.