It’s not a solution with PowerShell, but I had the same problem except with MINGW64. I got around it by switching to Windows Subsystem for Linux (which I wanted to do anyways) as my terminal, just generally and in VSCode. This post describes it well:

How to configure VS Code (windows) to use Ubuntu App as terminal

In summary:

1) Install Ubuntu from the Windows App Store

2) Change the default bash from CMD -> wslconfig /setdefault Ubuntu

— For VSCode

3) Restart VSCode

4) In VSCode change “terminal.integrated.shell.windows” to “C:WINDOWSSystem32bash.exe” (for further details see the post above)

Running smoothly now in VSCode and WSL (Bash on Ubuntu on Windows). Might be at least a temporary solution for you.

May be you can try opening command prompt with Administrator privileges. (Run As Administrator). Works for me most of the time.

Research

All of the files in %USERPROFILE%AppDataLocalMicrosoftWindowsApps are placeholders that point to files that are actually located somewhere in C:Program FilesWindowsApps, which happens to be denied permissions completely.

It appears I was on the right track with my statement made in my duplicate of this problem:

“Seems like they didn’t really think about the distribution method screwing with permissions!”

Source: Cannot install pylint in Git Bash on Windows (Windows Store)

Permissions are screwed up royally because of the WindowsApps distribution method:

Interestingly it says that the “Users” group can read and execute files, as well as my specific user, but the Administrators group can only List folder contents for some hilariously unfathomable reason. And when trying to access the folder in File Explorer, it refuses to even show the folder contents, so there’s something fishy about that as well.

Interestingly, even though executing python in CMD works just fine, the “WindowsApps” folder does not show up when listing the files in the directory it resides in, and attempting to navigate into the folder generates a “Permission denied” error:

Attempting to change the permissions requires changing the owner first, so I changed the owner to the Administrators group. After that, I attempted to change the permissions for the Administrators group to include Full control, but it was unable to change this, because “access was denied” (duh, Micro$ucks, that’s what we’re trying to change!).

This permission error happened for so many files that I used Alt+C to quickly click “Continue” on repeat messages, but this still took too long, so I canceled the process, resulting in this warning message popping up:

And now I am unable to set the TrustedInstaller user back as the owner of the WindowsApps folder, because it doesn’t show up in the list of Users/Groups/Built-in security principles/Other objects. *

*Actually, according to this tutorial, you can swap the owner back to TrustedInstaller by typing NT ServiceTrustedInstaller into the object name text box.

Solution

There is no solution. Basically, we are completely screwed. Classy move, Microsoft.

This appears to be a limitation in git-bash. The recommendation to use winpty python.exe worked for me. See Python not working in the command line of git bash for additional information.

save you time :
use wsl and vscode remote extension to properly work with python even with win10
and dont’t forget virtualenv!
useful https://linuxize.com/post/how-to-install-visual-studio-code-on-ubuntu-18-04/

The simplest thing to do would be to modify your PATH and PYTHONPATH environmental variables to make sure that the folder containing the proper python binaries are searched befor the local WindowsApp folder. You can access the environmental variables by opening up the control panel and searching for “env”

Adding the Local Python Path before the WindowsApps resolved the problem.

This issue is far too common to still be persistent. And most answers and instructions fail to address it. Here’s what to do on Windows 10:

1. Type environment variables in the start search bar, and open Edit the System Environment Variables.

2. Click Environment Variables…

3. In the System Variables section, locate the variable with the key Path and double click it.

4. Look for paths pointing to python files. Likely there are none. If there are, select and delete them.

5. Create a new variable set to the path to your python executable. Normally this is C:Users[YOUR USERNAME HERE]AppDataLocalProgramsPythonPython38. Ensure this by checking via your File Explorer.

   Note: If you can’t see AppData, it’s because you’ve not enabled viewing of hidden items: click the View tab and tick the Hidden Items checkbox.

6. Create another variable pointing to the Scripts directory. Typically it is C:Users[YOUR USERNAME HERE]AppDataLocalProgramsPythonScripts.

7. Restart your terminal and try typing py, python, python3, or python.exe.

Workaround: If you have installed python from exe follow below steps.

Step 1: Uninstall python

Step 2: Install python and check Python path check box as highlighted in below screentshot(yellow).

This solved me the problem.

This is due to the way Windows App Execution Aliases work in Git-Bash.

It is a known issue in MSYS2 failing to access Windows reparse points with IO_REPARSE_TAG_APPEXECLINK

As a workaround, you can alias to a function invocation that uses cmd.exe under the hood.

Add the following to your ~/.bashrc file::

function python { cmd.exe /c "python $1 $2 $3";}

For python, I’d recommend just toggling off app execution aliases as in the accepted answer, but for libraries that are distributed exclusively through the windows store like winget, this is your best option.

Further Reading

• bash: Local/Microsoft/WindowsApps/python3: Permission denied
• Permission Denied when running from bash
• winget does not run in WSL2 due to exec format error #234

For me, I tried manage app execution aliases and got an error that python3 is not a command so for that, I used py instead of python3 and it worked

I don’t know why this is happening but It worked for me

I experienced the same issue, but in addition to Python being blocked, all programs in the Scripts folder were too. The other answers about aliases, path and winpty didn’t help.

I finally found that it was my antivirus (Avast) which decided overnight for some reason to just block all compiled python scripts for some reason.

The fix is fortunately easy: simply whitelist the whole Python directory. See here for a full explanation.

Add the path of python folder in environmental variable and it will work

1.search environmental variable

2.look for system variable section and find variable named path in it

3.double click on path and add new path which directs towards python folder and that’s it.

the python folder is usually in
C:Users["user name"]AppDataLocalProgramsPythonPython39

Simple answer: replace python with PY everything will work as expected

I had this to Run /execute but was not working

python3 -m http.server 8080

after reading and trying some of the solutions above and did not worked , what worked for me was

python -m http.server 8080

For people coming to this question wanting to use the Microsoft Store version of Python, and after the related "Manage app execution aliases" fix by @Zooba has likely happened, and are using Git for Windows git-bash (also known as BASH through msys2 mintty), the solution is likely simply to remember to make the call with winpty.’

winpty python3

However, if the system has had other versions of Python, make sure those copies have been removed (e.g. those installed from python.org) or are contained to their specific bundled application (e.g. OSGeo4W) (may require re-ordering environment variables).

Why, if winpty is forgotten, is it a permission error? For the first time it runs, the Microsoft Store stubs are conflicting with the permissions available to msys. A lot of the other answers go into the details of what is going on and why it feels weird. The short answer, is that the stub is trying to be a convenience short-cut to the Microsoft Store. If you launch it with winpty, it can do that. After that first time, it continues to need winpty for both related and unrelated reasons to the Microsoft Store.

In Windows 10

• Open Control Panel
• Click System
• Click the Advanced system settings link
• Click Environment Variables button
• In the System Variables section find the PATH environment variable and select it
• Click Edit (If the PATH environment variable does not exist, click New)
• In the Edit environment variable window specify the value of the PATH environment variable
• Click OK
• Close all remaining windows by clicking OK
• Reopen Command prompt window and run python --version

make sure C:Python39 and C:Python39Scripts are added to both system path variables and user path variables