PowerShell 7.4.21 Released: Config Fixes, Update Steps and 7.6 LTS Migration

What actually changed in 7.4.21​

The GitHub release page in the official PowerShell/PowerShell repository splits the changes into three groups.

Engine Updates and Fixes

• PowerShell now tolerates I/O and JSON errors when it reads the per-user powershell.config.json file (PR #28048).

General Cmdlet Updates and Fixes

• Show-Command gets a new GetImportModuleCommand method and a session-restriction check (PR #28059).

Build and Packaging Improvements

• An update to .NET SDK 8.0.426.
• A move to the latest Microsoft.PowerShell.Native package, plus a new test (PRs #28174 and #28169).
• Removal of unintended Microsoft Store languages and simpler Store listing metadata.
• Windows CI no longer uses Windows PowerShell 5.1.
• Support for macOS signatures in nonofficial pipelines.
• New variable groups in the MSIX VPack pipeline that force use of the production Azure DevOps feed.
• Updates to GitHub Actions dependencies, including CodeQL actions to 4.38.2, actions/setup-dotnet 5.2.0 → 6.0.0, actions/github-script 8.0.0 → 9.0.0, actions/checkout 6.0.2 → 7.0.1, actions/upload-artifact 7.0.0 → 7.0.1, and ossf/scorecard-action 2.4.3 → 2.4.4.

The changelog was prepared a few days before the release. An automated pull request dated October 9 adds the PowerShell 7.4.21 release notes covering changes since 7.4.20. The previous release was 7.4.20 (08 Sep 2026), according to the endoflife.date tracker. The 7.4 branch has been getting patches about once a month.

In short: two fixes affect behavior, and the rest is build and release work. There is no new feature and no CVE.

The two fixes, without the hype​

The config-file fix​

powershell.config.json holds PowerShell settings. The per-user copy is the one in your own profile area, not the system-wide one in $PSHOME. The release note says only that PowerShell now tolerates I/O or JSON errors when reading that file. It does not list which errors are covered. It also doesn't say whether they are now ignored silently, logged, or shown as a warning.

This next part is my reading, not a documented claim. A corrupt, half-written, or locked settings file in a user profile should no longer cause trouble at startup. Roaming profiles, profiles redirected to a network share, and syncing tools that leave files half-written are all plausible ways to end up with one. If you have seen errors like that on 7.4, test this build. Microsoft has not published a before-and-after description, so don't treat the fix as guaranteed.

This is also not the first fix in this area. Earlier in 2026, the 7.5.7 release notes included a change to fix checks for local user config file paths (#27479).

The Show-Command fix​

Show-Command is the Windows-only cmdlet that opens a graphical form for building a command. 7.4.21 adds a session-restriction check to it. The note doesn't say which restriction modes are involved or what users will see differently. Some admins run restricted endpoints, such as constrained or JEA-style remoting configurations. If yours do, check whether Show-Command behaves differently after you upgrade. I'm not claiming a specific change, only that this is where one would show up.

In short: both fixes are narrow and lightly documented. Test them against your own setup.

The bigger story: 7.4 is almost out of support​

Microsoft's PowerShell Support Lifecycle documentation explains how the LTS releases fit together:

• The current LTS release is PowerShell 7.6.6. The previous LTS release, PowerShell 7.4.20, is still supported until 10-Nov-2026.
• The lifecycle table lists PowerShell 7.6 (LTS) | 18-Mar-2026 | 14-Nov-2028 | .NET 10.0 and PowerShell 7.4 (LTS) | 16-Nov-2023 | 10-Nov-2026 | .NET 8.0.
• PowerShell 7.5, the stable non-LTS release, also ends support on November 10, 2026.

The lifecycle page still names 7.4.20 as the supported 7.4 build. That page was last updated in August, before this release came out. Microsoft's rule is that Microsoft only supports the latest update version of a release. Once 7.4.21 is out, a machine still on 7.4.20 is no longer on the supported build.

The lifecycle date is set by .NET, not by PowerShell. Microsoft says the end-of-support dates follow the .NET Support Policy for the version of .NET that the release of PowerShell was built upon. PowerShell 7.4 runs on .NET 8, so it expires when .NET 8 does. After that, Microsoft's documentation says no further updates are provided, including security updates.

Should you rush to 7.4.21 or skip ahead to 7.6? If you have fewer than four weeks of support left, applying 7.4.21 is only a stopgap. The longer-term job is getting to 7.6 LTS.

In short: install 7.4.21 to stay on the supported build, then put your 7.6 migration on the calendar.

How to update on Windows​

Microsoft's installation guidance gives the following steps for Windows.

1. Find out how PowerShell was installed. Run $PSHOME in a pwsh session.
   • If it points to $Env:ProgramFiles\PowerShell\7, you probably used the MSI.
   • If it starts with $Env:ProgramFiles\WindowsApps\, you used the MSIX/Store package.
   • If it is $HOME\.dotnet\tools, you used the .NET global tool.
   • Anything else is probably a ZIP install.
2. Upgrade with the same method you used to install. Microsoft recommends this. Newer PowerShell 7 builds replace older ones in place.
3. WinGet users can check with winget list --id Microsoft.PowerShell --upgrade-available and then run winget upgrade --id Microsoft.PowerShell. Microsoft's own WinGet example lists Microsoft.PowerShell at version 7.6.6.0, so the default package follows 7.6. Check what WinGet offers before you assume it will keep you on 7.4. To stay on 7.4, you can download the 7.4.21 MSI directly instead.
4. Microsoft Update, WSUS, or Configuration Manager users should know that new releases can take up to two weeks to reach Microsoft Update. They arrive as optional updates. Microsoft Update keeps you in the same release channel, and it will never move an LTS install to a stable non-LTS release. If you need 7.4.21 sooner, Microsoft says to download it from GitHub.
5. Confirm the upgrade worked. Open a new session and run $PSVersionTable.PSVersion. It should report 7.4.21.

The release offers MSI and ZIP packages for x64, x86, and ARM64. It also has two framework-dependent ZIPs, a standard MSIX bundle, and a separate PowerShell-LTS-7.4.21.msixbundle. For non-Windows systems there are macOS .pkg and tarball builds, Linux tarballs (including musl and ARM32/ARM64), and RPM and DEB packages, with powershell-lts versions where they exist. There are 33 assets in total.

On Windows Server and in enterprise deployments, Microsoft still recommends the MSI. One known limit of the MSIX package is that Store-based installs don't support PowerShell remoting into the machine.

Verify the hash before you deploy​

The release page publishes a SHA-256 hash for every asset. In each hash list entry, the filename comes first, followed by its hash. Download the package and run:

Get-FileHash .\PowerShell-7.4.21-win-x64.msi -Algorithm SHA256

Compare the result with the hash listed directly under that exact filename. The hash for the ZIP or the ARM64 MSI tells you nothing about the x64 MSI.

A few things this release doesn't do​

• It doesn't affect Windows PowerShell 5.1. The "stop using PowerShell 5.1" item applies only to the project's own CI. PowerShell 7 installs alongside the built-in 5.1, which still ships with Windows.
• It isn't a security release, as far as the notes say. The CodeQL and Scorecard updates harden the project's build process. They don't patch the shell on your machines.
• It doesn't extend 7.4's support. A new patch this late in the lifecycle doesn't change the November 10 date.

Bottom line​

PowerShell 7.4.21 is a small, normal patch: one config-file fix, one Show-Command check, and a .NET 8 SDK update, plus a lot of release-pipeline work. Install it so your 7.4 machines stay on the supported build. Its main value, though, is as a reminder that 7.4 ends on November 10, and 7.6 LTS is supported until November 2028.