I installed the PowerShell Preview version on Windows, installed Tabby, and opened a new Tabby terminal. The terminal itself started normally, but running pwsh failed immediately.

The error looked like this:

Program 'pwsh.exe' failed to run: Access is denied
At line:1 char:1
+ pwsh
+ ~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

This was confusing because PowerShell Preview had already been installed and pwsh worked outside Tabby. The fix was to remove the Preview package and its remaining AppX package, install the stable PowerShell package, remove Tabby, reboot Windows, and verify which pwsh.exe Windows resolved.

What Tabby is for

Tabby is a Windows terminal application that combines local shells and remote sessions in one window. Its tabbed interface makes it useful when I need several terminal sessions open at the same time, such as separate SSH connections to multiple servers.

Tabby can store SSH profiles and open those hosts in separate tabs, so I do not need to install PuTTY just to maintain a collection of SSH sessions. It can also start local shells, including Windows PowerShell and PowerShell 7. That means I can use Tabby both to connect to remote Linux or Windows hosts over SSH and to run pwsh directly on the local computer.

The failure in this post was therefore not that Tabby could not open. Tabby started correctly, but its local PowerShell command could not launch pwsh.exe after the PowerShell Preview installation.

Quick answer

If pwsh returns Access is denied inside Tabby after installing PowerShell Preview, first check which executable Windows resolves with Get-Command pwsh -All and (Get-Command pwsh).Source. A stale Preview AppX package, a broken package registration, or an old terminal process can leave Tabby trying to launch a path that Windows can no longer execute. Close Tabby, uninstall the Preview package with winget, remove remaining PowerShellPreview AppX packages, install stable PowerShell, uninstall Tabby, reboot, and verify the stable executable path before opening a new terminal.

What happened in my setup

The sequence was:

  1. PowerShell Preview was installed on Windows.
  2. Tabby was installed from tabby.sh.
  3. Tabby was started normally.
  4. I ran pwsh from the Tabby terminal.
  5. Windows returned Access is denied for pwsh.exe.

The important detail is that the failure occurred when Tabby tried to start pwsh.exe, not when Tabby itself opened. That points the investigation toward the executable resolution and package state rather than treating the message as a generic Tabby startup error.

Why this can happen

The message does not necessarily mean that the Tabby window lacks administrator rights. Access is denied can appear when Windows resolves a command to an executable or AppX-backed package that is present but cannot be launched in the current state.

Several pieces can overlap:

  • PowerShell Preview and stable PowerShell can have different install locations and package registrations.
  • A Preview installation may leave an AppX package or executable alias after the main package is removed.
  • Tabby may already have a child process, shell profile, or resolved path from before the package was changed.
  • A terminal that was open during an install or uninstall keeps its old environment until it is closed.
  • Windows can resolve more than one pwsh.exe, so the command that works in one terminal is not necessarily the file another terminal is trying to start.

The exact cause in this incident was not isolated to one registry value or one Tabby setting. The reliable recovery was to remove the Preview package completely, remove the remaining Preview AppX package, install the stable package, clear Tabby’s old process state, and reboot.

Check the command resolution first

Before removing anything, close extra PowerShell windows only if you have saved your work, then run these commands in a Windows PowerShell or Command Prompt session where commands still work.

See every pwsh command Windows can find

Get-Command pwsh -All

This shows every command named pwsh found through PowerShell’s command resolution. If more than one result appears, compare the paths. A Preview path, an old installation directory, or a WindowsApps path is useful evidence when diagnosing the failure.

(Get-Command pwsh).Source

The .Source property shows the executable selected for the current session. After the repair, this command should point to the stable PowerShell installation rather than a Preview directory.

You can also ask Windows whether a file is found through the current PATH:

where.exe pwsh

These commands are read-only. They are worth running before uninstalling packages because they tell you whether the problem is a duplicate path, an unexpected alias, or a package that is no longer launchable.

Close Tabby and other terminals

Before changing PowerShell packages, close Tabby completely. Close any other terminal that may have started from Tabby as well.

An already-running terminal keeps its original environment and child-process state. Even after installing a corrected package, an old Tabby process can continue trying to use the old command path. Do not test the repaired installation from the same Tabby process that was open during the failure.

Remove PowerShell Preview with winget

Open a Windows PowerShell window or Command Prompt outside Tabby and uninstall the Preview package:

winget uninstall Microsoft.PowerShell.Preview

If winget shows multiple matches, use the package identifier explicitly:

winget uninstall --id Microsoft.PowerShell.Preview

Wait for the uninstall to finish. If Windows reports that the package is not installed, continue to the AppX check because a remaining package registration may still exist.

