[BUG] Windows Desktop: chat code-block Run button always uses powershell.exe 5.1, never pwsh 7

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, the Run button that the desktop app adds to shell code blocks in
the chat transcript always executes Windows PowerShell 5.1
(C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe), even though
PowerShell 7 is installed and on PATH. pwsh-only syntax therefore cannot run.
The one I hit constantly is &&, which 5.1 rejects at parse time (see Error
Messages), so an ordinary block like npm ci && npm test cannot be run with
the Run button at all.

The PowerShell tool the model executes through auto-detects and uses pwsh
7.6.5 on this same machine, as documented ("auto-detects pwsh.exe ... with a
fallback to powershell.exe"). So the detection logic already exists in the
product; the Run button just does not use it.

What Should Happen?

Any of these would resolve it. The first two were already proposed in #83889,
which was closed as a duplicate of #82486 — a request scoped to the Terminal
pane's configurability only — so these asks were dropped; credit for them
goes to that reporter.

1. Run button uses the same shell resolution as the PowerShell tool (prefer

pwsh.exe, fall back to powershell.exe).

1. Honor the fence language: route a ```bash block to bash when available, and

warn or disable Run when the fence language cannot match the target shell.

1. Failing that, a documented setting for this surface (make the existing

CLAUDE_CODE_SHELL / defaultShell actually apply to it on Windows).

Error Messages/Logs

At line:1 char:13
+ echo test-A && echo test-B
+             ~~
The token '&&' is not a valid statement separator in this version.
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : InvalidEndOfLine

Steps to Reproduce

1. On Windows with PowerShell 7 installed at

C:\Program Files\PowerShell\7\pwsh.exe, open a Code session in the
desktop app.

1. Get the assistant to emit a fenced shell block containing:

(Get-Process -Id $PID).Path; $PSVersionTable.PSVersion

1. Click the Run button on that block.

Observed: C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe / 5.1.26100.9168
Expected: C:\Program Files\PowerShell\7\pwsh.exe / 7.6.5

1. Click Run on a block containing echo test-A && echo test-B.

Observed: ParserError (see Error Messages).

1. Set CLAUDE_CODE_SHELL to the pwsh path as a user environment

variable, reboot the machine, repeat step 3. Nothing changes — Run still
executes powershell.exe 5.1.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude 1.37937.1 (edbd3c) 2026-08-25T22:55:59.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

Related — and why none of them covers this

• #83889 made exactly the two asks above (prefer pwsh.exe when present;

honor the fence language on Run) and quoted this same && parse error. It
was filed as a feature request about the integrated terminal and closed as
a duplicate of #82486 on 2026-08-20 — and #82486 asks only for a
configurable shell for the Terminal pane, so the "prefer pwsh 7 when it is
installed" part died with #83889.

• #82486 (open) — a setting to choose the integrated Terminal pane's shell.
• #61516 (closed not_planned, marked duplicate, locked), #72389 (closed

not_planned as stale), #69375 (auto-closed by the duplicate bot as a
duplicate of #61516): defaultShell / ! prefix / terminal pane. None fixed.

• #25558 — CLAUDE_CODE_SHELL ignored on Windows (closed not_planned,

locked). Consistent with step 5 above: the variable still does nothing.

• #83928 (open) — the PowerShell tool targeting 5.1. Note its reporter

has no pwsh installed, so the tool correctly fell back to 5.1 there. On
this machine pwsh 7 is installed and the tool picks it — which is
precisely why the Run button standing still is the anomaly.

• #78596 (open) — the same hardcoded powershell.exe breaking the pane

outright where 5.1 is blocked by policy.

• The Run button is already triaged as its own surface: #89602 and

#88793 are open Run-button bugs distinct from the pane's other issues.