Repository navigation
Default shell ("System default") caches a Store pwsh path for the whole session; every pane fails after a Store PowerShell update #334
Description
What happens
With "Default shell" left at System default, wmux resolves pwsh.exe once at startup and keeps that absolute path in cachedDefaultShell for the lifetime of the process. On a Store-installed PowerShell the resolved path is the versioned package directory behind the App Execution Alias, e.g.
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.7.0_x64__8wekyb3d8bbwe\pwsh.exe
When the Store updates PowerShell while wmux is running, that directory is removed and replaced by a new versioned one. The cached path is never re-validated, so from that moment on every new pane fails with:
[failed to create PTY: Error: Error invoking remote method 'pty:create': Error: Failed to create terminal: File not found: C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.7.0_x64__8wekyb3d8bbwe\pwsh.exe]
Restarting wmux fixes it, until the next PowerShell update.
Expected: a pane create should notice the cached default-shell path is gone and re-resolve it, the same way the per-spec cache already does. resolveExistingShellPath() re-checks a cached hit with fs.existsSync before handing it back (its own comment says this is exactly to avoid feeding a dead path to pty.spawn), but getDefaultShell() returns cachedDefaultShell unconditionally, so the "System default" path has no such protection. The appExecAliasTarget comment also notes that "the alias survives a Store update, the versioned directory does not", but the default-shell cache stores the versioned target rather than the alias spelling.
Suggested fix (either is enough):
- In
getDefaultShell(), re-validatecachedDefaultShellwithexistsSync(orspawnablePath) and re-resolve on a miss, mirroringresolveExistingShellPath(). - Or cache the spec (
pwsh.exe/ the alias path) instead of the resolved versioned exe, and resolve it throughresolveExistingShellPath()on each create so the existing re-validation applies.
Workaround that works today: set Settings → Workspace → Default shell to PowerShell Core (pwsh.exe). That spec goes through resolveShell() → resolveExistingShellPath(), whose cache is re-validated, so panes keep working across Store updates.
Steps to reproduce
- Install PowerShell 7 from the Microsoft Store (not MSI), so
pwsh.exeis only reachable via the App Execution Alias. - In wmux Settings → Workspace, leave "Default shell" at System default. Open a workspace; panes open fine with pwsh.
- While wmux is running, let the Store update PowerShell to a new version (or trigger it via Microsoft Store → Library → Update). Note: the update only completes once no pwsh process from the old package is running, so close existing panes first or wait for the Store to retry.
- Open a new pane (or a new workspace).
- Observe the "File not found: C:\Program Files\WindowsApps\Microsoft.PowerShell__x64__8wekyb3d8bbwe\pwsh.exe" PTY error on every new pane. Restart wmux → panes work again.
In my case the timing was: wmux started 18:01:59, AppX deployment event for the PowerShell package fired at 18:02:00 (the update had been retried three times during the day and only went through when the previous wmux session and its pwsh processes exited). The alias and Get-AppxPackage Microsoft.PowerShell already pointed at 7.6.8 when I inspected them, so only wmux's in-memory cache was stale.
wmux version
2.38.0
Windows version
Windows 11 26300
Anything else
- Shell: PowerShell 7.6.7 → 7.6.8, Store install (
Microsoft.PowerShell_8wekyb3d8bbwe), no MSI install present. settings.jsonhas no shell setting (wmux-workspace-prefs.defaultShellunset → System default); every workspace has"shell": "".session.jsonsurfaces carry"resolvedShell": "...Microsoft.PowerShell_7.6.7.0_x64__8wekyb3d8bbwe\pwsh.exe"— as far as I can tell that is only used for the tab title and gets overwritten on a successful spawn, so it is a symptom, not the cause.- Related: This started happening after I updated powershell a few days ago. #299 (App Execution Alias resolution) and Boot performance #176 (shell path memoization). This report is the one remaining cache that Boot performance #176's re-validation does not cover.
Activity
fix(pty): re-validate the cached System default shell (amirlehmam#334)
fix: inherit the shell only from UI splits and never a resolved path
Inherit the active terminal’s shell for splits and new tabs (#422)