PowerShell MSIX pwsh.exe returns Access Denied when launched by multiple terminal applications

Prerequisites

Write a descriptive title.
Make sure you are able to repro it on the latest released version
Search the existing issues.
Refer to the FAQ.
Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Install PowerShell 7.6.6 using WinGet:

winget install --id Microsoft.PowerShell

The WinGet package installs the MSIX variant. Verify that pwsh.exe resolves through the Windows App Execution Alias:

where.exe pwsh
(Get-Command pwsh).Source

Expected result:

C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

Open Windows Terminal and start PowerShell 7:

pwsh

Leave the PowerShell session running.

Open GitHub Copilot App and open a terminal in a project/worktree.

GitHub Copilot App attempts to launch PowerShell using a command similar to:

C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\pwsh.exe --nologo -ExecutionPolicy Bypass -NoExit -Command ". '<path>\terminal-integration\shellIntegration.ps1'"

The GitHub Copilot terminal fails to start with:

Failed to spawn PTY command: CreateProcessW ... failed: Access is denied. (os error 5)

The reverse sequence also reproduces the problem. If the GitHub Copilot terminal is started first, then attempting to launch PowerShell from Windows Terminal fails with:

[error 2147942405 (0x80070005) when launching "C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\pwsh.exe" --nologo]

Remove the MSIX installation and install the MSI version of the same PowerShell release:

winget uninstall --id Microsoft.PowerShell

Then install the MSI package of PowerShell 7.6.6.

winget install --id Microsoft.PowerShell --source winget --installer-type wix

After installation:

where.exe pwsh

resolves to:

C:\Program Files\PowerShell\7\pwsh.exe

Repeat the same Windows Terminal ↔ GitHub Copilot App test.

Both applications can now launch independent PowerShell processes concurrently without errors.

The PowerShell version remains 7.6.6 in both cases, so the difference is the installation/package type and executable path rather than the PowerShell version itself.

Expected behavior

Independent terminal applications should be able to launch separate PowerShell processes concurrently within the same Windows user session.

An existing PowerShell process launched by one terminal application should not prevent another terminal application from creating a new `pwsh.exe` process.

The MSIX/App Execution Alias at:


%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe


should behave equivalently to the normal PowerShell executable when used to create independent processes.

Actual behavior

When PowerShell 7.6.6 is installed as the MSIX package, launching `pwsh.exe` from a second terminal application fails with `ERROR_ACCESS_DENIED (5)` / `0x80070005` if another terminal application already has an MSIX-installed PowerShell process running.

The failure occurs in both directions:

* Windows Terminal → GitHub Copilot App: Copilot fails to create the PowerShell process.
* GitHub Copilot App → Windows Terminal: Windows Terminal fails to create the PowerShell process.

The failure occurs before PowerShell starts executing commands. In the GitHub Copilot case, `CreateProcessW` fails while attempting to create the process, so `shellIntegration.ps1` is not reached.

Installing the MSI version of the exact same PowerShell release changes the executable to:


C:\Program Files\PowerShell\7\pwsh.exe


and the problem disappears. Windows Terminal and GitHub Copilot App can then run PowerShell simultaneously.

This makes the MSIX/App Execution Alias path a significant differentiating factor in the reproduction.

Error details

GitHub Copilot App:


Failed to spawn PTY command: CreateProcessW `"C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\pwsh.exe --nologo -ExecutionPolicy Bypass -NoExit -Command ". '<path>\terminal-integration\shellIntegration.ps1>'"` failed: Access is denied. (os error 5)


Windows Terminal:


[error 2147942405 (0x80070005) when launching "C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\pwsh.exe" --nologo]


The important error is:


ERROR_ACCESS_DENIED (5)
0x80070005


The error is returned while creating the process rather than from a PowerShell command executed inside the new process.

Environment data

PS> $PSVersionTable | Format-List

Name  : PSVersion
Value : 7.6.6

Name  : PSEdition
Value : Core

Name  : GitCommitId
Value : 7.6.6

Name  : OS
Value : Microsoft Windows 10.0.26200

Name  : Platform
Value : Win32NT

Name  : PSCompatibleVersions
Value : {1.0, 2.0, 3.0, 4.0…}

Name  : PSRemotingProtocolVersion
Value : 2.4

