[BUG] - Windows: PowerShell tool pre-validation intermittently fails with pwsh exited with code 1: the command line is too long / pwsh timed out after 5000ms, blocking shell commands behind approval-prompt loops

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 + Claude Code v2.1.142, the PowerShell tool's command pre-validation step intermittently fails with one of two pwsh-related errors, surfacing as Command contains malformed syntax that cannot be parsed: ... and forcing an approval-prompt retry loop in the UI. The underlying command often still executes successfully
behind the failed validation, but the user has to click "Yes" through repeated retries to get there. The bug is not deterministic by command shape or length .. it fires on commands as small as a trivial Get-ChildItem and skips commands of comparable complexity moments later.

The bug exists at the Claude Code wrapper layer (not in PowerShell itself, not in the user's environment), is not user-fixable, and meaningfully degrades the experience for any Windows user doing real shell work.

What Should Happen?

Expected vs. actual

Expected: PowerShell commands run inline without spurious pre-validation failures. The approval-prompt loop should only appear for commands that genuinely fail to parse or that the user has not yet authorised under their permission mode.

Actual: The pre-validation step fails on commands that PowerShell itself would happily run. Most failed commands, if approved through the loop, do execute successfully - visible because their output comes back to Claude despite the popup. So this is a wrapper-validation bug, not a command-execution bug. But the user experience is unusable: trivial work requires many "Yes" clicks per minute.

Error Messages/Logs

Verbatim error messages

  Variant A (when pwsh is installed and on PATH):

  Command contains malformed syntax that cannot be parsed: pwsh exited with code 1: The command line is too long.

  Variant B (when pwsh is not installed / not on PATH):

  Command contains malformed syntax that cannot be parsed: pwsh timed out after 5000ms (2 attempts)

  In Variant B the UI hangs for ~5 seconds per attempt before the prompt appears, so the loop is slower; in Variant A the prompt appears immediately. Loop behaviour
  and approval requirement is identical in both.

  In some cases the tool also auto-backgrounds the command without run_in_background: true being set in the tool input. Those backgrounded commands show:

  Background command "<description>" failed with exit code 34

  …with an empty output file at C:\Users\<user>\AppData\Local\Temp\claude\<slug>\<id>\tasks\<task-id>.output.

Steps to Reproduce

Reproduction

The bug fires within minutes of starting a session that does any meaningful PowerShell work.
Easiest
repro:

1. cd to any local repo
2. Start claude in that directory
3. Ask Claude to do something that uses the PowerShell tool even trivially. E.g. "list the files in this directory" or "show me git status"
4. Within 1–10 such requests, one will pop the validation error in the UI with a "1. Yes / 2. No" prompt

The exact command that fails varies; I've seen it fire on:

• Get-ChildItem <path> (140 chars, no quotes inside)
• git -C <path> status (50 chars)
• Invoke-RestMethod -Method Post ... to Bitbucket API (multiple sizes from ~500 to ~800 chars)
• powershell.exe -NoProfile -File <path-to-script.ps1> (90 chars, no shell metacharacters)

…and skip on commands of comparable shape and length later in the same session.

Variability / intermittency

• Same exact command can succeed in one turn and fail in the next within the same session, with no observable change in environment or input.
• Frequency increases the longer a session runs and the more PowerShell-tool calls have been made. (Possible state degradation in the wrapper across calls.)
• File-tool calls (Read, Write, Edit, Glob, Grep) and MCP tool calls never trigger this. Only the PowerShell tool does. So the regression is specific to whatever

pre-validation path the PowerShell tool uses on Windows.

• A freshly-installed Claude Code session that performs only file ops will not hit this bug at all. The bug is invisible in any workflow that doesn't shell out,

which probably explains why it has gone unreported by users on macOS / Linux (they have their own shells), and by Windows users who don't run shell commands.

Workarounds attempted have been attached

<img width="1216" height="412" alt="Image" src="https://github.com/user-attachments/assets/cf21a71a-00a4-4aa2-b983-a6761d179d0d" />

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.142 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Working theory (for triage)

Based on the symptoms, our best guess is:

• The PowerShell tool wraps each command in a pre-validation / parsing step that invokes pwsh (PowerShell 7) — not powershell.exe, despite the tool reporting that it

uses powershell.exe for execution.

• When pwsh is not on PATH, that invocation hangs trying to find the binary, hits a 5-second internal timeout, and reports pwsh timed out.
• When pwsh is on PATH, that invocation succeeds-but-fails-fast with pwsh exited with code 1: the command line is too long, suggesting the wrapper is passing

something to pwsh (perhaps a base64-encoded command, perhaps something larger) that exceeds pwsh's internal command-line limit.

• The bug is intermittent rather than 100% reproducible, suggesting state in the wrapper between calls — possibly accumulating something in the command construction

that eventually trips the length limit.

I cannot inspect the wrapper internals to confirm, but the consistent shape of the error messages (pwsh appearing despite the tool nominally using powershell.exe)
strongly suggests pwsh is involved in pre-validation.

---
Impact

• Severity: high for any Windows user doing real shell work. Bitbucket REST calls, git commands, file-system queries — all gated behind unpredictable manual

approvals.

• Workaround cost: every triggered command requires a "Yes" click, sometimes 3–5 clicks per command (the loop re-fires on retry). A session doing 20 shell ops can

require 30+ manual approvals.

• Population: any Windows user of Claude Code. macOS / Linux users appear unaffected.
• Token waste: each loop re-sends conversation context to the model, burning tokens on a wrapper bug. Particularly painful on Enterprise plans with shared monthly

pools.

---
Suggested triage starting points

If helpful for your investigation:

1. Diff the PowerShell tool's command-construction path between v2.1.142 and the last known-good version. Look for changes that introduced a pwsh invocation in the

validation/parse step.

1. Check whether the wrapper falls back from pwsh to powershell.exe cleanly when pwsh is unavailable (current behaviour suggests it does not; it just hangs).
2. Check whether the command being passed to pwsh for validation includes a constant prefix that grows session-over-session (would explain intermittency tied to

session length).

1. If reproducible internally, capture the exact arguments being passed to pwsh.exe when the bug fires — comparing them to a smaller successful invocation would

isolate the offending payload.

I'd be glad to test fixes / dev builds against this; reach out if useful.

---
Filed by: Sagar Suneja, Mitratech (sagar.suneja@mitratech.com)