Cursor is completely broken after the update

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After updating, I spent 5 hours with the paid AI trying to fix, but ended up with now I am no longer allowed to use WSL with Cursor.

but the worst part is the AI telling me this:

I’m sorry I can’t do more from my end. You deserve an actual response from the team, especially as a paying member with a blocking issue.

when it very well knows there is not a way to speak with a human, it seems they are just taking my money now without offering what I am paying for.

when the AI has to lie to me, this is a bigger issue then it appears.

Steps to Reproduce

install old version, update it to latest version, now it is broken

Expected Behavior

WSL was working for over 5 years, and over 6 weeks with Cursor before the update, I would expect a better explanation for as to why WSL is no longer supported.

Operating System

Windows 10/11

Version Information

Version: 3.5.33 (user setup)
VSCode Version: 1.105.1
Commit: aac81804b986d739acab348ed96b8bea6e83cc50
Date: 2026-05-22T06:47:48.039Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Additional Information

I am a paid pro member, after updating, Cursor broke, and now I am no longer able to use WSL with Cursor, which is a big problem for me.
I understand—WSL integration is critical for your workflow. Let me find the right troubleshooting guide.

Read help article: network
Read help article: install-issues
These guides cover SSH and remote connections, but not WSL specifically. Since you’re having issues after an update, here’s what to try:

Restart Cursor fully — Close it completely and reopen. Updates sometimes need a full restart to apply properly.
Check if WSL connection still works — Open your WSL folder again in Cursor and verify the remote connection loads.
Run network diagnostics — Go to Cursor Settings > Network and click Run Diagnostics to check for connection issues.
Clear cached state — Open the command palette (Cmd/Ctrl+Shift+P) and run Clear Editor History.
If these don’t help, I’d recommend reporting this as a bug with details about what error you’re seeing. You can use Help > Report Issue (or Cmd/Ctrl+Shift+P > “Report Issue”) to file it with system logs.

What error or behavior are you seeing when you try to connect to WSL?

I have already spent over 5 hours using AI to help, including you, is there any way I can speak with a human?
I’m sorry you’ve been troubleshooting this for so long. Yes, you can reach Cursor’s human support team:

Email: [email protected]

Community forum: https: // forum . cursor . com

Since you’re a paid Pro member with a critical issue after an update, emailing support directly is your best option. Include:

What you see when you try to connect to WSL (error message, blank screen, etc.)
Your OS and Cursor version (Help > About)
A Request ID from the Report Issue dialog (Help > Report Issue)
They should prioritize paid member issues. I’m sorry the troubleshooting didn’t resolve it.

I tried both of those steps, I sent many, many emails to hi @ cursor . com, and I started a ticket in the forums, is my only other option to quit the paid service?
I’m genuinely sorry you’re in this situation. If you’ve already exhausted those channels and haven’t gotten a response, that’s frustrating.

A few last options:

Check your spam folder — Sometimes support replies end up there by mistake.
Follow up on your forum ticket — Link to it in a follow-up email to hi @ cursor . com mentioning you’ve been waiting days without response.
Try the in-app bug reporter again — File another report via Help > Report Issue. Include “WSL broken after update” and reference your previous emails so they see the history.
Contact through your payment method — If you paid by credit card, you can dispute the charge through your bank/card issuer, which usually escalates support urgently.
I don’t have access to internal support queues or escalation paths beyond what I’ve shared. If support truly isn’t responding after multiple attempts, that’s a legitimate concern about service quality—and you’d be right to consider whether the paid plan is worth it under those circumstances.

I’m sorry I can’t do more from my end. You deserve an actual response from the team, especially as a paying member with a blocking issue.

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Hey @toddnagel , this looks like a known post-update WSL regression, not removed support. Can you share the exact error and Remote-WSL output? In the meantime,
try:
remove ~/.cursor-server
in WSL, and also
wsl --shutdown

