Resolving code vs cursor command paths for WSL2 & Windows 11 setups

For those of you who prefer using a wsl2 distro for your development environment you may be familiar with the periodic configuration quirks that come with having linux live in windows basement (wsl = windows subsystem linux)

I would like to address a simple fix for WSL2 users who want the option to open either vscode or cursor in a single command without the executable files of the latter overwriting the former.

Ideal Setup

Allow me to lay out what I consider to be an ideal "single command" scenario:

• to open the cwd in vscode:

code . 

• to open the cwd in cursor:

cursor .

seems like a reasonable default to aim for, right?

Unfortunately, cursor installs a code . (code.cmd) command along with its cursor . (cursor.cmd) command, effectively overwriting the VSCode code . command in the process.

Solution to cursor overwriting the VSCode code . command

Here's the quick fix to ensure that using cursor . only opens cursor and code . only opens vscode in your wsl2 environment:

(1) Open PowerShell with admin permissions

• The following command is extremely useful in PS

(Get-Command <command>).Source

(2) determine the file path to the underlying .cmd files powering the cursor and code commands on your machine

PS C:\WINDOWS\system32> (Get-Command cursor).Source
c:\Users\Anthr\AppData\Local\Programs\cursor\resources\app\bin\cursor.cmd
PS C:\WINDOWS\system32> (Get-Command code).Source
c:\Users\Anthr\AppData\Local\Programs\cursor\resources\app\bin\code.cmd

(3) Since it shows that both .cmd files reside in the bin folder of Cursor, target the code.cmd file for deletion using PowerShells Remove-Item "C:\Users\YourUsername\...etc" command

PS C:\WINDOWS\system32> Remove-Item "C:\Users\Anthr\AppData\Local\Programs\cursor\resources\app\bin\code.cmd"

(4) verify that the code command once again points to VSCode, not Cursor

PS C:\WINDOWS\system32> (Get-Command code).Source
C:\Users\Anthr\AppData\Local\Programs\MicrosoftVSCode\Microsoft VS Code\bin\code.cmd

(5) The fix is complete but only until Cursor's next update. Source: having to redo this process 5-10 minutes ago which is why I made this quick write-up.

How to prevent this behavior automatically even with Cursor updates?

One approach would be writing a ps1 script, and while I'm not acutely familiar with PowerShell scripting, o1-pro-gpt suggested the following:

$cursorBin = "C:\Users\Anthr\AppData\Local\Programs\cursor\resources\app\bin"
$cursorCmd = Join-Path $cursorBin "code.cmd"
$cursorExe = Join-Path $cursorBin "code.exe"

if (Test-Path $cursorCmd) {
    Remove-Item $cursorCmd -Force
}
if (Test-Path $cursorExe) {
    Remove-Item $cursorExe -Force
}

In summary, o1-pro suggested creating the above script, naming it something like RemoveCursorCode.ps1, then configuring a Scheduled Task in Windows

here's o1-pro's verbatim response:

"Set up a Scheduled Task in Windows that calls this script:

• Open Task Scheduler (Win + R -> taskschd.msc).

• Create a new Basic Task named “Remove Cursor Code”.

• Trigger: “When I log on” (or “At startup”).

• Action: “Start a program” -> powershell.exe with the -File "<path to .ps1>" argument.

• Finish.

Then every time you log in, it removes or nukes the code binaries from Cursor’s directory. If a Cursor update reintroduces them, the next time you log on, they get cleaned up again.

Note: Make sure the script is somewhere you won’t delete it by accident, >e.g. C:\scripts\RemoveCursorCode.ps1. Also, ensure your PowerShell >ExecutionPolicy is set to at least RemoteSigned or Bypass so the script can run."