pwsh.exe hardcoded in 6 places - CLI completely unusable on Windows 11 with only PowerShell 5.1 (closed #411 is still broken in v0.0.417)

[guidegdm]

Describe the bug

Issue #411 was closed as "not_planned" in Oct 2025, but the bug is still present and getting worse — it now blocks the CLI from running any shell command at all on Windows machines that ship only with Windows PowerShell 5.1 (powershell.exe).

The error on every single command:

<exited with error: PowerShell 6+ (pwsh) is not available. Please install it from https://aka.ms/powershell (https://aka.ms/powershell). Error: Error: Command failed: pwsh.exe --version 'pwsh.exe' is not recognized as an internal or external command, operable program or file.

Affected version

0.0.417 (also reproducible on 0.0.415, 0.0.414 — any recent version)

Root cause (with exact locations in index.js)

pwsh.exe is hardcoded in 6 places in ~/.copilot/pkg/universal/{version}/index.js.
All 6 must be changed to powershell.exe for the CLI to work on Windows PowerShell 5.1:

#	Pattern	Location
1	process.platform==="win32"?"pwsh.exe":"pwsh"	Shell type detection
(xds function)
2	l?"pwsh.exe":"bash"	PTY spawn (class constructor)
3	Start-Process -FilePath "pwsh.exe"
tryExecuteDetachedCommandWindows (inner PS command)
4	ths("pwsh.exe",["-NoProfile","-Command",I]
tryExecuteDetachedCommandWindows (outer spawn)
5	"pwsh.exe --version"	ensureShellIsSupported version check
6	(one remaining — likely in installer/zip extraction path)	TBD

Proposed fix

Use powershell.exe as the fallback when pwsh.exe is not found:

// Before
process.platform === "win32" ? "pwsh.exe" : "pwsh"

// After — detect what's available
process.platform === "win32" ? (hasExe("pwsh.exe") ? "pwsh.exe" :
"powershell.exe") : "pwsh"

Or simpler: just use powershell.exe (works on both PS 5.1 and PS 7+, both ship  
it).

Why "not_planned" is the wrong call

- Windows 11 ships only with powershell.exe by default. No pwsh.
- powershell.exe is available on every Windows machine going back to Windows 7.
- The CLI already works perfectly once patched — there is no functional dependency on PS 6+.
- This blocks 100% of Windows users on default installs from using the CLI at all.
- Related open issue: #1086

Workaround (until fixed)

Patch ~/.copilot/pkg/universal/{version}/index.js — replace all pwsh.exe → powershell.exe. 
Must be re-applied after each winget upgrade GitHub.Copilot.

[guidegdm]

+1 — and the problem is worse than a one-time fix

I'm hitting all of the same issues described here, plus a compounding set of workflow problems that make the CLI nearly unusable day-to-day on Windows:

1. Auto-updates silently revert the pwsh.exe workaround every single day Every time Copilot CLI auto-updates, the hardcoded pwsh.exe path is restored, breaking shell commands again. There is no setting to persist a custom shell path. The only fix — manually replacing the binary — gets wiped on the next update. This is a daily manual task just to keep the tool functional.

2. No way to specify a shell path in config There should be a user-configurable setting (e.g. shellPath in settings or an env var like COPILOT_CLI_SHELL) so the shell binary can be overridden without touching internal files, and without being reverted on update.

3. Terminal restart / VS Code window reload kills the session entirely When a fix requires restarting the terminal or reloading the VS Code window (which it currently does after each update reverts the binary), the entire Copilot CLI session is lost. Sessions are not persistent across restarts, so all context is gone.

4. Context bank is not reliably auto-updated The CLI is supposed to automatically update the context bank based on session rules, but this is inconsistent — sometimes it does, sometimes it doesn't. Users coming from tools like Claude CLI expect this to work reliably without manually prompting it each session.

Requested fixes:

• Fall back to powershell.exe when pwsh.exe is not found (or detect shell automatically)
• Add a configurable shellPath setting that persists across updates
• Make session context persistent across terminal restarts
• Fix context bank auto-update to be consistent and rule-driven

This is a regression that actively breaks daily workflows. Please reopen or link #411 and treat this as a blocking issue for Windows users.

[SteveSandersonMS]

For context, the reason we've chosen to require PowerShell 6+ is that's what's needed for modern PowerShell syntax, even basic things like && as a command separator.

In our experience when initially implementing PowerShell support, we found that models would very persistently produce scripts that use modern syntax and couldn't be persuaded to use legacy PowerShell syntax. So the effect was that they would write modern scripts, we would try to dispatch them to powershell.exe (legacy), and the user would continually see errors. It was a bad user experience.

We eliminated that problem by requiring PowerShell 6+. It means we can dispatch shell tool calls through pwsh.exe and modern syntax is supported, and model behavior generally works well and feels good to the end user.

To make this even easier for users, we've declared modern PowerShell as a dependency in the winget manifest. So anybody who installs Copilot CLI through winget (our default Windows installation path) should never encounter any issues with this.

So this leaves a question: should we also support legacy PowerShell even if users might get a poorer experience with script errors? And in fact more fundamentally, is it even still true that models do a bad job with legacy PowerShell, or was that only true in the Sonnet 4.5 days and no longer the case with Opus 4.6 etc?

I think we're open to different options here. One thing that would help is understanding more about why it would be important to support legacy PowerShell even though we auto-install modern PowerShell when you install Copilot CLI via winget.

[kripergvg]

I had a clean windows install and even though I had pwsh installed it wasn't in the PATH. Maybe you can consider checking this when installing copilot-cli, otherwise it's a quite frustrating experience seeing cli fails at everything because it can't find pwsh

[jazzdelightsme]

I've had to support and maintain a PS module written mostly in PS script that needed to work in both legacy Windows PowerShell 5.1 (powershell.exe) and modern PowerShell (pwsh.exe). It was a gigantic pain--not only were there many aspects of the user experience that were much worse in legacy PS, but the differences between modern PS and legacy PS only grow larger over time. This module is under constant development, and regressions in legacy PS were always sneaking in, and we had to constantly add workarounds, such as by avoiding really nice new features, or trying to monkey-patch features into legacy PS. When we recently cut off support for 5.1, there was much rejoicing.

I truly feel sympathy for someone who is stuck having to deal with powershell.exe--that's a legitimate situation that many people working in constrained environments have to deal with. But I do not understand how there could be a significant group of people who do have the ability install and use Copilot-CLI but do not have the ability to install pwsh.exe.