[BUG] Desktop app on Windows: every new PowerShell tool call waits ~154 s before the command starts (dialog, permissions and host IPC ruled out); Bash is instant (same as #57960, closed stale; still present on 2.1.270)

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

This is the same bug as #57960 (filed May 2026 on Claude Code 2.1.138, closed as stale without a response). That report's desktop log shows the mechanism: "Streaming stall detected: 150.0s gap between events" and "permissionDecisionMs=150717". Four months and about 130 builds later the delay is unchanged; the measurements below cover every build from 2.1.220 to 2.1.270.

In the Claude Desktop app (Code tab) on Windows, every PowerShell tool call that has not been run before in the session takes 153 to 160 seconds from tool invocation until the command actually starts. When a permission dialog is shown, it appears only at the end of that wait and is confirmed within seconds. The Bash tool is unaffected (median 2.7 s).

Measured from the session transcripts (~/.claude/projects/<project>/<session>.jsonl, tool_use timestamp to tool_result timestamp) across 224 sessions:

851 of the 1244 PowerShell calls (68 %) took longer than 60 s; those alone add up to 37.8 hours over 121 sessions. The delay is present in every Claude Code build I have used, 2.1.220 through 2.1.270 (per-version table in Additional Information).

Where the time goes: a probe command wrote its own start time. Tool call issued at 17:21:54, the command itself started at 17:24:30.453 and finished at 17:24:30.572 (119 ms). The entire wait happens before the command starts.

The same command repeated verbatim returns in 2 to 3 seconds, so some per-command result is cached after the first run.

### What Should Happen?

A PowerShell tool call should start within a few seconds, like the Bash tool does on the same machine, and any permission dialog should appear immediately rather than after ~150 s.

### Error Messages/Logs

```shell
No error message is shown; the call simply waits and then succeeds.

Process-start watcher (WMI, 200 ms polling) during one slow call, tool_use issued at 16:44:25:

16:44:25 bash.exe parent claude.exe (PreToolUse hook, finishes in ~1 s) 16:44:26 powershell.exe parent claude.exe -NoProfile -NonInteractive -NoLogo -EncodedCommand ... (AST parser script) ... no process activity related to the call for ~150 s ... ~16:47:00 the actual command runs

The EncodedCommand decodes to the PowerShell AST parser script ([System.Management.Automation.Language.Parser]::ParseInput, output via ConvertTo-Json -Depth 10 -Compress). Run manually with "Get-Date" as input it completes in 1.07 s and returns "valid":true.

Timing of individual calls in one session (2026-09-14, local time, durations from the transcript):

18:00:08 Get-Date auto mode sandbox on 153.2 s 18:11:00 Get-Date (exact repeat) manual mode sandbox on 2.6 s 18:11:21 Get-Process -Name explorer | Select-Object -First 1 ... manual mode sandbox on 159.5 s 18:14:23 Start-Sleep -Milliseconds 10 manual mode sandbox on 158.8 s 18:19:42 Get-Process -Name explorer manual mode sandbox on 153.3 s 18:23:03 Get-Process -Name explorer (exact repeat) manual mode sandbox on 2.2 s 17:51:30 $a = Get-Date; "..." auto mode sandbox OFF 156.7 s (dangerouslyDisableSandbox: true)

Startup cost of the shell itself, measured on the same machine: powershell.exe -NoProfile -Command 1 0.63 to 0.70 s bash.exe -c "echo x" 0.14 s
```

### Steps to Reproduce

1. Open a project in the Claude Desktop app (Code tab) on Windows 11.
2. Ask Claude to run a trivial PowerShell tool command, for example Get-Date.
3. Observe: the result (or the permission dialog) appears only after roughly 150 seconds.
4. Ask Claude to run the identical command again: it returns in 2 to 3 seconds.
5. Ask Claude to run an equivalent Bash command (date): it returns in 2 to 4 seconds.

Reproduces in auto mode and in manual mode, with and without the sandbox, with and without matching permissions.allow rules, with simple and with compound commands.

### Claude Model

Other

### Is this a regression?

No, this never worked

### Last Working Version

none observed

### Claude Code Version

2.1.270 (Claude Code), bundled in Claude Desktop app 1.52386.6.0 (Windows Store package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc). A separate CLI install reports 2.1.236 but was not used for these sessions.

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

Environment

• Windows 11 Pro 10.0.26200
• Windows PowerShell 5.1.26100.9444; pwsh (PowerShell 7) is not installed
• Git for Windows present; the Bash tool uses Git Bash and works normally
• Workspace trust accepted (hasTrustDialogAccepted: true)
• One PreToolUse hook with matcher Bash|PowerShell (timeout 10 s). It applies equally to both tools and Bash is fast, so it is not the cause.
• Project .claude/settings.json contains 40 permissions.allow rules such as PowerShell(Get-Date*), PowerShell(Get-Process*). They do not change the timing (see #73587 and #82523 for related rule-matching reports).

Ruled out

• PowerShell startup: 0.6 to 0.8 s
• Sandbox: identical delay with dangerouslyDisableSandbox: true
• Auto mode classifier: identical delay in manual mode
• Permission rules and trust: identical delay for allow-listed commands
• dialogExpiry: default 5 min and resolves to cancel, does not match 155 s
• AST parser subprocess: fast and valid when run manually
• Command complexity: Get-Date alone is as slow as compound pipelines

PowerShell tool call duration by Claude Code build and entry point (all sessions of this project since August 2026):

Additional observations

• A few calls per session take 33 to 38 s instead of ~155 s; no pattern identified.
• Near-identical repeats (same script, different log file name) are also fast (3 to 10 s).
• The user confirms every permission dialog within seconds; the dialog only shows up after the wait, so the delay precedes the prompt, consistent with #69647.

Related issues

• #57960 Claude Desktop on Windows: PowerShell tool call permission prompt delayed ~2m35s before appearing: identical bug, closed as stale without a fix
• #45099 PowerShell prompt freezing (referenced by #57960)
• #69647 PowerShell tool takes ~3 minutes to spawn in VS Code extension on Windows (Bash tool is instant): same symptom, different host, 2.1.183
• #73587 Desktop app ignores permissions.allow rules
• #82523 PowerShell allow rules do not prevent the prompt
• #59454 PowerShell pre-validation intermittently fails or times out on Windows

I can provide the transcript-analysis script and the WMI watcher output on request.