Name  : SerializationVersion
Value : 1.1.0.1

Name  : WSManStackVersion
Value : 3.0


MSIX installation:


PS> where.exe pwsh
C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\pwsh.exe

PS> (Get-Command pwsh).Source
C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\pwsh.exe


The MSIX package was installed using WinGet:


winget install --id Microsoft.PowerShell


After replacing the MSIX installation with the MSI installation of the same PowerShell 7.6.6 release:


winget install --id Microsoft.PowerShell --source winget --installer-type wix



PS> where.exe pwsh
C:\Program Files\PowerShell\7\pwsh.exe


The MSI installation does not exhibit the concurrent-launch failure.

Visuals

No response

Related issues

There are several related reports involving PowerShell's MSIX/App Execution Alias and pwsh.exe under %LOCALAPPDATA%\Microsoft\WindowsApps:

#27565 — Tracking: MSIX packaging gaps for PowerShell 7
#27603 — PowerShell from Microsoft Store is causing problems on Codex
github/app#2820 — Terminal failed to start with "Access is denied"
microsoft/terminal#20201 — error 0x80070780 when starting pwsh.exe
openai/codex#38222 — Windows sandbox: restricted token cannot enumerate or execute under the user profile

Windows Terminal #20201 is particularly relevant because it involves PowerShell launched through the MSIX App Execution Alias on Windows build 26200, and a Terminal maintainer specifically identified the App Execution Alias as a likely culprit.

The failure described in this report is different: it occurs during normal process creation between independent terminal applications when one PowerShell process is already running. The same PowerShell 7.6.6 installation works correctly when installed via MSI, where pwsh.exe resolves to C:\Program Files\PowerShell\7\pwsh.exe.

I am not assuming these reports have the same root cause, but the shared MSIX/App Execution Alias path and process-launch failures may be related.

This might be related to PowerShell/Win32-OpenSSH#2450. It's a problem I've seen someone report where Windows fails to "activate" the MSIX package on startup when a different logon session started it but I was never able to replicate it myself.

You could see if there are any errors during activation that might indicate what went wrong but I would be surprised if it actually told you why rather than a generic access denied error.

Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' -MaxEvents 10 -ErrorAction Ignore |
    Where-Object LevelDisplayName -eq 'Error' | Select-Object -First 3 |
    ForEach-Object { "$($_.TimeCreated.ToString("yyyy-MM-ddThh:mm:ss.f")) - $($_.Message -replace '\s+', ' ')" }

I assume it's somewhat related due to the AI tools potentially trying to start PowerShell in a sandbox like environment which could change the logon session aligning with how SSH works but that's a guess. It may not be related at all.

Thanks for the suggestion. I tried the original command, but it returned no output. I also modified it to inspect more of the recent AppModel-Runtime events.

Most of the events returned were informational events (IDs 201, 210, 211, 217 and 219) related to the ohmyposh.cli package. I haven't found any errors mentioning Microsoft.PowerShell or anything that clearly corresponds to the failed pwsh.exe launch.

So far, I haven't been able to identify a relevant activation error in the event log. This doesn't necessarily rule out an MSIX activation issue, but I don't have log evidence confirming it.

The original reproduction is still consistent: with PowerShell 7.6.6 installed as MSIX, launching it from a second terminal application fails with ERROR_ACCESS_DENIED (5) / 0x80070005; installing the MSI version of the same release resolves the issue completely.

Curious if the problem still persists if ohmyposh was uninstalled. I don't really know how Oh My Posh actually works and if it potentially tries to manipulate anything inside $PSHome which will not work for an MSIX application. If it modifies anything in there or adds anything new it will break the consistency and verification work that MSIX does on activation. It is most likely completely unrelated but might be a good thing to verify just in case.

I wish I could help debug the problem but so far I've just not been able to replicate it myself

If it helps these are the ETW/event traces for launching pwsh.exe. I ran the following in an existing pwsh.exe session after installing PSEtw and Yayaml then in another process running as cmd/powershell.exe I had it ran pwsh.exe -Command '$pid' to replicate launching PowerShell 7.

# Wait 2 or 3 seconds after running before launching the new `pwsh.exe`
Trace-PSEtwEvent -Provider Microsoft-Windows-AppModel-Runtime -KeywordsAny * -Level * |
    Select-Object ProcessId, KeywordNames, EventMessage, Properties |
    ConvertTo-Yaml -AsArray -Stream -WarningAction Ignore

