Shims from Windows messes up with WSL

[felipecrs]

This problem is rather complex, so let me start with a reproduction:

In PowerShell:

$ winget install jdx.mise

# reload PATH
$ $env:PATH = [Environment]::GetEnvironmentVariable("PATH", "Machine") + ";" + [Environment]::GetEnvironmentVariable("PATH", "User")

$ mise use -g gh

# add shims to PATH
$ $p=[Environment]::GetEnvironmentVariable("PATH","User"); $m="$env:LOCALAPPDATA\mise\shims"; if($p -split ';' -notcontains $m) { [Environment]::SetEnvironmentVariable("PATH", "$m;$p", "User") }

# reload PATH
$ $env:PATH = [Environment]::GetEnvironmentVariable("PATH", "Machine") + ";" + [Environment]::GetEnvironmentVariable("PATH", "User")

# confirm it works
$ gh --version
gh version 2.93.0 (2026-05-27)

# start a new fresh instance if you don't want to mess up yours
$ wsl --install Ubuntu-26.04 --no-launch

# mise creates extension-less shims that WSL "sees"
# But I guess that's ok so far. VS Code also does the same.
$ wsl -d Ubuntu-26.04 bash -xc 'cd /tmp && gh --version'
+ cd /tmp
+ gh --version
/mnt/c/Users/felipecrs/AppData/Local/mise/shims/gh: line 3: exec: mise: not found

# install mise in WSL
$ wsl -d Ubuntu-26.04 -u root bash -xc 'apt update && apt install -y extrepo && extrepo enable mise && apt update && apt install -y mise'

# the same command as above
$ wsl -d Ubuntu-26.04 bash -xc 'cd /tmp && gh --version'
+ cd /tmp
+ gh --version
# infinite loop, never stops

# debug logs
$ wsl -d Ubuntu-26.04 bash -xc 'cd /tmp && MISE_DEBUG=true gh --version'
+ cd /tmp
+ MISE_DEBUG=true
+ gh --version
DEBUG Version: 2026.6.2 linux-x64 (2026-06-09)
DEBUG ARGS: mise x -- gh --version
DEBUG [vfox] Getting metadata for yarn
DEBUG config: ~/.config/mise/config.toml
DEBUG Version: 2026.6.2 linux-x64 (2026-06-09)
DEBUG ARGS: mise x -- gh --version
DEBUG [vfox] Getting metadata for yarn
DEBUG config: ~/.config/mise/config.toml
DEBUG Version: 2026.6.2 linux-x64 (2026-06-09)
DEBUG ARGS: mise x -- gh --version
DEBUG [vfox] Getting metadata for yarn
DEBUG config: ~/.config/mise/config.toml
DEBUG Version: 2026.6.2 linux-x64 (2026-06-09)
DEBUG ARGS: mise x -- gh --version
# infinite loop, never stops

I'm not sure what's the best way to fix this, but this is a super normal setup, I would say. I use Windows to develop native Windows applications while WSL to develop other ones.

Some thoughts:

1. Maybe mise and mise-shims Windows binaries should refuse to execute on WSL. That could be detected by inspecting the parent process, checking if it's wsl.exe or wslhost.exe.

   $ powershell -NoProfile -Command 'if ((Get-Process -Id (Get-CimInstance Win32_Process -Filter "ProcessId=$PID").ParentProcessId).Name -match "wsl|wslhost") { Write-Host "Invoked from WSL" -ForegroundColor Green } else { Write-Host "NOT from WSL" -ForegroundColor Red }'
   NOT from WSL
   
   $ wsl -d Ubuntu-26.04 powershell.exe -NoProfile -Command 'if ((Get-Process -Id (Get-CimInstance Win32_Process -Filter "ProcessId=\$PID").ParentProcessId).Name -match "wsl|wslhost") { Write-Host "Invoked from WSL" -ForegroundColor Green } else { Write-Host "NOT from WSL" -ForegroundColor Red }'
   Invoked from WSL

   But that isn't trivial.

2. Why do we need .cmd or extension-less shims on Windows?

   The .cmd shims are always problematic anyway. They don't work when called from UNC directories, and also ask to confirm the exit on Ctrl+C.

   Not sure when someone would use it instead of the .exe one.

   Not sure when someone would use the extension-less shim either.

   If it's for Git Bash, Git Bash seems to correctly use the .exe when the command is invoked without extension:

   $ which powershell
   /c/Windows/System32/WindowsPowerShell/v1.0/powershell
   
   # even though it's not an actual file
   $ powershell -command 'ls "C:\Windows\System32\WindowsPowerShell\v1.0\powershell"'
   ls : Cannot find path 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell' because it does not exist.
   At line:1 char:1
   + ls "C:\Windows\System32\WindowsPowerShell\v1.0\powershell"
   + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       + CategoryInfo          : ObjectNotFound: (C:\Windows\Syst...v1.0\powershell:String) [Get-ChildItem], ItemNotFoundException
       + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

   VS Code has it so that code inside WSL opens VS Code on Windows, which is a totally different use case.

Thoughts?