Troubleshooting ‘Python was not found’ and App Execution Alias Conflicts in Windows 11

Quick Summary / Direct Answer: The ‘Python was not found’ error in Windows 11 frequently happens because App Execution Aliases intercept your shell commands, redirecting them to the Microsoft Store instead of your actual Python installation. Disable these aliases in Windows Settings and reconstruct your system PATH variables pointing to AppData and Scripts directories to restore full terminal functionality.

Key Takeaways:

• App Execution Aliases in Windows 11 override standard PATH resolution for python.exe and python3.exe.
• Disabling execution aliases and properly ordering your environmental PATH variables permanently resolves the Microsoft Store redirection bug.
• Manual PATH reconstruction for user-level and system-level directories ensures scripts execute without throwing file-not-found exceptions.

The Root Cause of Windows 11 Python Interception

It fails silently, then shouts loudly. You type python into PowerShell or Windows Terminal, expecting an interactive REPL or a script to spin up. Instead, Windows abruptly opens the Microsoft Store page for Python. It’s frustrating. It breaks automation pipelines. It halts local web server development cold.

Here is why this happens. When Microsoft introduced App Execution Aliases in Windows 10 and carried them forward into Windows 11, they created stub executables inside %LOCALAPPDATA%\Microsoft\WindowsApps. These zero-byte redirection stubs sit near the very top of the default Windows PATH variable. When you invoke a command, the OS checks this directory first. If a stub exists—and Windows automatically populates stubs for Python when you install it via the Microsoft Store or even when it detects certain system configurations—it intercepts the execution.

Most tutorials gloss over this edge case. They tell you to reinstall Python, check the ‘Add Python to PATH’ box, and hope for the best. That approach fails when App Execution Aliases retain priority over your manual installations. We need a permanent, surgical fix.

Diagnosing Your Environment and PATH Order

Before modifying anything, inspect what your shell is actually running. Open your terminal and run a path resolution check.

Get-Command python | Select-Object Source

If the output points to C:\Users\<username>\AppData\Local\Microsoft\WindowsApps\python.exe, you are caught in the alias trap. If it throws an error entirely, your environment variables lack the necessary pointers.

Let us look at how Windows evaluates executable lookups compared to traditional Unix shells. Understanding this mechanism prevents future deployment headaches.

Step-by-Step Resolution Workflow

Fixing this requires two distinct actions: disabling the conflicting UI stubs and manually rebuilding your PATH hierarchy.

Step 1: Disable App Execution Aliases

We need to turn off the Windows Store redirection stubs.

1. Open the Windows 11 Settings app (Win + I).
2. Navigate to Apps > Advanced app settings > App execution aliases.
3. Scroll down until you locate the entries for python.exe and python3.exe.
4. Toggle both switches to Off.

Once disabled, Windows will stop routing your terminal commands to the Microsoft Store sandbox.

Step 2: Reconstruct Your PATH Variables

Next, ensure your actual Python installation directories occupy the correct positions in your environment variables. Avoid bloating the global system PATH if you are working on a multi-user machine. User-level installations scale better.

Add these exact paths to your User Environment Variables, placing them above legacy system paths if possible:

C:\Users\YourUsername\AppData\Local\Programs\Python\Python311\
C:\Users\YourUsername\AppData\Local\Programs\Python\Python311\Scripts\

If you prefer using PowerShell to update your user PATH programmatically without clicking through the GUI, run this snippet:

$userPath = [Environment]::GetEnvironmentVariable('PATH', 'User')
$pythonPaths = ';C:\Users\YourUsername\AppData\Local\Programs\Python\Python311\;C:\Users\YourUsername\AppData\Local\Programs\Python\Python311\Scripts\'
if ($userPath -notlike '*Python311*') {
    [Environment]::SetEnvironmentVariable('PATH', $userPath + $pythonPaths, 'User')
    Write-Host 'Python paths successfully appended.' -ForegroundColor Green
} else {
    Write-Host 'Python paths already exist in user environment.' -ForegroundColor Yellow
}

Validating the Fix

Close all open terminal windows to force a complete environment refresh. Open a fresh instance of PowerShell or Command Prompt and test your setup.

python --version
pip --version

Both commands should now output the correct version numbers corresponding to your manual installation directory, completely bypassing the Microsoft Store interceptor.

Frequently Asked Questions

Why does Windows 11 keep reinstalling the Python execution alias stubs?

Major Windows feature updates or resetting specific app defaults can occasionally re-enable App Execution Aliases. If you run a fresh Python installer from python.org and accidentally check certain integration options, it may also recreate or reprioritize these links. Keep an eye on your advanced app settings after major OS patches.

Should I use the Microsoft Store version of Python or the official standalone installer?

For serious development, system automation, and production parity, the standalone installer from python.org is vastly superior. The Microsoft Store version runs inside an AppX container, which introduces strict filesystem virtualization restrictions that frequently break third-party C-extension compilation and virtual environment linking.

The Bottom Line: Actionable Next Steps

Don’t let aggressive OS-level shortcuts break your development velocity. Take five minutes right now to check your App Execution Aliases, clean out redundant environment paths, and explicitly define your user-level PATH variables. Test your terminal with a clean shell restart, and you will eliminate the ‘Python was not found’ frustration once and for all.