# pwsh -Command '$pid'  -> 7548
- ProcessId: 6528
  KeywordNames:
  - Process
  EventMessage: Performing app integrity check for package Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe.
  Properties:
  - PackageFullName=Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe
- ProcessId: 6528
  KeywordNames:
  - Process
  EventMessage: Checking package graph for Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe.
  Properties:
  - PackageFullName=Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe
- ProcessId: 6528
  KeywordNames:
  - Process
  EventMessage: Package graph check for Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe finished with 0.
  Properties:
  - ErrorCode=0
  - PackageFullName=Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe
- ProcessId: 6528
  KeywordNames:
  - Process
  EventMessage: App integrity check for package Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe finished with 0.
  Properties:
  - ErrorCode=0
  - PackageFullName=Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe
- ProcessId: 6448
  KeywordNames:
  - DesktopAppXContainer
  EventMessage: Added process 7548 to Desktop AppX container 75dbbb49-c66d-11f1-b75c-960750da46bd for package Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe.
  Properties:
  - ProcessID=7548
  - PackageName=Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe
  - ContainerId=75dbbb49-c66d-11f1-b75c-960750da46bd
- ProcessId: 6448
  KeywordNames:
  - DesktopAppXProcess
  EventMessage: Created process 7548 for application Microsoft.PowerShell_8wekyb3d8bbwe!App in package Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe. [FinishPackageActivation]
  Properties:
  - ProcessID=7548
  - PackageName=Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe
  - ImageName=pwsh.exe
  - ApplicationName=Microsoft.PowerShell_8wekyb3d8bbwe!App
  - Message=[FinishPackageActivation]

An unexpected update: I can no longer reproduce the issue.

I retested the MSIX installation with both PowerShell 7.6.6 and 7.6.7, but the ERROR_ACCESS_DENIED (5) error no longer occurs when launching PowerShell from Windows Terminal and GitHub Copilot App, even when one already has a PowerShell session running.

I'm not sure what changed, as I haven't identified a specific action or system change that would explain why the issue stopped occurring. I also haven't confirmed whether Oh My Posh is related, so I can't rule that out yet.

Previously, I could reproduce the problem consistently with MSIX, and switching to the MSI installation of the same PowerShell 7.6.6 release resolved it. Now, however, I haven't been able to reproduce the original behavior again.

I'll keep this issue updated if I can reproduce it again or identify what changed.

An unexpected update: I can no longer reproduce the issue.

I retested the MSIX installation with both PowerShell 7.6.6 and 7.6.7, but the ERROR_ACCESS_DENIED (5) error no longer occurs when launching PowerShell from Windows Terminal and GitHub Copilot App, even when one already has a PowerShell session running.

I'm not sure what changed, as I haven't identified a specific action or system change that would explain why the issue stopped occurring. I also haven't confirmed whether Oh My Posh is related, so I can't rule that out yet.

Previously, I could reproduce the problem consistently with MSIX, and switching to the MSI installation of the same PowerShell 7.6.6 release resolved it. Now, however, I haven't been able to reproduce the original behavior again.

I'll keep this issue updated if I can reproduce it again or identify what changed.

probably PSES 1.1 related, which shipped with the W11 September Preview Update (and thus also the October Update). The new VSCode and Copilot CLI/SDK Sandbox relies on MXC which in turn relies on PSES 1.1. AND it doesn't work quite right without PowerShell 7.7… feels a bit like a catch-22 given 7.7 ain't GA.

Also, I feel like this thread here confabulates AppInstaller (which can install MSIX as system, as an good Intune Admin from having to deploy Company Portal as SYSTEM knows) capabilities and winget, which uses AppInstaller, capabilities.

Navigation Menu

Repository navigation

PowerShell MSIX pwsh.exe returns Access Denied when launched by multiple terminal applications #28117

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Related issues

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

PowerShell MSIX pwsh.exe returns Access Denied when launched by multiple terminal applications #28117

Description

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Related issues

Activity

jborean93 commented on Sep 28, 2026

xdeleon04 commented on Oct 12, 2026

jborean93 commented on Oct 13, 2026

xdeleon04 commented on Oct 14, 2026

no-identd commented on Oct 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions