DefaultShell and app exec alias support

Summary of the new feature / enhancement

As a user I want to set my DefaultShell to an MSIX packaged application, like PowerShell 7, and have that work.

With PowerShell 7.7+ moving towards only being packaged as an MSIX application the entrypoint for pwsh.exe is no longer in a machine wide location C:\Program Files\PowerShell\7\pwsh.exe but rather an app exec alias for the end user under $env:LocalAppData\Microsoft\WindowsApps\pwsh.exe. It is not possible to set DefaultShell to this user specific path in a user agnostic manner and only works if you hardcode the full path, including the username.

Path valeus I've tried

• C:\Users\username\AppData\Local\Microsoft\WindowsApps\pwsh.exe - works but hardcoded to specific user

This works but as it's hardcoded to a specific user it's not really a viable option.

• pwsh.exe and relying on PATH - fails, sshd uses pwsh.exe as the full path

2720 2026-08-05 11:55:46.790 User domain\\vagrant-domain not allowed because shell pwsh.exe does not exist

• Cmd style env vars %LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe - fails, literal value is used as the shell path

7212 2026-08-05 12:00:43.641 User domain\\vagrant-domain not allowed because shell %localappdata%\\microsoft\\windowsapps\\pwsh.exe does not exist

• Pwsh style env vars $env:LOCALAPPDATA\Microsoft\WindowsApps\pwsh.exe - fails, literal value is used

7140 2026-08-05 12:02:21.065 User domain\\vagrant-domain not allowed because shell $env:localappdata\\microsoft\\windowsapps\\pwsh.exe does not exist

• Symlink in machine wide location pointing to user exe - fails, does not seem to follow symlink

5424 2026-08-05 12:11:02.191 User domain\\vagrant-domain not allowed because shell c:\\windows\\temp\\pwsh-test.exe does not exist

Even so symlinks on Windows do not seem to support env vars as a target normall, they are either relative or absolute paths.

Proposed technical implementation details (optional)

I'm not sure how exactly this should work or be configured but I could see the following options

• PATH lookup if DefaultShell is not absolute
  • Can't say I'm the biggest fan as now you are susceptible to PATH hijacking
• Support cmd style env var so DefaultShell %LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe works
  • A bit unweilding to configure but seems to be more common practice to use this style
  • ExpandEnvironmentStringsW in the context of the target user could do this
• Support special prefix like AppExecAlias:\pwsh.exe and replace prefix with the user's WindowsApps path
  • Limits special substitution and environment lookups to these special aliases
  • May be too magical

I know there is work going on to support SYSTEM support for MSIX packages but I don't know what that actually looks like and how it interacts with a user provisioned MSIX package but may be something to keep in mind.

Start by tracing how sshd validates and launches the configured DefaultShell for the target user. Reproduce the listed pwsh.exe, environment-variable, and symlink cases, then compare the proposed PATH lookup, environment expansion, and AppExecAlias approaches. Done means an agreed configuration works for a user-installed MSIX shell without hardcoding a username.