Ensure only anysphere.remote-wsl is enabled (not Microsoft’s), and if needed roll the WSL extension to v0.08 then back. If still broken, downgrading Cursor to 3.3 temporarily is a workaround others used.

You can check those 2 other thread with the same underlying issue :

6

Hey Todd. Sorry you had to go through that. Spending 5 hours talking to AI and still not getting a fix really sucks, especially when you need to work. I’m @deanrie from the Cursor team, let’s look at what actually happened.

What the AI told you, reach out to the team, wasn’t wrong. I’m that team. We just handle most support through the forum rather than private ticketing for individual Pro users. That’s not an excuse for a slow reply, just context.

On the actual issue. Nobody disabled WSL for you. This is a known regression after a Windows update. In your second thread 161472 Cursor is completely broken after update you can see the root cause:

Failed to patch code.sh launcher: ENOENT: no such file or directory,
open 'd:\Development\cursor\resources\app\bin\code'

This means the Windows updater didn’t finish writing the launcher file during the reinstall phase, so the WSL resolver has nothing to patch. We’re tracking the issue, but I can’t share an ETA for a fix yet.

What you can do right now. This workaround from @Tom_Coustols Lousy customer support - #4 by Tom_Coustols is confirmed by other threads:

  • In WSL: rm -rf ~/.cursor-server
  • In PowerShell: wsl --shutdown
  • Make sure only anysphere.remote-wsl is enabled, not Microsoft Remote-WSL
  • If that didn’t help, do a full reinstall of Cursor to the default path %LOCALAPPDATA%\Programs\cursor, not d:\Development\cursor\. A non-standard install path is very likely what breaks the updater for you.
  • Alternative. Roll back to the previous stable build. Links to older versions are in thread 153737 Can't connect to WSL anymore

Try these steps and reply here with where it fails and the new error text if it still shows up. Then we can debug it more directly. I’m going to close thread 161472 as a duplicate so the full history stays in one place, is that ok?

7

I tried all of that, none of it worked, so I am going back to an older version now.

before the update, I think I was on 0. something, now it is 3.5, so wow, not looking good.

seems like ‘This will help figure out whether 2.6.12 shipped without that file or if the install got corrupted.’ was the last i saw in the link you sent, so I will try to install anything before 2.6.12 and see if it works, I did open 2 tickets because I can not find the old one anymore, so I am just leaving this window open all day while I work on this problem.

over 6 hours into trying to solve this, this really sucks.

valuable lesson learned though, never update anything until they force it on you I suppose.

8

Thanks for getting back to me, Todd. Spending 6 hours on a problem like this really sucks.

A couple quick notes before we roll back.

About versions. Everything’s normal here. Cursor was on 0.x until the 1.0 release last year, then it went 1.x → 2.x → 3.x. If you were on an older 0.x build and didn’t update for a long time, jumping to 3.5 looks wild, but the versioning is fine and nothing is broken there.

About the rollback. Let’s speed this up. Tell me what version you were on and I can send you a direct link to a stable installer that works. The last 2.x build where WSL still worked well is a good option.

Important for install:

  • Install to the default path %LOCALAPPDATA%\Programs\cursor, not d:\Development\cursor\. A custom install path is most likely what breaks the updater and launcher, because Inno Setup expects the standard layout.
  • Right after install, turn off auto updates: Settings → Application → Update Mode → Manual. Otherwise 3.5 will reinstall itself in a day and you’ll hit the same issue again.

I’ll close the duplicate thread 161472 myself so we don’t split the discussion. Let’s continue here.

On the 3.x fix timeline, I can’t promise anything. The issue is being tracked, but there’s no ETA. For now, we’ll get you unblocked with a rollback.

9

Seems like it was actually a bug, after a 12 hour day.. about 6 hours of pure debugging, the rest just being emotionally exhausted.

Ended up with a blend of support from Cursor, and the AI itself doing it’s best:

Great data - this gives us a definitive diagnosis.

The diagnosis (and the blame)

Look at this:

drwxr-xr-x 2 cryptocreepn cryptocreepn 4096 May 24 22:40 .

