Windows App Execution Aliases: Package Activation, PATH, and Collisions

An app execution alias lets a user or another process start a packaged Windows app by typing a short executable-style name instead of knowing the package’s install directory. It is not simply a portable copy of the application’s binary placed on PATH: for MSIX packages, Windows associates the alias with a package activation target, and the user can manage supported aliases in Windows Settings. Debugging is easier when four separate questions are kept apart: did the package declare the alias, is that alias enabled for this user, can the current process find the alias directory, and does package activation succeed?

Windows Terminal’s wt.exe is a familiar example, and the Microsoft Store Sysinternals Suite documents aliases for its packaged utilities. The exact alias behavior belongs to the package and Windows version, so do not infer that every command named foo.exe is an execution alias just because it launches an application.

What a packaged alias declares

Microsoft’s packaging-extension documentation places an alias under an application extension whose category is windows.appExecutionAlias. The manifest connects a package-relative executable to an alias name. The documented alias must end in .exe; an application can declare one alias, and if multiple apps register the same alias, Windows invokes the last one registered. That is a reason to choose a unique, product-specific command name rather than taking a generic name that another app may claim.

The following is a manifest fragment, not a complete package manifest. The package root must declare the uap3 and desktop XML namespaces required by the schema, and the extension must appear under the package’s application element:

<uap3:Extension
    Category="windows.appExecutionAlias"
    Executable="bin\contosoctl.exe"
    EntryPoint="Windows.FullTrustApplication">
  <uap3:AppExecutionAlias>
    <desktop:ExecutionAlias Alias="contosoctl.exe" />
  </uap3:AppExecutionAlias>
</uap3:Extension>

The alias is part of the package’s activation contract. It does not grant new privileges, make a non-installed app available, or guarantee the target will start successfully. The app still has its normal package identity, dependencies, activation behavior, and policy requirements. The schema documentation identifies the extension as the way to determine which executable app is activated.

Alias registration is per-user state, not just a manifest line

Windows exposes a Manage app execution aliases page in Settings. An alias that is declared by a package may be turned off for a user, so a correct manifest alone does not prove that typing the name will work in that user’s shell. Search Windows Settings for that exact page when diagnosing a packaged alias; settings navigation labels can shift across Windows releases.

Microsoft’s Sysinternals Store documentation describes that package’s aliases as special reparse points managed by Windows for MSIX packages. It locates them under %LOCALAPPDATA%\Microsoft\WindowsApps, including a package-specific subdirectory, and says they are removed when the MSIX package is uninstalled. Treat this as a documented implementation example for the Sysinternals package, not as a promise that every app alias has identical on-disk details.

Do not edit or replace files in C:\Program Files\WindowsApps to repair an alias. Microsoft specifically warns against modifying that protected package directory in its Windows Terminal guidance. The supported controls are the package’s installation and manifest lifecycle, the per-user alias settings, and the user’s command-search environment.

Separate PATH lookup from package activation

For Windows Terminal, Microsoft’s current troubleshooting instructions say to enable its alias in Manage app execution aliases and verify that %LOCALAPPDATA%\Microsoft\WindowsApps is present in PATH if wt.exe is still unavailable. Run diagnostics in the same account and shell where the failure occurs; a process started before an environment change can retain an older environment block.

In PowerShell, inspect the alias directory and command candidates without changing machine state:

$aliasDir = Join-Path $env:LOCALAPPDATA 'Microsoft\WindowsApps'
$env:Path -split ';' | Where-Object { $_ -ieq $aliasDir }

Get-Command wt.exe -All |
    Format-Table CommandType, Name, Source, Definition -AutoSize

where.exe wt.exe

The first command shows whether the expected per-user directory is in this process’s PATH. Get-Command -All and where.exe help reveal command candidates, but neither one tells you whether the alias toggle is enabled or which package owns a selected entry. Use the Settings page and the package’s installation state to answer those questions. A where.exe result can establish a path match; it cannot prove that Windows will successfully activate the package after the alias is invoked.

If wt.exe works in Command Prompt but not PowerShell, check which command each shell resolves and compare the process environment. If it fails in every shell for one account, check the alias toggle and package installation for that account. If the command disappears after uninstalling a Store package, that is consistent with the documented lifecycle for Sysinternals aliases; it is not evidence that a manually copied replacement should be created in the protected package directory.

Alias collisions are a naming failure, not a PATH mystery

Microsoft’s manifest guidance warns that when different apps register the same alias, the last registered app is invoked. This can make a command appear to “change owners” after installing or updating software. Prefer unique aliases such as contosoctl.exe instead of common names such as python.exe or git.exe, which may already be supplied by another installation method. When a collision is suspected, compare the Settings state, command candidates, package identities, and recent installation history before changing PATH or reinstalling applications.

Do not assume that adding the WindowsApps directory earlier in PATH is a safe collision fix. It can change which ordinary executable a shell finds, but it does not repair a disabled alias, correct a package manifest, or establish the intended owner. Changing user or machine PATH may affect unrelated tools and automation. Make the narrow change only after identifying the specific command-resolution conflict.

Windows Subsystem for Linux is a separate boundary

Windows Terminal’s documentation explicitly says execution aliases do not work inside WSL distributions. If a Linux process needs to request Windows Terminal, cross the Windows process boundary deliberately; Microsoft’s example uses cmd.exe to launch wt.exe from the WSL command line. Do not treat a Linux shell’s PATH, a Windows user’s alias toggle, and the WindowsApps path as one shared environment. Each belongs to a different process environment and launch mechanism.

The same caution applies to services, scheduled tasks, remote sessions, and elevated processes. A command available in an interactive user’s shell may be absent for another identity because that user has different package registration, settings, or environment variables. Diagnose using the actual account and launch context rather than copying an interactive user’s PATH into a service.

A short troubleshooting sequence

Confirm the command name and the Windows account where it fails.
Confirm that the expected packaged app is installed for that account.
Search Settings for Manage app execution aliases and verify the specific toggle.
Inspect the current process’s PATH for %LOCALAPPDATA%\Microsoft\WindowsApps when troubleshooting a documented package alias such as wt.exe.
Compare command candidates and investigate duplicate alias registrations; prefer a unique manifest name.
Test package launch in the same context, then separately test the WSL-to-Windows boundary if relevant.

This model avoids common false repairs: editing the protected package installation tree, adding arbitrary directories to the machine path, or reinstalling a working package when only a per-user toggle is disabled. An alias is a convenience at the command-resolution boundary; successful lookup and successful application activation are separate checks.

Related:

Sources: