Skip to content

Some cmdlets and config require writing to $PSHOME\SessionConfig folder #9278

Open
#27535
Open
Some cmdlets and config require writing to $PSHOME\SessionConfig folder#9278
#27535
Assignees
jshigetomi
Labels
Committee-ReviewedPS-Committee has reviewed this and made a decisionIn-PRIndicates that a PR is out for the issueIssue-Enhancementthe issue is more of a feature request than a bugKeepOpenThe bot will ignore these and not auto-closePackage-MSIXIssue occurs with MSIX packageWG-RemotingPSRP issues with any transport layer

Description

@SteveL-MSFT
Steve Lee (SteveL-MSFT)
opened on Apr 3, 2019

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-PSSessionConfiguration stores the config file in $PSHOME\SessionConfig folder.

powershell.config.json for the system is stored in $PSHOME, this means that admins can't set system wide config and cmdlets like Enable-ExperimentalFeature -Scope AllUsers won't work.

Update-Help -Scope AllUsers also won't work as it's stored in $PSHOME.

When this is fixed, test changes relying on Test-CanWriteToPsHome should be reverted.

Update — scope narrowed; solved via the MachineFolder data store

The pieces this issue originally enumerated are now split up:

This issue is narrowed to the SessionConfig .pssc write-location: Register/Set-PSSessionConfiguration copy the .pssc into $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.dll registration) remains a separate concern tracked in #27563. Tracked under #27565.