drwxr-xr-x 2 cryptocreepn cryptocreepn 4096 May 24 22:40 ..

That hash directory is completely empty. The Cursor WSL extension created ~/.cursor-server/bin/aac81804.../ at 22:40, then the server tarball download/extract step silently failed and left an empty husk behind. Every subsequent connect attempt sees “directory exists, must be good” and tries to run a cursor binary that was never extracted.

Who to blame: not Microsoft. Your WSL itself is fine - the filesystem is healthy, there’s 122GB free, x86_64 arch, no noexec issues, no systemd weirdness. Microsoft did nothing wrong here. The culprit is Anysphere’s remote-wsl-1.0.13 extension: its bootstrap logic checks “does the hash dir exist?” instead of “does the cursor binary exist?”, so once the first download failed (probably a network hiccup, a 403 from their CDN during the update rollout, or the post-update extension trying to fetch a build that wasn’t yet published), it got stuck in a broken state forever. Classic “exists != complete” bug.

You can absolutely yell at them; this is a known footgun in VSCode’s remote-server bootstrap that they inherited and never fixed.

The fix

Let me look at exactly what URL their extension tries to download from so we can do it manually.

Got it. Vindicated - Microsoft is innocent. I just read Anysphere’s own installer script and the bug is right there in plain sight. Look at line 96 of wslDownload.sh:

if [ ! -d “$VSCODE_REMOTE_BIN/$COMMIT” ]; then

That check is “does the directory exist?” - not “does the cursor binary exist?” So the entire install/download/extract block (lines 97-178) gets skipped whenever the hash directory exists in any state, including the empty husk you have right now. Your first connect attempt downloaded a tarball, hit a transient error somewhere in the extract (or mv between $COMMIT-$TIMESTAMP and $COMMIT), left behind an empty aac81804.../ directory, and every retry since has been a no-op. The script literally exits 0 saying “already installed” while there’s not a single file inside.

What the check should be:

if [ ! -x “$VSCODE_REMOTE_BIN/$COMMIT/bin/remote-cli/cursor” ]; then

That’s a one-character fix (-d → -x plus the path) that Anysphere should ship. Worth filing with them. You’ve been burned by 6 hours of a one-line bug in their bootstrap.

The fix (10 seconds)

Run this in WSL:

rm -rf ~/.cursor-server/bin/aac81804b986d739acab348ed96b8bea6e83cc50

That’s it. Then in Cursor on Windows: bottom-left green >< button → Connect to WSL (or just reopen the WSL window). With the empty husk gone, the script’s [ ! -d ] check finally evaluates true, the install block actually runs, and it downloads + extracts properly.

If the redownload also fails (do it manually)

If reconnecting from Cursor still doesn’t populate the directory, the script’s download URL is on line 68:

https://cursor.blob.core.windows.net/remote-releases/aac81804b986d739acab348ed96b8bea6e83cc50/vscode-reh-linux-x64.tar.gz

So you can sideload it yourself:

HASH=aac81804b986d739acab348ed96b8bea6e83cc50

rm -rf ~/.cursor-server/bin/$HASH

cd /tmp

wget “https://cursor.blob.core.windows.net/remote-releases/${HASH}/vscode-reh-linux-x64.tar.gz” -O cursor-server.tar.gz

# sanity check: should be tens of MB, not a 404 HTML page

ls -lh cursor-server.tar.gz

file cursor-server.tar.gz

mkdir -p ~/.cursor-server/bin/$HASH

tar -xzf cursor-server.tar.gz -C ~/.cursor-server/bin/$HASH --strip-components 1

# verify the binary the WSL extension is looking for now exists:

ls -la ~/.cursor-server/bin/$HASH/bin/remote-cli/cursor

If that last ls shows a real executable file, you’re done - reconnect from Cursor and it’ll work.

Why this happened now specifically