Remove remaining PowerShell Preview AppX packages

PowerShell Preview can leave a package behind even after the normal package uninstall. Check the current user’s installed AppX packages:

Get-AppxPackage *PowerShellPreview* |
    Select-Object Name, PackageFullName, Status

If the command returns a Preview package, remove it:

Get-AppxPackage *PowerShellPreview* | Remove-AppxPackage

This command removes matching Preview packages for the current Windows user. Run it from an elevated session only if your installation requires administrator rights, and review the package list before removing anything. Do not replace the wildcard with a broad pattern such as *PowerShell* unless you have confirmed exactly which packages you intend to remove.

After removal, check again:

Get-AppxPackage *PowerShellPreview*

An empty result means that no matching Preview package remains for the current user.

Install the stable PowerShell package

Install the stable package from the winget source:

winget install --id Microsoft.PowerShell --source winget

Accept the source and package agreements if winget asks for them. Using the stable package identifier avoids accidentally installing the Preview channel again.

After the installation completes, do not immediately test from an old Tabby window. First close any terminal that was open during the installation.

Uninstall Tabby before the reboot

In my recovery sequence, I uninstalled Tabby before restarting Windows. This cleared the terminal application and its stored shell state from the test environment.

You can remove Tabby from Settings > Apps > Installed apps, search for Tabby, and select Uninstall. If you prefer winget, first identify the exact package shown on your machine:

winget list --name Tabby

Only then use the identifier reported by winget:

winget uninstall --id <tabby-package-id>

The package identifier can vary by distribution method, so I would not hard-code an identifier from another machine into a repair script.

Reboot Windows

Restart the computer after removing the Preview package, removing the remaining AppX package, installing stable PowerShell, and uninstalling Tabby.

The reboot matters because it clears old terminal processes, refreshes package registration, reloads environment variables, and releases files that may still be held by a shell or terminal process. It also gives Windows a clean starting point for the next command-resolution check.

Verify the stable pwsh path

After the reboot, open a fresh Windows PowerShell session and check the selected executable:

(Get-Command pwsh).Source

Check all matches as well:

Get-Command pwsh -All
where.exe pwsh

The result should identify the stable PowerShell installation. If the output still points to a Preview directory, repeat the package inspection before reinstalling anything else.

You can confirm the installed version with:

pwsh -NoLogo -Command '$PSVersionTable | Select-Object PSVersion, PSEdition'

The stable channel should report the expected production PowerShell version and Core edition.

Test pwsh in a new Tabby installation

Once the path and version are correct, reinstall Tabby from the official Tabby website if you still want to use it. Start a completely new Tabby window and run:

pwsh

In my case, pwsh started normally after the cleanup, stable installation, Tabby removal, and reboot.

If the error returns after reinstalling Tabby, compare the result in a normal Windows PowerShell window and a new Tabby window:

Get-Command pwsh -All
(Get-Command pwsh).Source
pwsh -NoLogo -Command '$PSVersionTable.PSVersion'

If both terminals resolve the same stable path but only Tabby fails, the remaining investigation should focus on Tabby’s shell profile, its configured executable path, permissions inherited by the Tabby process, and any security software blocking child processes. If both terminals fail, continue investigating the PowerShell installation or Windows package state instead of treating Tabby as the only cause.

What I would check before repeating the full cleanup

The full removal sequence worked, but it is more disruptive than the initial diagnostics. On another machine, I would collect these facts first:

  1. Get-Command pwsh -All
  2. (Get-Command pwsh).Source
  3. where.exe pwsh
  4. Get-AppxPackage *PowerShellPreview*
  5. The PowerShell version returned outside Tabby and inside a new Tabby window.

I would also confirm that Tabby is fully closed before changing packages. If the source path is clearly stale or points to Preview, package cleanup is justified. If the same stable path works in another terminal, the issue may be isolated to Tabby’s profile or process environment.

Final checklist

Before considering the repair complete, confirm:

  • PowerShell Preview is no longer installed.
  • Get-AppxPackage *PowerShellPreview* returns no matching package for the current user.
  • Stable PowerShell is installed with winget.
  • Windows has been rebooted.
  • (Get-Command pwsh).Source points to the expected stable installation.
  • pwsh starts in a new Tabby window.
  • pwsh -NoLogo -Command '$PSVersionTable.PSVersion' reports the expected version.

The key lesson is to verify the executable path before assuming that a terminal application is broken. Tabby exposed the failure, but the underlying repair was to remove the inconsistent Preview package state, install the stable PowerShell package, clear the old terminal state, and verify the command path from a fresh session.