Provide a way to associate .ps1 files with PowerShell installed via .msixbundle

Summary of the new feature / enhancement

I am requesting a feature to allow .ps1 file association for PowerShell installed via the .msixbundle package, so that it can be manually selected as the default application.

Related issue: #20039

Proposed technical implementation details (optional)

No response

As I remember powershell/pwsh was never associated with *.ps1

As I remember powershell/pwsh was never associated with *.ps1

My memory was that PS1 files were intentionally not "click and run" by default because of hazards of sending them as a malware. That remains the case and the default is to open them in an editor. It would require quite a big security U turn to change this .

There is a partial association - Windows 11 has "Run with [Windows] PowerShell" as a file manager option and I can't remember if when I installed PowerShell 7 I there was an option to replace that with "Run with PowerShell [7.x]"
Really there should be a "run with PowerShell and leave the window open" for scripts where one wants to see the output.

James O'Neill (@jhoneill)

James O'Neill (@jhoneill), cmd remains the default association for .bat, so that's ridiculous.

@jhoneill, cmd remains the default association for .bat, so that's ridiculous.

Actually @RokeJulianLockhart it isn't quite like that... and you should look up "Chesterton's fence".

With a time machine to go back to about 1981 you could tell Bill Gates, Paul Allen and Time Patterson (who wrote QDOS, later MSDOS) that it was as stupid idea to have .com, .exe and .bat as three different executables that would always run. I'm not 100% sure but I think bat was inherited like so much else from CP/M so maybe you have to go back over 50 years and tell Gary Kildahl.
In Windows, DOS executables, including batch files still ran. OS/2 and the first releases of of Windows NT added .CMD files. You can back to the early 1990s and tell Dave Cutler they were a bad idea.
In the later 1990s Vbscript and Java script files were added to list and if you check the PATHEXT environment variable it still has .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;
There's no need to tell those responsible for Windows 95 / 98 / ME and 2000 that it was a bad idea because they lived through the I Love you virus. https://en.wikipedia.org/wiki/ILOVEYOU
After May 2000 nothing new from Microsoft was going to be allowed to autorun scripts, anything earlier could not not remove auto run without breaking a lot of stuff. Maybe at the time of Windows Vista they could have broken the autorun for BAT and CMD, and it's silly that they can run PowerShell's executable with a script as a parameter.
Logical and consistent ? Nope. But that's how it is. You're welcome to try to get the necessary security U turn. But knowing why the fence is there you're at least in a better position to understand the difficulty of removing it.

ILOVEYOU - Wikipedia

James O'Neill (@jhoneill)

James O'Neill (@jhoneill), having a default file association in the level of the shell is not equivalent to autorun. When software invokes the path of an executable, on some OSes, that doesn't always provide it the authority to invoke it, insofar as its signature differs, especially if the invocation occurs across a packaging boundary. This is also true for scripts.

At least on Linux-based OSes, file associations are solely utilised by high-level applications, insofar as scripts are concerned. I realise that shebangs aren't interpreted by the NT kernel, but Windows's security system is significantly more advanced regardless: If an application attempts to invoke a script that it hasn't signed, I believe that UAC invokes a prompt, as it would for any similar executable.

We can hark back to VMS if we want to relitigate all security decisions that Windows has made. We don't need to; 25H2 isn't the same OS as VMS, OS/2, CP/M, W3.1, 95, 98, 2K, ME, XP, and ≥ Vista.

My previous explanation was incomplete.

To clarify, .ps1 files have never been automatically associated with PowerShell by default. However, manually changing the association is usually straightforward. For PowerShell 7 installed via the .msi installer, the steps are as follows:

Open the Properties of a .ps1 file.
Click the Change... button on the General tab.
In the Select a default app for .ps1 files window, click Choose an app on your PC.
Select C:\Program Files\PowerShell\7\pwsh.exe.

However, because PowerShell installed via .msixbundle behaves differently from traditional applications, this method does not work. I would like this issue to be addressed so that the MSIX version can be manually associated just as easily.

I am opening this issue after reading the following article:
PowerShell MSI package deprecation and preview updates - PowerShell Team
https://devblogs.microsoft.com/powershell/powershell-msi-deprecation/

Beginning with PowerShell 7.7-preview.1 (April 2026), the MSIX package will be the primary installation method for PowerShell on Windows. We will no longer ship the MSI installer package for new PowerShell releases.

For existing releases, including PowerShell 7.6, we will continue to provide MSI packages. However, MSI isn’t planned for future releases, including PowerShell 7.7 GA and beyond.

PowerShell Team
PowerShell MSI package deprecation and preview updates - PowerShell Team
This post announces the deprecation of MSI packaging beginning with PowerShell 7.7.

@RokeJulianLockhart Whatever. You are welcome to try to get Microsoft to change their view that opening a PS1 file in PowerShell automatically would be a security problem. By all means push against that wall and see if it opens.

And no, by default unsigned scripts run normally . UAC is only for applications which need to run with elevated privileges
25H2 is expected to run a batch file which was written for DOS, and any 32-bit or 64-bit executable - I run an unsigned 27 year old Win32 program most days :-)

I believe is the PowerShell team want to implement this property they will need to update the msix manifest's Extensions entry

PowerShell/assets/AppxManifest.xml

