Repository navigation
Provide a way to associate .ps1 files with PowerShell installed via .msixbundle #27277
Description
Activity
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.Reacted by Mr Beedell, Roke Julian LockhartJames O'Neill (@jhoneill),
cmdremains the default association for.bat, so that's ridiculous.Reacted by Matthew Gray, Mr Beedell, Roke Julian Lockhart and Yang Yang@jhoneill,
cmdremains 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.Reacted by masterflitzerReacted by Mr Beedell, Roke Julian LockhartJames 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,
.ps1files have never been automatically associated with PowerShell by default. However, manually changing the association is usually straightforward. For PowerShell 7 installed via the.msiinstaller, the steps are as follows:- Open the
Propertiesof a.ps1file. - Click the
Change...button on theGeneraltab. - In the
Select a default app for .ps1 fileswindow, clickChoose an app on your PC. - Select
C:\Program Files\PowerShell\7\pwsh.exe.
However, because PowerShell installed via
.msixbundlebehaves 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
This post announces the deprecation of MSI packaging beginning with PowerShell 7.7.Reacted by Mr Beedell, Roke Julian Lockhart and thekovic- Open the
@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 :-)Reacted by JAK1047 and Mr Beedell, Roke Julian LockhartI believe is the PowerShell team want to implement this property they will need to update the msix manifest's
ExtensionsentryPowerShell/assets/AppxManifest.xml
Lines 32 to 38 in 1799667
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\WindowsAppswhich is restricted for admin users and requires some trickery to access.Reacted by Mr Beedell, Roke Julian Lockhart, Howard Kapustein and Karl Wester-Ebbinghausbut without the user would have to select the exe inside
C:\Program Files\WindowsAppswhich 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.exeAssuming 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.
Reacted by Ryan Yates- marked Install from the Store does not seem to allow for PowerShelI to be associated with .ps1 files #20039 as a duplicate of this issue
on May 16, 2026 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.
Reacted by Mr Beedell, Roke Julian Lockhart and thekovicHi 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_8wekyb3d8bbweStatus 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.
Reacted by Karl Wester-Ebbinghaus
Summary of the new feature / enhancement
I am requesting a feature to allow
.ps1file association for PowerShell installed via the.msixbundlepackage, so that it can be manually selected as the default application.Related issue: #20039
Proposed technical implementation details (optional)
No response