Windows Remote Control worker crashes — better-sqlite3 NODE_MODULE_VERSION 127 vs 137 — Cursor 3.15.6

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Where does the bug appear?
Cursor IDE / Remote Control / Agent Worker

Describe the bug
Remote Control agents stop working and display “Waiting for a worker” or “No self-hosted workers were available for this repo.”

Investigation of the Cursor Agent Worker logs shows that the worker successfully starts, authenticates, and identifies my Git repositories, but the exec-daemon then fails because Cursor’s bundled better-sqlite3 native module is incompatible with the Node.js runtime:

better_sqlite3.node was compiled against a different Node.js version using NODE_MODULE_VERSION 127. This version of Node.js requires NODE_MODULE_VERSION 137.

The worker repeatedly restarts and encounters the same error.

Steps to reproduce

Use a local Cursor agent with Remote Control enabled.
Attempt to continue the agent locally or from the Cursor mobile app.
Agent becomes stuck at “Waiting for a worker.”
Mobile reports “No self-hosted workers were available for this repo.”
Agent worker log shows the better-sqlite3 ABI mismatch above.

Troubleshooting already performed

Completely restarted Cursor.
Rebooted Windows.
Confirmed Cursor reports no update available.
Renamed Cursor’s cached agent-cli directory so Cursor was forced to download/recreate a clean Agent CLI installation.
Cursor successfully created a fresh agent-cli, but the newly installed worker immediately reproduces the identical NODE_MODULE_VERSION 127/137 error.
Therefore the problem appears reproducible with the currently distributed Agent CLI rather than corruption of the previous local cache.

Expected behavior
The local worker should start successfully and Remote Control agents should connect to the PC.

Environment

Windows 11 x64
Cursor 3.15.6 (user setup)
Agent CLI version/build shown in worker path: 2026.08.04-aaa8809

Impact
Remote Control is effectively unusable. Existing Remote Control agent conversations cannot continue because their local worker fails to start.

Steps to Reproduce

see above

Expected Behavior

no lock up

Operating System

Windows 10/11

Version Information

3.15.6 (user setup)

For AI issues: which model did you use?

Grok 4.5

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

Hey there - thanks for the detailed report. Reinstalling won’t help here; this is an issue we’re tracking on the Windows worker package.

Interim unblock: run the worker under WSL (Linux build is fine):

  1. Install Ubuntu via WSL
  2. Inside WSL: curl https://cursor.com/install -fsS | bash (docs)
  3. agent login, then from a repo inside the WSL filesystem (not /mnt/c): agent worker start

I’ll post here when the native Windows package is fixed.

8

Thank you!

9

Any update on this? Your response was 9 days ago and you still have a broken product for Windows. Isn’t it better if you revert the latest changes so we can get the agent workers up and running again?

11

Also happening here. It don’t seems a hard fix

12

I’m also having this same issue. It makes the Windows product un-usable and I want to cancel my subscriptions until this is resolved. As others have suggested, can’t you just go back to the most recent working version? When will this be resolved?

13

Same issue here :frowning:

14

Adding another confirmed repro, on a newer build than the original report.

Not understanding the delay here and the customer optics for a CLI tool being broken on an AI driven development company are not great.

Especially since the root cause looks like a build-matrix issue rather than anything environmental. The bundled Node runtime moved from 22 (ABI 127) to 24 (ABI 137), but the Windows package is still shipping a better-sqlite3 prebuilt compiled against ABI 127. The macOS and Linux packages presumably pick up the right prebuilt, which is why WSL works and the native Windows binary doesn’t.

If that’s right, the fix is small: make sure the Windows packaging step rebuilds or re-fetches better-sqlite3 against the Node version actually being bundled (npm rebuild better-sqlite3 or pinning prebuild-install to the correct --target), and add a Windows runner to the release gate that at least runs agent worker start once. That check would have caught this on 08.04 and again on 08.11.

Not trying to pile on. The self-hosted worker is new and I expect some rough edges. But two CLI releases have shipped since the first report without picking this up, and the only workaround on offer is re-cloning the repo into WSL, which is a real cost for anyone whose toolchain lives on the Windows side. A note on whether a fix is in the pipeline would go a long way.

Environment:

  • Windows 11 x64
  • Cursor CLI build: 2026.08.11-e8db854
  • Path: %LOCALAPPDATA%\cursor-agent\versions\2026.08.11-e8db854\node_modules\better-sqlite3\build\Release\better_sqlite3.node
  • agent login succeeds; agent worker start fails immediately on exec-daemon with the NODE_MODULE_VERSION 127 vs 137 error.
19

Hopefully this help you