PowerShell 7 is moving to MSIX packaging as part of the inboxing initiative. This issue tracks all known gaps between MSIX-packaged PS7 and the full capability set customers depend on today.

Each sub-issue below is a discrete gap with its own engineering scope. This issue will remain open until all blockers are resolved.

🔴 Blocker — System Context: pwsh invisible to automation

MSIX packages register per-user only. The SYSTEM account, LocalSystem, and service identities cannot locate or invoke pwsh, breaking any automation that doesn't run as an interactive user.

• [NEW] PS7-packaged: pwsh not discoverable in SYSTEM / LocalSystem context #27562 — PS7-packaged: pwsh not discoverable in SYSTEM / LocalSystem context
  Covers: scheduled tasks as SYSTEM, Windows Services, MDM scripts (Intune/ConfigMgr), deployment agents.

• [NEW] PS7-packaged: WinRM / PowerShell Remoting broken under MSIX #27563 — PS7-packaged: WinRM / PowerShell Remoting broken under MSIX
  The WinRM plugin (pwrshplugin.dll) has ACL and registration requirements incompatible with the per-user MSIX model.

🔴 Blocker — DISM API: Windows Capability commands fail from PS7

Add-WindowsCapability, Get-WindowsOptionalFeature, and related DISM cmdlets fail with "Class not registered" when called from MSIX-packaged PS7. This breaks on-device setup and configuration scripts for OpenSSH, WSL, App SDK, and similar.

• [EXISTING] Get-WindowsOptionalFeature -Online fails on PowerShell from MSIX installation - [Get-WindowsOptionalFeature: Class not registered] #13866 — Get-WindowsOptionalFeature -Online fails on MSIX PS7

🟡 Enterprise Configuration: PS7 cannot write its own config

$PSHome is read-only under MSIX. Session configuration, machine-wide profiles, updatable help, and any tooling that writes to PS7's home directory fails with access denied or silently does nothing.

Solution substrate: an admin-writable, all-users-readable per-machine data store ("MachineFolder"). Design and rollout:

• [NEW] [Design] MachineFolder: a per-machine writable data store for MSIX-packaged PowerShell #27697 — [Design] MachineFolder: a per-machine writable data store for MSIX-packaged PowerShell — shared mechanism; system-wide config relocation implemented in PR Place System-Wide Config in the Machine Folder for MSIX Packages #27632.

• [EXISTING] Some cmdlets and config require writing to $PSHOME\SessionConfig folder #9278 — Register/Set-PSSessionConfiguration write .pssc to $PSHome\SessionConfig — narrowed to the SessionConfig write-location (WinRM/remoting activation is tracked in PS7-packaged: WinRM / PowerShell Remoting broken under MSIX #27563).

• [NEW] PS7-packaged: $profile.AllUsersAllHosts not writable by administrators #27564 — PS7-packaged: $profile.AllUsersAllHosts not writable by administrators
  Admins cannot write the machine-wide profile — a common enterprise configuration pattern.

• [NEW] PS7-packaged: Update-Help -Scope AllUsers fails under MSIX ($PSHOME read-only) #27699 — PS7-packaged: Update-Help -Scope AllUsers fails under MSIX ($PSHome read-only)

• [NEW] PS7-packaged: provide a cmdlet to export the fully merged / effective configuration #27698 — PS7-packaged: provide a cmdlet to export the fully merged / effective configuration

🟡 Server Core

MSIX packages cannot register/activate on Windows Server Core. See #27610 for root cause and fix direction.

• PS7-packaged: Server Core cannot register/activate MSIX packages #27610

🟢 Other confirmed gaps (tracked, not on critical path)

• [EXISTING] Provide a way to associate .ps1 files with PowerShell installed via .msixbundle #27277 — .ps1 file association broken with MSIX install
• [EXISTING] Return a more actionable error description when the user attempts to write to an MSIX-installation's root. #25733 — No actionable error when writing to MSIX root (silent failure → should be a clear error)

Status

We are committed to resolving the blocker gaps before PS7 ships as the inbox shell. Updates will be posted to each individual issue as progress is made.