The command name can point at a packaged alias under the WindowsApps command path.
When you type python --version, does Windows open Microsoft Store or an install prompt?
That result usually means Windows is routing the command through an app-execution alias or Python manager path instead of launching the runtime you expected. I do not want you switching aliases off blindly. First we confirm the exact symptom.
python --versionsafe diagnosticCan py still reach a Python runtime?
Current Python Install Manager setups can expose both python and py. If py works while python opens an install route, Python may already be reachable and the broken layer is the plain command route.
py --versionread-onlyAsk Windows what it currently finds for python.
where.exe python is read-only. It can show whether the current terminal sees a WindowsApps alias route, another Python executable, multiple matches, or nothing useful. The result is evidence; it is not a reason to delete PATH entries.
where.exe pythonread-onlyRefresh the Python app-execution alias instead of disabling random aliases.
Python's current Windows troubleshooting guidance says to open Manage app execution aliases, make sure the Python default aliases are enabled, and if they are already enabled, disable and re-enable them to refresh the command. It also says the WindowsApps directory must remain available through the user PATH. Do not wipe PATH or switch unrelated aliases just to force python to behave differently.
Open a new terminal and run python --version again.
A fresh terminal matters because command-routing changes may not be reflected in a terminal that was already open. We only call this fixed if the original Store/install-prompt behavior is gone.
python --versionverification
python already launches Python here.
The Store-routing symptom is not present in this terminal. If it happens only in another app or terminal, diagnose that specific context instead of changing a working system-wide command.

The plain python command no longer opens the Store route. 😎
We changed only the proven alias/command-routing layer, opened a fresh terminal, and verified the original symptom.

The reviewed alias path did not resolve it.
Do not start deleting Python folders or stripping PATH entries. The remaining cause may involve multiple Python installations, an old launcher, a manager configuration, or another command route that needs a deeper branch.
This focused journey only covers Store/install-prompt routing.
Access errors, crashes, plain command-not-found errors, and IDE-only failures need different evidence. Use the broader FIX routes instead of changing aliases for a symptom they did not cause.
An app-execution alias can own the command name before the runtime you expected ever launches.
Windows app-execution aliases are short command names published by packaged apps. Python's current Install Manager integrates with that mechanism, and Windows also uses aliases to help users reach a Python installation route. That is why seeing Microsoft Store or an install prompt is not the same symptom as “Python is definitely missing.” It tells us that Windows resolved the name to an alias route. FIX then checks whether py can already reach Python and what where.exe python shows before suggesting a settings change.
A Python runtime may already exist and be reachable through py or another route.
The only useful outcome is whether a fresh terminal now launches the intended Python instead of the install route.
Do not use old “turn every Python alias off” advice as a universal fix.
Current Python Install Manager behavior is different from older Windows/Python setups. Python's present troubleshooting guidance can require the default Python aliases to be enabled and refreshed, not blindly disabled. Multiple installations and legacy launchers can also change what py means. ITFixLab therefore treats the current machine's observable result as stronger evidence than an old screenshot from an installer tutorial.