"EACCES: permission denied" if additional executable with same name appears on `PATH` when using `@actions/exec`

[Vampire]

I use @actions/exec in my setup-wsl GitHub Actions action to do various tool runs.

One of the tools that is run is wsl. To use WSLv2 on windows-2022 currently, you have to do a wsl --update first. To use any version of WSLv2 on windows-2025 currently, you have to do a wsl --install --no-distribution first.

Both of these commands add an addtional wsl.exe link to C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps - which is on the PATH - that was not there before.

If you now use exec() to run a wsl command, you always get

Unexpected error attempting to determine if executable file exists 'C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps\wsl.EXE': Error: EACCES: permission denied, stat 'C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps\wsl.EXE'

spamming the build output.

To reproduce, first do a wsl --update through exec(), then a wsl --status through exec() on a windows-2022 image that does not yet have https://github.com/actions/runner-images/issues/10563 done.

[ssbarnea]

>where wsl
C:\Users\runner\AppData\Local\Microsoft\WindowsApps\wsl.exe
C:\Windows\System32\wsl.exe

First one is a symlink, second one is an executable. It is a bit confusing to see an error with the uppercase extension (as most FS outside Windows world are case-sensitive).

I suspect that we could remove the symlink as both locations are in PATH to avoid the error, but I still think that the error should not happen because Windows does allow execution of the symlink without any problems, so the stat check is broken, it should pass.

I raised https://github.com/actions/toolkit/pull/1953 which should fix the issue but considering that nobody looked at the issue so far and that they don't even run the CI w/o approval,... it might take a lot of time to get someone attention.

With a bit of luck maybe @thboop, @luketomlinson or @Link- might see #1953 and review it.