Lines 32 to 38 in 1799667

    
           <Extensions> 
        
             <uap3:Extension Category="windows.appExecutionAlias" EntryPoint="Windows.FullTrustApplication" Executable="pwsh.exe"> 
        
               <uap3:AppExecutionAlias> 
        
                 <desktop:ExecutionAlias Alias="pwsh.exe" /> 
        
               </uap3:AppExecutionAlias> 
        
             </uap3:Extension> 
        
           </Extensions>

This should include the uap:FileTypeAssociation

<uap:Extension Category="windows.fileTypeAssociation">
  <uap:FileTypeAssociation Name="Microsoft.$PRODUCTNAME$">
    <uap:DisplayName>$DISPLAYNAME$</uap:DisplayName>
    <uap:Logo>assets\StoreLogo.png</uap:Logo>
    <uap:SupportedFileTypes>
      <uap:FileType>.ps1</uap:FileType>
    </uap:SupportedFileTypes>
  </uap:FileTypeAssociation>
</uap:Extension>

There may be some other elements like uap:EditFlags or uap:InfoTip that may be helpful to be used with PowerShell.

Whether the pwsh team want to do so is a question for them but without the user would have to select the exe inside C:\Program Files\WindowsApps which is restricted for admin users and requires some trickery to access.

but without the user would have to select the exe inside C:\Program Files\WindowsApps which is restricted for admin users and requires some trickery to access.

The right answer is to point to the app execution alias, not the packaged exe => %LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe

Assuming this is the default app associated with .ps1 AND the app execution alias isn't disabled (Settings' Apps > Advanced app settings > App execution aliases). If this is of concern you're better off pointing to C:\Users\howard\AppData\Local\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe\pwsh.exe. The packagefamily subdir containing the alias .exe always exists, it's only the parent directory that's affected by alias name collisions and enabled/disabled.

The right answer is to point to the app execution alias, not the packaged exe => %LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe

I tried that when I first posted my comment but Windows didn't like it

The app exec alias works normally and can be launched to open pwsh.exe, it just seems like the explorer picker for a default app won't allow you to choose that. When searching online it seems like the MSIX package needs to register the extension it supports so the default app picker can show it in the normal list.

If it helps I rebuilt the pwsh MSIX package with the extension I shared above and it now appears as a choice in the default app picker.

This is linked to this discussion #19870 & this issue #20039 as store installs use the msixbundle package, but as there is more useful info in this issue, I have closed #20039 as a duplicate of this one.

If it helps I rebuilt the pwsh MSIX package with the extension I shared above and it now appears as a choice in the default app picker.

This is the expected behavior I'm looking for. I hope this gets implemented.

Hi all,

how can users adjust such approach for MSIX based PowerShell 7 or later?

Windows Registry Editor Version 5.00

; Add "Run with PowerShell 7 (Admin)" for .ps1 files
[HKEY_CLASSES_ROOT\SystemFileAssociations\.ps1\shell\RunWithPwsh7Admin]
@="Run with PowerShell 7 (Admin)"
"HasLUAShield"="yes"
"Icon"="pwsh.exe"

[HKEY_CLASSES_ROOT\SystemFileAssociations\.ps1\shell\RunWithPwsh7Admin\command]
@="powershell.exe -Command \"Start-Process 'pwsh.exe' -ArgumentList '-NoExit', '-File', '\\\"%1\\\"' -Verb RunAs\""`

MSI based Powershell resided in a fixed path 'c:\program files\Microsoft PowerShell\7\'
MSIX however has a version specific home 'c:\program Files\WindowsApps\Microsoft.PowerShell_versionnumber_8wekyb3d8bbwe

Status Quo:
✅ I can call pwsh globally.
❌ The path is not retrieveable for icons.

Affected:

Registry > context menu

Microsoft Terminal is able to fetch it somehow, so I hope there is a feasible solution:

I've opened the PR #27875, hopefully the team/WG can have a look through that and either accept/reject it.

Navigation Menu

Repository navigation

Provide a way to associate `.ps1` files with PowerShell installed via `.msixbundle` #27277

Summary of the new feature / enhancement

Proposed technical implementation details (optional)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	<Extensions>
	<uap3:Extension Category="windows.appExecutionAlias" EntryPoint="Windows.FullTrustApplication" Executable="pwsh.exe">
	<uap3:AppExecutionAlias>
	<desktop:ExecutionAlias Alias="pwsh.exe" />
	</uap3:AppExecutionAlias>
	</uap3:Extension>
	</Extensions>

Provide a way to associate .ps1 files with PowerShell installed via .msixbundle #27277

Description

Summary of the new feature / enhancement

Proposed technical implementation details (optional)

Activity

237dmitry commented on Apr 16, 2026

jhoneill commented on Apr 16, 2026

beedell-roke commented on Apr 16, 2026

jhoneill commented on Apr 16, 2026

beedell-roke commented on Apr 16, 2026

sincos2854 commented on Apr 16, 2026

jhoneill commented on Apr 16, 2026

jborean93 commented on Apr 24, 2026

DrusTheAxe commented on May 16, 2026

jborean93 commented on May 16, 2026

jborean93 commented on May 16, 2026

kilasuit commented on May 16, 2026

sincos2854 commented on May 16, 2026

Karl-WE commented on Aug 10, 2026

jborean93 commented on Aug 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Provide a way to associate `.ps1` files with PowerShell installed via `.msixbundle` #27277