Getting error of shell core not able to start

I concluded that windows PowerShell Core sessions fail to start because Warp is launching the WindowsApps pwsh.exe path and Windows rejects the PTY child process creation with 0x80070542..

Triage summary

This is a Windows shell-startup bug affecting PowerShell Core sessions. The screenshot shows Warp attempting to launch C:\Users\...\AppData\Local\Microsoft\WindowsApps\pwsh.exe and the Windows PTY spawn path failing with 0x80070542 (Either a required impersonation level was not provided, or the provided impersonation level is invalid).

The report is likely a regression despite the template's Regression: No selection: the issue body lists a recent working date of 2026-10-19, and the triggering follow-up says it was working before. That justifies keeping this high priority.

Likely root cause

The most plausible current-code path is:

• crates/warp_util/src/path/windows.rs includes %LOCALAPPDATA%\Microsoft\WindowsApps in the PowerShell 7 search paths.
• app/src/terminal/available_shells.rs and crates/warp_terminal/src/local_tty/shell.rs convert the resolved pwsh.exe into a direct PowerShell shell starter.
• crates/warp_terminal/src/local_tty/windows/mod.rs passes that command to CreateProcessW with ConPTY startup attributes.
• app/src/terminal/view/shell_terminated_banner.rs surfaces the resulting CreateShellProcessFailed error as the red Shell process could not start! banner.

The remaining ambiguity is why the user's non-Store PowerShell 7 install is not being selected over the WindowsApps alias, or whether a persisted shell setting still points at the alias.

Duplicate check

I checked all open issues via the GitHub API. #6165 is a broad Windows shell-process creation failure, and #12871 involves a persisted WindowsApps pwsh.exe path, but I did not find two existing open issues matching this exact 0x80070542 impersonation failure. This should not be marked duplicate yet.

Needed from reporter

The next useful evidence is the exact local pwsh resolution order and Warp logs from a failed launch, so maintainers can tell whether this is shell discovery, persisted settings, or a Windows app-execution-alias launch-context failure.

Question reasoning

1. Can you attach redacted Warp logs from immediately after this banner appears, especially any shell selection or PTY spawn lines? — The logs are needed to confirm whether Warp chose the WindowsApps alias from shell discovery, from a persisted shell preference, or from another launch path.
2. From another terminal, what is the redacted output of where.exe pwsh, and which exact non-Store pwsh.exe path do you expect Warp to use? — This user-specific PATH/order information is needed because the screenshot shows Warp using the WindowsApps alias even though the reporter says non-Store PowerShell 7 is installed.

I concluded that windows Warp stable can fail to start the shell core when opening terminal or agent windows after restart, and the reporter later restored startup by deleting stale local *-User state files..

Duplicate reasoning

• #16567: Same reporter, Windows platform, same Warp stable release family, and the same terminal/session startup failure when opening a Warp session.
• #15784: Also reports Windows Warp sessions where local shells do not start and remain stuck in the shell-startup state, matching the core failure surface.