Activity

  1. Steve Lee (SteveL-MSFT)
    added
    Issue-Enhancementthe issue is more of a feature request than a bug
    WG-RemotingPSRP issues with any transport layer
    on Apr 3, 2019
  2. Steve Lee (SteveL-MSFT)
    added this to the 6.3-Consider milestone on Apr 3, 2019
  3. Steve Lee (SteveL-MSFT)
    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

  4. iSazonov commented on Apr 28, 2019

    @iSazonov
    Ilya (iSazonov)
    on Apr 28, 2019
    Collaborator

    Long time Windows exposes UAC virtualization for registry keys and file system.
    If we could use it it would solve this problem.

  5. SteveL-MSFT commented on Apr 29, 2019

    @SteveL-MSFT
    Steve Lee (SteveL-MSFT)
    on Apr 29, 2019
    MemberAuthor

    Ilya (@iSazonov) that would potentially work for Windows, but doesn't solve the same problem with Snaps.

  6. iSazonov commented on Apr 30, 2019

    @iSazonov
    Ilya (iSazonov)
    on Apr 30, 2019
    Collaborator

    I 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.

  7. TravisEz13 commented on May 6, 2019

    @TravisEz13
    Travis Plunk (TravisEz13)
    on May 6, 2019
    Member

    What 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.

  8. bcdady commented on Jun 11, 2019

    @bcdady
    Bryan Dady (bcdady)
    on Jun 11, 2019

    See also https://github.com/PowerShell/PowerShell-Snap/issues/32

  9. joeyaiello commented on Jul 8, 2019

    @joeyaiello
    Joey Aiello (joeyaiello)
    on Jul 8, 2019
    Contributor

    Can we just use /etc/ for this? Or does Snap "classic" et al not have a way to do this?

  10. TravisEz13 commented on Jul 9, 2019

    @TravisEz13
    Travis Plunk (TravisEz13)
    on Jul 9, 2019
    Member

    Joey Aiello (@joeyaiello) The problem is this should be done in PowerShell. /etc is where the file should be for all PowerShell installations.

  11. iSazonov commented on Jul 12, 2019

    @iSazonov
    Ilya (iSazonov)
    on Jul 12, 2019
    Collaborator

    For reference #4080

  12. TravisEz13 commented on Nov 4, 2019

    @TravisEz13
    Travis Plunk (TravisEz13)
    on Nov 4, 2019
    Member

    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.json Yes (buggy #7452) Fixed in 7.0.0
    Update-Help -scope AllUsers $PSHome\en-US Yes
    Enable-ExperimentalFeature -Scope AllUsers $pshome\powershell.config.json Yes
    Set-ExecutionPolicy -Scope LocalMachine $pshome\powershell.config.json Yes

  13. TravisEz13 commented on Nov 4, 2019

    @TravisEz13
    Travis Plunk (TravisEz13)
    on Nov 4, 2019
    Member

    Proposal

    Rational

    It looks like the majority of the problem is writing to the configuration file. We should move it under /etc for Linux and macOS, and `%programdata% for Windows.

    We can make similar changes for $PSHome\SessionConfig and $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.json

    MSI could be update to create the file.
    MSIX - Steve Lee (@SteveL-MSFT)?
    zip - instructions would have to be updated

    Issues

    1. What do you do on upgrade? Currently we overwrite the file, but this is not the correct behavior.
    2. 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.

  14. SteveL-MSFT commented on Nov 4, 2019

    @SteveL-MSFT
    Steve Lee (SteveL-MSFT)
    on Nov 4, 2019
    MemberAuthor

    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.

  15. 41 remaining items

  16. lafe commented on Nov 13, 2025

    @lafe
    Lars Fernhomberg (lafe)
    on Nov 13, 2025

    I encountered this issue with the Set-ExecutionPolicy Cmdlet just this week. So from my point of view, it's still relevant.

  17. microsoft-github-policy-service
    removed
    Resolution-No ActivityIssue has had no activity for 6 months or more
    on Nov 13, 2025

  18. ssg commented on Mar 24, 2026

    @ssg
    Sedat Kapanoğlu (ssg)
    on Mar 24, 2026

    I'm having the problem of not being able to Set-ExecutionPolicy because it tries to modify powershell.config.json in 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".

  19. ssg commented on Mar 24, 2026

    @ssg
    Sedat Kapanoğlu (ssg)
    on Mar 24, 2026

    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.

  20. Steve Lee (SteveL-MSFT)
    removed this from the 7.3-Consider milestone on May 8, 2026
  21. Steve Lee (SteveL-MSFT)
    assigned
    Justin Chung (jshigetomi)
    on May 8, 2026
  22. Steve Lee (SteveL-MSFT)
    added
    KeepOpenThe bot will ignore these and not auto-close
    on May 8, 2026

  23. SteveL-MSFT commented on May 12, 2026

    @SteveL-MSFT
    Steve Lee (SteveL-MSFT)
    on May 12, 2026
    MemberAuthor

    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.

  24. DrusTheAxe commented on May 15, 2026

    @DrusTheAxe
    Howard Kapustein (DrusTheAxe)
    on May 15, 2026

    On Windows 10, it would make sense to be in $env:SystemDrive\ProgramData

    Better answer is ApplicationData's MachineFolder

    https://github.com/microsoft/WindowsAppSDK/blob/main/specs/applicationdata/ApplicationData.md#342-manifested-opt-in

    TL;DR in AppxManifest.xml declare "I want a per-machine (machine-wide-accessible) data location".

    1. Declare <appdata:ApplicationData><MachineFolder/> in AppxManifest.xml. Add the Sddl=... attribute needed to grant additional permissions
    2. 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

  25. DrusTheAxe commented on May 15, 2026

    @DrusTheAxe
    Howard Kapustein (DrusTheAxe)
    on May 15, 2026

    I'm having the problem of not being able to Set-ExecutionPolicy because it tries to modify powershell.config.json in 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")

  26. ssg commented on May 15, 2026

    @ssg
    Sedat Kapanoğlu (ssg)
    on May 15, 2026

    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?

  27. DrusTheAxe commented on May 15, 2026

    @DrusTheAxe
    Howard Kapustein (DrusTheAxe)
    on May 15, 2026

    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.

  28. Justin Chung (jshigetomi)
    linked a pull request that will close this issueStore MSIX machine-wide configuration in a secure ProgramData directory #27535on May 27, 2026
  29. microsoft-github-policy-service
    added
    In-PRIndicates that a PR is out for the issue
    on May 27, 2026
  30. Justin Chung (jshigetomi)
    linked a pull request that will close this issueEnable admin-writable $PSHOME for MSIX installs via MutablePackageDirectory #27553on Jun 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Committee-ReviewedPS-Committee has reviewed this and made a decisionIn-PRIndicates that a PR is out for the issueIssue-Enhancementthe issue is more of a feature request than a bugKeepOpenThe bot will ignore these and not auto-closePackage-MSIXIssue occurs with MSIX packageWG-RemotingPSRP issues with any transport layer

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions