The “Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases” error has been the most common Python-on-Windows message since 2019, and the message is still showing up in 2026 on a fresh install with the “Add Python to PATH” box checked. The naive answer is “turn off the App Execution Alias.” The working answer is that the message is a five-headed error: it can mean five different things, the same fix does not work for all five, and the only command that fixes it for good is the one that installs Python in a way that no longer fights the Microsoft Store alias.
The reason “python was not found” is its own question and not just “how do I install Python” is that the error is the one that shows up after the developer thinks they have installed Python. The developer ran the installer, the developer checked the box, the developer restarted the terminal, and the developer is staring at “Python was not found.” The error is the second-install problem, the second-career problem, and the second-machine problem. The error is the moment the developer realizes that “I installed Python” and “I can run Python” are two different things, and the second is the one that matters.
Table of contents
- The five things the message actually means
- The one command that fixes it for good (and the four that do not)
- The modern toolchain that makes the whole problem disappear
- The seven mistakes that quietly turn a working install into “Python was not found”
- How this fits the rest of the deploy
- FAQ
The five things the message actually means
The error message is the same in all five cases, but the cause is different in each case. The fix is different in each case. A developer who treats the error as a single bug is going to try the wrong fix three or four times before they get lucky.
1. The Microsoft Store App Execution Alias is on. Windows 10 (since 2019) and Windows 11 ship with an “App Execution Alias” that points python.exe and python3.exe at the Microsoft Store, so typing python in a terminal opens the Store instead of running the installed Python. The alias is on by default, the alias is the cause of the error for most fresh installs, and the fix is to turn the alias off in Settings > Apps > Advanced app settings > App execution aliases (or in older Windows: Settings > Apps & features > Manage app execution aliases). The fix takes five seconds, the fix is the lever that turns “the terminal opens the Store” into “the terminal runs my Python.”
2. The Python installer ran but the PATH was not updated. The Python installer has an “Add Python to PATH” checkbox at the bottom of the first screen. The checkbox is unchecked by default, the checkbox is the cause of the error for a developer who installed Python but skipped the checkbox, and the fix is to re-run the installer, click “Modify,” and check the box. The fix is the right answer for a developer who installed Python the first time and forgot, and the fix is the lever that turns “Python is on disk but not on PATH” into “Python is on disk and on PATH.”
3. The PATH was updated but the terminal is a stale session. A terminal that was opened before the PATH was updated does not see the new PATH, the terminal has to be closed and reopened, and the developer who opens a new terminal inside VS Code (which inherits the old PATH) is going to keep seeing the error until the IDE is restarted. The fix is to close every terminal and reopen, and the fix is the lever that turns “I added Python to PATH but the terminal is still confused” into “I added Python to PATH and the terminal sees it.”
4. The Python is installed but the bitness does not match the launcher. A 64-bit Python on a 32-bit PATH (or vice versa), a Python installed for the wrong user (System vs. user), a Python installed in a non-standard path that the PATH entry does not point to, or a Python installed by Chocolatey / Scoop / winget into a path that is not on the system PATH. The fix is to check where python (Windows) or which python (macOS / Linux) and confirm the binary on PATH is the one the developer thinks it is, and the fix is the lever that turns “the wrong Python is on PATH” into “the right Python is on PATH.”
5. The Python is in a virtual environment that is not activated. A developer who has activated a venv (or conda environment, or poetry shell) and then opened a new terminal, or who has run a script via the IDE without activating the environment, is going to see the error because the virtual environment’s python.exe is not on PATH. The fix is to activate the environment (venv\Scripts\activate on Windows, source venv/bin/activate on macOS / Linux), and the fix is the lever that turns “the virtual environment is off” into “the virtual environment is on.”
The five are the floor. There is also the “I have two Pythons and the launcher is picking the wrong one” case (the py launcher on Windows handles this with py -3.11 to pick a specific version), the “I am running in a Docker container and the image does not have Python” case (the fix is apt-get install python3 or a python:3.11-slim base image), and the “I am in a CI runner that does not have Python” case (the fix is actions/setup-python@v5 on GitHub Actions or the equivalent on the runner).
The one command that fixes it for good (and the four that do not)
The error has accumulated four “fixes” over the years, each of which fixes one of the five causes and not the others. The honest answer is that the one command that fixes the most cases is where python (Windows) or which python (macOS / Linux) — the command that shows which Python the terminal is actually looking at — followed by the right fix for the cause the output reveals.
The four “fixes” that do not fix everything:
“Add Python to PATH.” The fix works for the developer who installed Python without the checkbox. The fix does not work for the developer who is hitting the Microsoft Store alias (the alias overrides PATH), does not work for the developer who has a stale terminal, and does not work for the developer who has two Pythons and the wrong one is on PATH. The fix is the right answer for one of the five causes, and the fix is the wrong answer for the other four.
“Turn off the App Execution Alias.” The fix works for the developer who is hitting the Microsoft Store alias. The fix does not work for the developer who has not installed Python at all (the alias still points at the Store, but there is no real Python behind it), does not work for the developer who has a stale terminal (the alias is still off but the terminal is not seeing the new Python), and does not work for the developer who has a virtual environment that is not activated. The fix is the right answer for one of the five causes, and the fix is the wrong answer for the other four.
“Restart the terminal.” The fix works for the developer who has a stale session. The fix does not fix the underlying cause, and the fix is going to keep being needed every time the developer opens a new terminal before the PATH propagates. The fix is the right answer for one of the five causes, and the fix is the wrong answer as a “real” fix.
“Reinstall Python.” The fix works for the developer who has a corrupted install, the fix works for the developer who has a Python in a non-standard path, and the fix is the worst answer for the other three causes (the developer is going to spend 20 minutes reinstalling and still see the error). The fix is the right answer for one of the five causes, and the fix is the wrong answer for the other four.
The honest answer is that there is no single “fix” for “Python was not found.” The honest answer is that the developer has to figure out which of the five causes is theirs, and the honest answer is that the developer can do that in 10 seconds with where python (or which python on macOS / Linux) plus a look at the App Execution Alias setting.
The modern toolchain that makes the whole problem disappear
The most honest answer to “Python was not found” is to stop installing Python the old way. The most honest answer is to use one of the three modern Python version managers, each of which sidesteps the App Execution Alias, sidesteps the PATH mess, and sidesteps the “which Python is this” problem for good.
pyenv (and pyenv-win on Windows). The classic polyglot-friendly Python version manager, modeled on rbenv. pyenv installs Python into a versioned directory (~/.pyenv/versions/3.11.6/), shims python and python3 through ~/.pyenv/shims/, reads a .python-version file at the project root, and lets the developer switch versions per-project with pyenv local 3.11.6. pyenv-win is the Windows port and works the same way. The pattern is the right answer for a developer who has multiple Python projects on different versions, the pattern is the right answer for a developer who is tired of the PATH dance, and the pattern is the lever that turns “I have one Python” into “I have one Python per project.”
uv (from Astral). A Rust-based Python package and project manager that installs Python on demand, manages virtual environments, runs scripts with inline dependencies, and is dramatically faster than pip / venv / pyenv for the common case. uv python install 3.11 installs a Python into a managed location, uv run python script.py runs a script with the right Python and the right virtual environment, and uv is the right answer for a developer who wants one tool that does the whole thing. The pattern is the modern default for new Python projects, the pattern is the right answer for a developer who is starting a new project, and the pattern is the lever that turns “I have pip, venv, pyenv, and poetry and they all disagree” into “I have uv.”
rye (from Armin Ronacher). A higher-level Python project manager that wraps uv and adds project scaffolding, dependency locking with uv lock, Python version pinning, and a rye pin 3.11 command that sets the project’s Python. rye is the right answer for a developer who wants a “batteries included” Python toolchain, the pattern is opinionated, and the pattern is the lever that turns “I have too many tools” into “I have one tool that does the whole thing.”
The three are the floor. There is also conda (the data-science default, which manages Python and R and system libraries), pipx (the right answer for installing Python CLI tools in isolated environments), and Docker (the most honest version manager: the version is whatever the image says it is).
The seven mistakes that quietly turn a working install into “Python was not found”
A short, opinionated list of mistakes that have actually turned a working Python install into the error. None of them are dramatic. They are the boring ones.
Installing Python from the Microsoft Store when the developer already has a real Python install. The Microsoft Store install is a UWP app, the install lives in a different directory (%LOCALAPPDATA%\Microsoft\WindowsApps\python.exe), and the install fights the real Python for the python command. The fix is to uninstall the Store version and turn off the App Execution Alias, and the fix is the lever that turns “I have two Pythons and neither works” into “I have one Python and it works.”
Adding Python to the User PATH but not the System PATH. Some installers (and most chocolatey / scoop installs) only update the user PATH, and the developer who runs Python from a non-elevated terminal is going to see the error. The fix is to add Python to the System PATH (System Properties > Environment Variables > System variables > Path > Edit), and the fix is the lever that turns “I can run Python from my user shell but not from a system shell” into “I can run Python from any shell.”
Installing Python 2 and Python 3 and letting the launcher pick Python 2. A developer who has both Python 2 and Python 3 installed is a developer who is going to be confused by python --version returning 2.7. The fix is to use python3 explicitly, or to use the py launcher (py -3 to force Python 3, py -3.11 to force a specific version), and the fix is the lever that turns “I am running the wrong Python” into “I am running the right Python.”
Installing Python with the wrong bitness. A 64-bit Windows install with a 32-bit Python (or vice versa) is a Python that may install without errors and then refuse to load some packages. The fix is to uninstall and reinstall with the right bitness, and the fix is the lever that turns “Python is installed but every package install fails” into “Python is installed and every package install works.”
Forgetting to activate the virtual environment in a new terminal. A developer who runs python script.py from a terminal where the venv is not activated is a developer who is running the system Python, and the system Python may or may not have the project’s dependencies. The fix is to activate the venv (venv\Scripts\activate on Windows, source venv/bin/activate on macOS / Linux) or to use uv run / poetry run / pipenv run so the activation is automatic, and the fix is the lever that turns “the venv is off” into “the venv is on.”
Adding the wrong directory to PATH. A developer who adds C:\Python38\ to PATH (the install dir) but not C:\Python38\Scripts\ (where pip.exe lives) is a developer who can run python but not pip. The fix is to add both directories (the installer adds both when the checkbox is checked), and the fix is the lever that turns “`pip is not recognized” into “pip works.”
Running python in a Docker container that does not have Python. A developer who runs python inside a node:20 or alpine or debian:slim container is a developer who is going to see “Python was not found” in a fresh container. The fix is to use a python:3.11-slim base image, or to apt-get install -y python3 (or apk add python3 on Alpine), and the fix is the lever that turns “the container has no Python” into “the container has Python.”
How this fits the rest of the deploy
A Python install rarely lives in isolation. The install is usually part of a stack (a virtual environment, a Dockerfile, a CI runner, a deploy platform) that runs the Python service the project ships. The platform that handles the install should make the rest of the stack feel like part of the same conversation.
The services layer is the part of the platform that runs the long-lived Python API the project ships. The static layer is the part that hosts the dashboard the developer uses to inspect deploys. The environment variables are the part that holds the secrets the API needs to talk to the database. The Python install is the floor; the platform is what enforces the version in production.
A Python project on a platform where the runtime, the database, the storage, and the deploy logs are all in the same place is a project the team is going to be able to operate. A Python project on a platform where each piece is in a different console is a project the team is going to spend the first hour just opening the right tab.
For a team that wants to see the full cost of the project before it commits, the RunxBuild hosting calculator shows the line items together. The service, the database, the storage, the worker, the bandwidth — each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
FAQ
Why does Windows say “Python was not found” even after I install Python?
Windows ships with an “App Execution Alias” that points python.exe and python3.exe at the Microsoft Store, so typing python opens the Store instead of running the installed Python. The fix is to turn the alias off in Settings > Apps > Advanced app settings > App execution aliases, or to disable it for the App Installer entry that owns the python.exe and python3.exe shims.
How do I add Python to PATH on Windows?
Re-run the Python installer, click “Modify,” and check the “Add Python to environment variables” (or “Add Python to PATH”) box. Finish the install, then close and reopen every terminal. Alternatively, add Python’s install directory and its Scripts\ subdirectory to the System PATH manually via System Properties > Environment Variables > System variables > Path > Edit.
How do I check which Python is on PATH on Windows?
Open a terminal and run where python. The output is every python.exe on PATH in the order Windows tries them. The first one is the one that runs when you type python. If the first one is C:\Users\you\AppData\Local\Microsoft\WindowsApps\python.exe, that is the App Execution Alias and that is the one to turn off.
Does this error happen on macOS or Linux?
It can, but the cause is different. On macOS, the cause is usually that the developer installed Homebrew Python (brew install python) but the system Python (/usr/bin/python3) is still on PATH, and the developer is running the system Python. On Linux, the cause is usually that the developer installed Python via the system package manager but the python symlink points to Python 2 (Debian / Ubuntu) or to a stub script that prints “Python was not found.”
How do I use pyenv on Windows?
Install pyenv-win via Chocolatey (choco install pyenv-win) or via the GitHub release. Then pyenv install 3.11.6 to install a Python, pyenv global 3.11.6 to set the default, and pyenv local 3.11.6 to pin a project (writes a .python-version file). The shims are at ~\.pyenv\pyenv-win\shims\ and should be on PATH automatically after install.
Should I use pyenv, uv, or conda?
pyenv is the right answer if you want one tool that just manages Python versions and you are happy to manage virtual environments separately. uv is the right answer if you want one tool that does the whole thing (Python, packages, virtual environments, scripts) and you are starting fresh. conda is the right answer if you are doing data science and need to manage Python and R and system libraries in the same environment.
How do I fix “Python was not found” in a Docker container?
Use a python:3.11-slim (or python:3.11-alpine) base image instead of debian, ubuntu, or node. If you must start from a non-Python image, install Python explicitly: apt-get install -y python3 python3-pip on Debian / Ubuntu, apk add python3 py3-pip on Alpine, yum install -y python3 python3-pip on RHEL / Fedora. Verify with python3 --version inside the container.
How do I fix “Python was not found” in GitHub Actions?
Use actions/setup-python@v5 with python-version: '3.11' (or read it from a .python-version file with python-version-file: '.python-version'). The action handles the install, the PATH, and the caching, and the action is the right answer for a CI runner that does not have Python.