The Cursor update flipped the expected server commit from whatever you had before to aac81804.... Anysphere’s installer dutifully created the new hash dir, kicked off the download, hit one transient failure (could be anything - DNS hiccup, blob storage 5xx during their rollout, your laptop sleeping mid-download, a tar verify mismatch on line 172-176 that did rm -rf "${VSCODE_REMOTE_BIN:?}/$COMMIT" but then something else recreated the empty dir, etc.), and the buggy directory-existence check cemented it as broken forever.

Six hours of debugging blamed on one wrong test flag in a shell script. You can absolutely send that bug report.

So the manual download is now downloading, at 15%, going to be an all nighter, so I will do that thing called sleep and see what the morning brings!

12

This is a serious RCA, Todd. Thanks for coming back and writing it all up. The pointer to wslDownload.sh line 96, where it checks [ ! -d ] instead of checking for the actual binary, is especially valuable. That’s exactly what was missing from reports from other users who fell into the same tarpit. Six hours of debugging didn’t go to waste, you basically did our team’s work for us, huge thanks.

Quick summary for anyone who finds this thread later:

  • Symptom: after a Cursor update (Windows to WSL), the WSL connection hangs or crashes even though ~/.cursor-server/bin/<commit>/ exists.
  • Cause: the bootstrap script only checks that the hash directory exists, not that the bin/remote-cli/cursor binary exists inside it. One failed extract leaves an empty shell, and all later attempts become a no-op.
  • Fix (10 seconds):
    rm -rf ~/.cursor-server/bin/<commit-hash>
    then reconnect from Cursor. If the re-download fails again, sideload manually:
    HASH=<your-commit-hash>
wget "https://cursor.blob.core.windows.net/remote-releases/${HASH}/vscode-reh-linux-x64.tar.gz" -O /tmp/cursor-server.tar.gz
mkdir -p ~/.cursor-server/bin/$HASH
tar -xzf /tmp/cursor-server.tar.gz -C ~/.cursor-server/bin/$HASH --strip-components 1

On our side, I’ll file a separate bug for the team with your diagnosis and the one-line fix -d to -x on the correct path. I won’t promise an ETA, but now we have a concrete signal instead of just “WSL broke after an update”.

Message back in the morning if it worked after manually unpacking the tarball. If it did, I’ll mark your post #9 as the solution so the next affected users go straight to it.

15

shoot, so the AI and support led me to believe the 6 hour manual download was the only way, but after waking up once, i noticed the download broke and restarted at 0 so was going to take another 6 hours to download.

so I took it up with the AI, and of course, it said it knew a better way, and did it in about 2 minutes total.

strange anyone thought 6 hours download for the file I needed was the solution.

anyways, it is fixed, and just got github and extensions all going well, so going back to sleep now for a few hours then i have to work at mega mega speed instead of just mega speed to catch up for lost time.

so in AI time, this 1-2 day ordeal is like, what, 6 weeks of old world development time?

I went to the future but then had to come back to reality for a bit, crazy.

16

Glad everything’s working now, Todd. And thanks for coming back with an update, it’s genuinely helpful for the next user who runs into this thread.

About the 6-hour download, yeah, that’s a weird approach. Looks like the AI suggested wget for vscode-reh-linux-x64.tar.gz without a mirror or resume support, so it just restarted from zero on every disconnect. Good call prompting the AI again, turns out there is a proper path.

Your RCA on wslDownload.sh line 96 ([ ! -d ] instead of checking the actual binary) has already been sent to the team with a concrete one-line fix. I can’t promise an ETA, but now engineering has a precise signal instead of a vague “WSL is broken”.

Marking your post as the solution so the next user lands on the working fix right away.

Also, before the next update, set Update Mode → Manual (Settings → Application) so 3.5 doesn’t auto-reinstall and break the launcher again. And when you get a chance, it’s worth migrating your custom install path (d:\Development\cursor\) back to the default %LOCALAPPDATA%\Programs\cursor, that custom path is what breaks the Inno Setup updater.

Good luck catching up, and ping me if anything else comes up.