Repository navigation
Some cmdlets and config require writing to $PSHOME\SessionConfig folder #9278
Description
Activity
- changed the title
[-]Register-PSSessionConfiguration requires writing to $PSHOME\SessionConfig folder[/-][+]Some cmdlets and config require writing to $PSHOME\SessionConfig folder[/+]on Apr 3, 2019 Long time Windows exposes UAC virtualization for registry keys and file system.
If we could use it it would solve this problem.Ilya (@iSazonov) that would potentially work for Windows, but doesn't solve the same problem with Snaps.
Reacted by Mr Beedell, Roke Julian LockhartI like the way for Windows. I think it is right way.
I guess there is a solution in Snaps too - PowerShell is not single application with such behavior. My quick search https://forum.snapcraft.io/t/snap-layouts/7207 "Creating new files and directories in read-only spaces". So I believe Snaps has that we need.Reacted by Flavien MICHALECZEKWhat parts of snap would we map? Just because we can, doesn't mean we should. We should not make any part of $PSHome writable on linux.
Reacted by Maxwell Bloch and ExE Boss- Reacted by Travis PlunkReacted by Mr Beedell, Roke Julian Lockhart
Can we just use
/etc/for this? Or does Snap "classic" et al not have a way to do this?Joey Aiello (@joeyaiello) The problem is this should be done in PowerShell.
/etcis where the file should be for all PowerShell installations.Reacted by ExE Boss and Rain Sallow (/u/ta11ow)For reference #4080
Known locations that write into $PSHOME - In-progress
Item Location CurrentUser Version exists Resolution Register-PSSessionConfiguration$PSHOME\SessionConfig? Update-Help -scope currentuser$pshome\powershell.config.jsonYes (buggy #7452)Fixed in 7.0.0 Update-Help -scope AllUsers$PSHome\en-USYes Enable-ExperimentalFeature -Scope AllUsers$pshome\powershell.config.jsonYes Set-ExecutionPolicy -Scope LocalMachine$pshome\powershell.config.jsonYes Proposal
Rational
It looks like the majority of the problem is writing to the configuration file. We should move it under
/etcfor Linux and macOS, and `%programdata% for Windows.We can make similar changes for
$PSHome\SessionConfigand$PSHome\en-US(and related folders) later.Details
Security
These folders should be secured similarly to the currently location the file is located at when the product is installed via DEB, RPM, or MSI.
The configuration file is system wide configuration and only system administrators should be able to modify it. This also eliminates pwsh creating it on first launch.
Linux and macOS
We would move the system configuration to
/etc/powershell/powershell.config.json
We would use the folder so that any addition items will be group together.Packages would have to be updated to create this and the zip instruction would have to be update or a script created.
Windows
We would move the system configuration to
%programdata%\Microsoft\PowerShell\powershell.config.jsonMSI could be update to create the file.
MSIX - Steve Lee (@SteveL-MSFT)?
zip - instructions would have to be updatedIssues
- What do you do on upgrade? Currently we overwrite the file, but this is not the correct behavior.
- Not sure how to set the default config after MSIX install.
- Possible solution is to include a script that admins can run after install. This would simplify zip and tar.gz install as well.
For PowerShell.config.json, it might be better to have cmdlet(s) to manage that file with
-Scope AllUsers/CurrentUser. This would work cross-platform.Reacted by ExE Boss, Ryan Yates and Craig E. SheaReacted by Travis Plunk41 remaining items
I encountered this issue with the
Set-ExecutionPolicyCmdlet just this week. So from my point of view, it's still relevant.Reacted by Bryan DadyI'm having the problem of not being able to
Set-ExecutionPolicybecause it tries to modifypowershell.config.jsonin the Appx installation directory. This happens on an Administrator Powershell prompt:>Set-ExecutionPolicy RemoteSigned Set-ExecutionPolicy: Access to the path 'C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.0.0_x64__8wekyb3d8bbwe\powershell.config.json' is denied. To change the execution policy for the default (LocalMachine) scope, start PowerShell with the "Run as administrator" option. To change the execution policy for the current user, run "Set-ExecutionPolicy -Scope CurrentUser".Steve Lee (@SteveL-MSFT) marked the original bug as duplicate, now we're left at the mercy of triage for this issue marked as "Issue-Enhancement". It feels like an obvious bug to me at the moment, regression even.
This keeps happening on pwsh 7.6.0 installed from MSStore.
https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop8-mutablepackagedirectory might be a way to address this
Enables your desktop application to specify a folder where you can modify the installation files for your application.On Windows 10, it would make sense to be in $env:SystemDrive\ProgramData
Better answer is ApplicationData's MachineFolder
TL;DR in
AppxManifest.xmldeclare "I want a per-machine (machine-wide-accessible) data location".- Declare
<appdata:ApplicationData><MachineFolder/>inAppxManifest.xml. Add the Sddl=... attribute needed to grant additional permissions - Use Microsoft.Windows.Storage.ApplicationData.MachinePath to get its path
ApplicationData provides per-packagefamily per-user data storage.
ApplicationData.MachineFolder provides per-packagefamily per-machine data storage.
GitHub
The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet. - microsoft/WindowsAppSDK- Declare
I'm having the problem of not being able to
Set-ExecutionPolicybecause it tries to modifypowershell.config.jsonin the Appx installation directory. This happens on an Administrator Powershell prompt:By design. MSIX package's install location is not Writeable; Read (and eXecute) rights only. Else it would break MSIX's security and integrity promises, and preclude data efficiencies (e.g. shared by all users, not a unique copy/disk-space per user).
Some unpackaged apps use the classic pattern of "store config file next to app and modify the config file as/when desired". Powershell is one such example.
MSIX recommends storing an original/unmodified/template file in the package and storing an override file in a mutable location e.g. ApplicationData.LocalPath for per-user storage, or ApplicationData.MachinePath for per-machine storage. Then at runtime instead of the classic
f = OpenFile(path_to_exe + "\foo.data")use the override pattern e.g.
f = OpenFile(ApplicationData.Current.LocalPath + "\foo.data") IF not found f = OpenFile(path_to_exe + "foo.data")Reacted by Mr Beedell, Roke Julian LockhartMSIX recommends storing an original/unmodified/template file in the package and storing an override file in a mutable location e.g.
So, is it a bug with
Set-ExecutionPolicy?MSIX recommends storing an original/unmodified/template file in the package and storing an override file in a mutable location e.g.
So, is it a bug with
Set-ExecutionPolicy?That would be a fair characterization.
The rules for packaged and unpackaged processes aren't identical. This is one such example.
One can make an application run in both contexts e.g. use override file if running with package identity. It's up the the app/dev to decide if this is warranted for their needs.
Reacted by Mr Beedell, Roke Julian Lockhart- linked a pull request that will close this issueStore MSIX machine-wide configuration in a secure ProgramData directory #27535
on May 27, 2026 - linked a pull request that will close this issueEnable admin-writable $PSHOME for MSIX installs via MutablePackageDirectory #27553
on Jun 1, 2026
Summary of the new feature/enhancement
For Snap and AppX packages of PSCore6, $PSHOME is effectively read-only. Any configuration stored in $PSHOME needs to be in a different location. On Windows 10, it would make sense to be in $env:SystemDrive\ProgramData.
Register-PSSessionConfigurationstores the config file in $PSHOME\SessionConfig folder.powershell.config.jsonfor the system is stored in $PSHOME, this means that admins can't set system wide config and cmdlets likeEnable-ExperimentalFeature -Scope AllUserswon't work.Update-Help -Scope AllUsersalso won't work as it's stored in $PSHOME.When this is fixed, test changes relying on
Test-CanWriteToPsHomeshould be reverted.Update — scope narrowed; solved via the MachineFolder data store
The pieces this issue originally enumerated are now split up:
powershell.config.jsonandEnable/Disable-ExperimentalFeature -Scope AllUsers→ handled by the config relocation: design [Design] MachineFolder: a per-machine writable data store for MSIX-packaged PowerShell #27697, implementation PR Place System-Wide Config in the Machine Folder for MSIX Packages #27632.Update-Help -Scope AllUsers→ now tracked in PS7-packaged: Update-Help -Scope AllUsers fails under MSIX ($PSHOME read-only) #27699.Test-CanWriteToPsHometest reverts → revisited as each piece lands.This issue is narrowed to the SessionConfig
.psscwrite-location:Register/Set-PSSessionConfigurationcopy the.psscinto$PSHome\SessionConfig(Utils.DefaultPowerShellAppBase,CustomShellCommands.cs:950), which is read-only under MSIX. The fix mirrors the profile relocation —Utils.GetPackagedMachineDataStorePath() ?? AppBase+\SessionConfig.WinRM / remoting activation under MSIX (native
pwrshplugin.dllregistration) remains a separate concern tracked in #27563. Tracked under #27565.