Remote Control worker crashes on Windows: better_sqlite3 NODE_MODULE_VERSION 127 vs 137

[jiriritaism (朝辺義弘)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Remote Control sessions are successfully published and become visible in the Cursor web Agents page, but the local Windows self-hosted worker never becomes available.

Cursor Desktop remains stuck at:

“Setting up environment”
“Waiting for a worker”

The corresponding remote session shows:

“Waiting for self-hosted worker”

The local Cursor Agent Worker does start and performs several initialization steps successfully:

• worker process starts
• Cursor API authentication succeeds
• the correct Git repository label is derived
• user privacy mode is fetched
• worker ID is registered with the browser service

However, the worker then fails while starting exec-daemon.

The worker log shows a native Node module ABI mismatch involving better-sqlite3:

Error starting exec-daemon:
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 then exits with code 1.

Because the worker crashes immediately after registration, Remote Control remains indefinitely at “Waiting for a worker”.

This issue reproduces even after completely regenerating Cursor’s local Agent CLI cache.

I fully quit Cursor, renamed the existing agent-cli directory as a backup, restarted Cursor, and allowed Cursor to generate a completely new agent-cli directory.

The newly generated Agent Worker reproduces the exact same NODE_MODULE_VERSION 127 vs 137 error.

I have not run npm rebuild, npm install, or manually modified Cursor’s generated Agent CLI files.

Additional environment checks:

• normal local Cursor Agent execution works
• Git-backed workspace is configured correctly
• branch is main
• Git remote is configured and reachable
• working tree is clean
• Remote Control session publishing works
• remote browser session visibility works
• Cursor Network Diagnostics initially detected a streaming compatibility issue under HTTP/2
• switching HTTP Compatibility Mode to HTTP/1.1 makes all Cursor Network Diagnostics pass
• Remote Control still fails after the network diagnostics are fully green

This appears to be a mismatch between the Node.js runtime used by the Windows Remote Control worker and the better-sqlite3 native binary distributed inside Cursor’s Agent Worker package.

Steps to Reproduce

1. Open Cursor Desktop on Windows 10 x64.

2. Open a local Git-backed workspace.

3. Confirm that:

   • branch is main
   • a Git remote is configured and reachable
   • working tree is clean

4. Confirm that normal local Agent execution with “This PC” works correctly.

5. Enable Remote Control in Cursor settings.

6. Run a simple read-only local Agent prompt and confirm it completes normally.

7. Run /remote-control in the same local Agent session.

8. Send a simple read-only prompt through Remote Control.

9. Confirm that the Remote Control session appears successfully in the Cursor web Agents page.

10. Observe that Cursor Desktop remains stuck at:
    “Setting up environment”
    “Waiting for a worker”

11. Observe that the web session shows:
    “Waiting for self-hosted worker”

12. Open the Cursor Agent Worker log.

13. Observe that the worker:

    • starts
    • authenticates successfully
    • derives the Git repository label
    • fetches user privacy mode
    • registers the worker ID

14. Observe that exec-daemon then fails with:

    better_sqlite3.node was compiled using NODE_MODULE_VERSION 127.

    The current Node.js runtime requires NODE_MODULE_VERSION 137.

15. Observe that the worker exits with code 1.

16. Fully quit Cursor.

17. Rename the Cursor-managed agent-cli directory to a backup name.

18. Restart Cursor and allow Cursor to regenerate a fresh agent-cli directory.

19. Retry Remote Control.

20. Observe that the newly regenerated worker reproduces the same NODE_MODULE_VERSION 127 vs 137 error.

Additional troubleshooting performed:

• Cursor Network Diagnostics initially showed a streaming compatibility issue under HTTP/2.
• HTTP Compatibility Mode was changed to HTTP/1.1.
• After this change, all Network Diagnostics pass.
• Remote Control still fails with the same worker crash.
• No manual npm rebuild or modification of Cursor-managed Agent Worker files was performed.

Expected Behavior

The Remote Control worker should start successfully and remain connected to the local Windows workspace.

After the Remote Control session becomes visible in the Cursor web Agents page, prompts sent through Remote Control should be executed by the local Cursor Agent without remaining stuck at “Waiting for a worker”.

The Cursor-managed Agent Worker package should include a better-sqlite3 native binary that is compatible with the Node.js runtime used by that worker.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

OS: Windows 10 x64

Cursor Desktop:
3.15.19

Cursor commit:
de07bee81cefe43461ebf4f40c3d2d78d15052a0

Plan:
Pro

Git:
2.55.0.windows.3

Workspace:
Local Git-backed workspace

Branch:
main

Remote host:
GitHub

Working tree:
clean

Remote client:
iPhone SE 2
iOS 18
Safari
Cursor web Agents page

HTTP Compatibility Mode:
HTTP/1.1

Network Diagnostics:
All checks pass after switching to HTTP/1.1

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed report. Your diagnosis is spot on. This is an ABI mismatch between the Node runtime inside the Windows agent-cli and the native better-sqlite3 binary, which makes exec-daemon crash and the worker exit with code 1 right after registration. That’s why it gets stuck on “Waiting for a worker” forever. Your note about HTTP/1.1 being a red herring is also correct. This issue isn’t network-related.

This is something we’re already tracking on Windows. There are similar threads here: 1, 2. I’ve passed this report to the team as well, with all the details.

Unfortunately, there’s no user-side workaround right now. Like you noticed, regenerating agent-cli reproduces the same mismatch because the incompatible binary ships as part of the bundle. I also wouldn’t recommend trying a manual npm rebuild on managed files since it’ll likely just make things more confusing.

I can’t share an exact timeline yet, but I’ll reply in the thread once there’s an update.

[jiriritaism (朝辺義弘)]

Thanks for confirming this and for passing the report to the team.

That makes sense, and it matches what I was seeing locally. Since regenerating agent-cli reproduces the same ABI mismatch, I’ll avoid modifying the managed files or attempting a manual npm rebuild.

For now, I’ll put the Windows Remote Control test on hold and continue working with the normal local Cursor workflow until a fix is available.

The rest of the setup is working correctly:

• local Agent execution works
• the Git-backed workspace and GitHub remote work
• the Remote Control session becomes visible in the web Agents page
• the failure occurs specifically when the Windows self-hosted worker starts exec-daemon

Thanks again for the quick confirmation and for tracking this internally.

I’ll keep an eye on this thread and retest Remote Control when an update becomes available.