Quick Summary / Direct Answer: The ‘Python was not found’ error on Windows typically happens when Microsoft Store app execution aliases intercept the `python` command, or when the actual interpreter path is missing from your User or System PATH environment variables. Disable the store aliases in Windows Settings and ensure your Python installation paths are correctly prioritized to resolve this immediately.
Key Takeaways:
- App Execution Aliases in Windows act as shims that redirect terminal commands to the Microsoft Store installer.
- PATH environment variable precedence dictates which executable runs first when typing commands into PowerShell or Command Prompt.
- Proper installation flags like ‘Add python.exe to PATH’ prevent manual configuration pain down the road.
The Root Cause of the Windows Python Interception Problem
You open PowerShell, type python, and expect an interactive REPL or your script to launch. Instead, Windows abruptly opens the Microsoft Store or spits out a frustrating ‘Python was not found’ error. Why does this happen? It is rarely a broken installation. It is a routing conflict deep inside the operating system.
When Windows 10 and 11 introduced App Execution Aliases, they created a system where harmless-looking stub executables live in a protected system directory. If these shims take priority over your true python.exe binary, the shell gets confused. The system looks for Python, finds a stub designed to sell you Python from the store, and panics when it isn’t fully initialized.
Most tutorials gloss over this edge case. They tell you to reinstall Python five times, check the box, and pray. That approach fails because it doesn’t address the underlying environment pollution and registry tracking.
How Windows Resolves Executables
Windows parses directories specified in the PATH environment variable from top to bottom. If a shim directory sits higher than your actual python installation directory, the shell executes the shim. It failed. Here is why: the shim lacks context.
| Execution Source | Registry Path / Directory | Priority Impact | Recommended State |
|---|---|---|---|
| App Execution Aliases | %LocalAppData%\Microsoft\WindowsApps |
High (Intercepts default names) | Disabled for Python |
| System Python Install | C:\Program Files\Python311\ |
Variable | Top Priority |
| User Python Install | %LocalAppData%\Programs\Python\Python311\ |
Variable | Standard Priority |
Disabling Microsoft Store App Execution Aliases
The fastest way to break the stranglehold of the Microsoft Store aliases is turning them off at the system level. You don’t need a registry cleaner. You just need the Windows Settings app.
- Press the Windows Key and type Manage app execution aliases.
- Hit Enter to open the Settings panel.
- Scroll down until you find entries labeled App Installer for python.exe and python3.exe.
- Toggle them from On to Off.
Once flipped, the WindowsApps stub directory stops intercepting your terminal calls. If you try running python now, the shell looks further down the PATH string.
Configuring PATH Precedence Correctly
If disabling aliases didn’t bring your terminal back to life, your PATH variables are out of order or entirely missing the correct paths. Let us fix that permanently. We’ll use PowerShell to inspect and modify the user environment variables safely.
# Check current user PATH for Python entries
$userPath = [Environment]::GetEnvironmentVariable('Path', 'User')
$userPath -split ';' | Select-String -Pattern 'Python'
If nothing returns, Python isn’t registered in your user profile. To fix this, you must append both the main installation directory and the Scripts directory. Here is the exact architectural layout you need in your environment variables:
C:\Users\\AppData\Local\Programs\Python\Python311\ C:\Users\\AppData\Local\Programs\Python\Python311\Scripts\
When deploying this configuration at scale via Group Policy or Intune, ensure your deployment scripts target the User PATH rather than just the System PATH to avoid permission escalations during pip package installations.
Validating Your Environment with Python Launchers
Windows includes a specialized utility called the Python launcher (`py.exe`). It lives in C:\Windows\, which is almost always in the system PATH. This makes it immune to most user-level PATH corruption issues.
Instead of typing python script.py, switch your muscle memory to:
py -3.11 script.py
This bypasses ambiguity entirely. The launcher reads shebang lines inside your Python files and boots the exact interpreter version required, eliminating guesswork.
Frequently Asked Questions
Why does typing python open the Microsoft Store instead of running my script?
Windows uses App Execution Aliases to direct users to the Store when a common command line tool is missing. If these shims are active, they capture the `python` command before your shell can search your actual installation directories.
Should I install Python for All Users or Just My User Account?
For developer workstations, installing for ‘Just My User Account’ is generally superior. It prevents permission errors when installing local packages via pip and avoids requiring administrative privileges for minor updates.
What is the difference between python.exe and py.exe on Windows?
`python.exe` points to a specific installed version within a directory. `py.exe` is the Python Launcher for Windows, a master utility that manages multiple side-by-side Python versions and routes execution based on version flags or shebangs.
The Bottom Line: Actionable Next Steps
Stop reinstalling Python blindly. Take control of your environment variables today. First, disable the App Execution Aliases in your Windows settings. Second, verify that your true python directories sit cleanly in your User PATH without trailing whitespace or incorrect slashes. Finally, adopt the native `py` launcher to future-proof your local development workflows against environment drift.
