Resolve Microsoft Store PowerShell App Execution Aliases to their real package executable before ConPTY spawn, while preserving explicit PowerShell choices and the existing fail-safe fallback chain.
* Resolve PowerShell to a real executable so terminals spawn (Windows error code 5)
On Windows, launching a PowerShell terminal could fail with:
Failed to spawn shell "pwsh.exe": Cannot create process, error code: 5
error code 5 = ERROR_ACCESS_DENIED from CreateProcessW inside node-pty's
ConPTY. Orca handed ConPTY a bare family name ("pwsh.exe" /
"powershell.exe"). When pwsh resolved to the Microsoft Store App Execution
Alias stub under WindowsApps (or was blocked by AV/AppLocker/SAC),
CreateProcessW rejected it with access-denied. isPwshAvailable probes via
execFileSync (which DOES follow the alias), so detection and launch disagreed.
Fix: resolve the PowerShell executable to a real absolute path before
spawning, skipping the WindowsApps alias stub, and add a Windows fallback
chain: pwsh (resolved abs) -> Windows PowerShell (System32 abs) -> cmd.exe.
SSH/remote and WSL/Git Bash/cmd paths are unaffected.
Fixes#5161
* test(pty): assert resolved absolute PowerShell path in win32 spawn tests
The PowerShell-resolution fix (#5161) now hands ConPTY a real absolute
executable instead of a bare 'powershell.exe'/'pwsh.exe' family name. The
pre-existing win32 spawn assertions in pty.test.ts (not in the worker's
per-file affected set) still expected the bare names and went red on the
full CI verify suite. Mock the fs seam and pin the install roots the
resolver probes so the resolved path is deterministic on Linux CI and
Windows alike, and assert the resolved System32 / Program Files paths.
* fix(pty): derive Windows shell name with win32 basename for determinism
getForegroundProcess() falls back to the spawned shell's basename when
Windows node-pty reports only the terminal name. The basename was taken
with the host-native path.basename, so on a non-Windows host (Linux CI)
the Windows absolute path 'C:\...\powershell.exe' was not split and the
whole path was stored as the shell name — making getForegroundProcess
return the absolute path instead of 'powershell.exe'. This produced a
host-dependent result for the same forced win32 platform.
Parse the spawned shell basename for the target platform (win32 basename
on Windows, POSIX otherwise), matching the daemon path
(pty-subprocess.ts already uses pathWin32.basename). The win32 spawn
foreground test is now deterministic on Linux CI and Windows alike.
---------
Co-authored-by: brennanb2025 <brennanb2025@users.noreply.github.com>
OrcaWin
Brennan BensonandNeil
