Hardcoded legacy Windows PowerShell (powershell.exe) causes runtime failures and degraded UX

[Charlweed]

Before submitting your bug report

• I've tried using the "Ask AI" feature on the Continue docs site to see if the docs have an answer
• I'm not able to find a related conversation on GitHub discussions that reports the same bug
• I'm not able to find an open issue that reports the same bug
• I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS:Windows
- Continue version:1.545
- IDE version:
- Model:
- config:
  

  
  OR link to agent in Continue hub:

Description

Problem Statement

The codebase currently contains multiple hardcoded invocations of powershell.exe or the legacy powershell command. These specifically target Windows PowerShell 5.1, which is legacy software that no longer receives feature updates.

Modern PowerShell development, including scripts often generated or expected by modern developer tools, focuses heavily on PowerShell Core (pwsh) 6+. PowerShell Core is cross-platform and contains significant language features, performance improvements, and syntax changes not present in version 5.1.

Impact & Friction

1. Unpredictable and Silent Failures: Running modern PowerShell Core scripts in legacy PowerShell will frequently fail. Because PowerShell 5.1 lacks newer language features (e.g., ternary operators, pipeline chain operators like && and ||, or modern JSON parsing), the execution will fail in ways that are difficult to diagnose. The errors often present as obscure syntax or parsing errors within a sub-shell, obscuring the root cause (a version mismatch).
   

2. Uncorrectable by the End User: Because the powershell invocation is hardcoded deep within the application logic (such as in clipboard utilities or terminal command execution), this issue is entirely uncorrectable by the end user. Even if a user has explicitly installed PowerShell Core and set it as their default terminal, the application bypasses this configuration and forces the legacy binary.
   

3. Cross-Platform Inconsistency: Hardcoding powershell.exe makes the execution logic strictly Windows-centric. While non-Windows platforms generally default to pwsh or bash, having fragmented fallback paths leads to inconsistent behaviors and duplicated logic across different extensions and core utilities.
   

Proposed Solution

Implement a centralized, dynamic detection utility that:

1. Prefers pwsh (PowerShell Core) if it is available in the system environment.
   

2. Falls back to legacy powershell only as a secondary option on Windows to maintain backward compatibility for systems without Core installed.
   

3. Consolidates this detection into a single source of truth to eliminate duplicated checks across the CLI and IDE extensions.
   

Note that PowerShell Core (pwsh) is "generally" backwards compatible, and failures center around reliance on Windows-Only OS features. Because PowerShell core supports the "#Requires" construct, which is typically included in scripts that require legacy PowerShell, failures due to backwards incompatibility are very rare.

To reproduce

Create bug_demo.ps1:

# demo.ps1
$version = $PSVersionTable.PSVersion.Major
$result = $version -ge 7 ? "Modern PowerShell $version ✓" : "Legacy"
Write-Host $result

Tell Continue to execute the script. Continue will use 'powershell.exe'
Script fails with Unexpected token '?' in expression or statement., but this is a best-case scenario. There's no workaround — powershell.exe simply cannot parse the file, and reports an error.

A task can invoke at statement like this: ([System.Text.Encoding]::Default.GetBytes("€")).Count. Legacy PowerShell is strictly ASCII, and it silently replaces Unicode with '?'. This kind of statement silently corrupts filenames, prices, config values, or log entries containing any non-ASCII character — which includes most of the world's currencies, names, and languages

Log output