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

Still reproducing on the newest CLI build, Agent CLI 2026.09.23-86fc751 ג€” the confirmations above stop at 2026.09.18-9a7762b, so the 09-23 package did not fix it either.

Environment: Windows 10.0.26200, Cursor 3.21.16 stable (commit 8ae78e8eee1e63479c7e0504b664bc0a80c68000, VS Code 1.128.0).

Symptom surface not yet mentioned in this thread: this also breaks the desktop Agent view, not just mobile / “Waiting for a worker”. The agent panel sits on “Reconnectingג€¦ Cancel” with no progress and no error shown in the UI. The only visible trace is Worker exited (code=1, signal=null) in the Cursor Agent Worker output, plus the familiar exec-daemon failure:

Error starting exec-daemon: The module '...\agent-cli\.local\share\cursor-agent\versions\2026.09.23-86fc751\node_modules\better-sqlite3\build\Release\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 log on this machine had 290 consecutive Error starting exec-daemon entries and not one successful start. Renaming agent-cli forced a clean re-download of 2026.09.23-86fc751, which shipped a byte-identical 1,918,976-byte better_sqlite3.node, confirming the bad binary is in the package rather than in a corrupted local cache.

A simpler workaround than replacing the .node file: swap the runtime instead of the native module. better-sqlite3 and tree-sitter in the package are both ABI-127 (Node 22) builds, so the shipped node.exe v24.5.0 is the odd one out. Dropping the official Node 22.23.3 win-x64 node.exe into the version directory makes everything consistent:

...\anysphere.cursor-agent-worker\agent-cli\.local\share\cursor-agent\versions\2026.09.23-86fc751\node.exe

After that require('better-sqlite3') loads, the worker starts and stays up, and the Agent view connects. This needs no MSVC toolchain, no npm rebuild, and no third-party prebuild ג€” just the stock Node 22 binary from nodejs.org. Same caveat as the other workaround: it lives inside a versioned cache folder, so the next CLI download reverts it.

That the whole bundle except node.exe targets ABI 127 suggests the release is pinning the wrong Node for the Windows runner. Shipping Node 22 there, or rebuilding the native modules for Node 24, would both resolve it.

Hey all, this is an issue we’re tracking. On Windows the bundled worker’s better-sqlite3 binary is built against a different Node version than the runtime it ships with, so the exec-daemon exits before the worker registers. It’s on our side, not your setup, and it affects the current Windows builds. @Kazuhiro_Watanabe the Smart App Control block on the native module is a related Windows signing issue we’re also tracking.

The reliable way to unblock today is to run the worker under WSL, which avoids both the Node mismatch and the Smart App Control block:

  1. In an admin PowerShell: wsl --install -d Ubuntu, reboot if prompted.
  2. In the Ubuntu shell: curl https://cursor.com/install -fsS | bash, then agent login.
  3. Clone your repo inside the WSL filesystem (for example ~/project, not /mnt/c/...).
  4. From that folder run agent worker start --name <your-machine>.

The native Windows worker won’t start until the fix ships. I’ll post here when there’s an update.

Version 2026.09.28-64d2043, Windows, agent worker start → better_sqlite3.node NODE_MODULE_VERSION 127 / 137 mismatch. Please try again using the agent update once the new version is released.

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (Signing in to Cursor, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.


Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?


Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)


Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)


For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…


Additional Information
Add any other context about the problem here.


Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

My Machines Windows worker fails immediately on startup because the packaged better-sqlite3 native module was compiled for NODE_MODULE_VERSION 127, while the current cursor-agent runtime requires NODE_MODULE_VERSION 137.

agent update reports that the agent is already up to date.

Steps to Reproduce

  1. On Windows, update cursor-agent:
    agent update

  2. Confirm version:
    agent --version
    Result: 2026.10.01-e373342

  3. Start My Machines worker:
    agent worker start --name “NPARK-P03”

  4. Worker immediately fails with:
    better_sqlite3.node was compiled against NODE_MODULE_VERSION 127.
    This version of Node.js requires NODE_MODULE_VERSION 137.

Expected Behavior

The Windows My Machines worker should start successfully and remain connected so it can be selected as a runtime for Cloud Agents.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

cursor-agent 2026.10.01-e373342

For AI issues: which model did you use?

N/A - My Machines worker startup issue

Additional Information

The failure occurs inside the Cursor-installed package:

C:\Users\Administrator\AppData\Local\cursor-agent\versions\2026.10.01-e373342\node_modules\better-sqlite3\build\Release\better_sqlite3.node

The repository is an isolated clean test clone.

I did NOT run npm rebuild, npm install, replace native modules, or modify Cursor package files.

Please confirm whether this is a known Windows My Machines packaging issue and whether a fixed cursor-agent build or supported workaround is available.

Does this stop you from using Cursor

No - Cursor works, but with this issue

+1 — still broken on Cursor 3.23.12 (Windows)

@mohitjain confirming this is still unfixed after 3.22.12 / CLI 2026.09.28-64d2043.

  • OS: Windows 11 (build 26200)
  • Cursor IDE: 3.23.12 (commit 2d29876d567da1607532b23bbf2cd5ddbca496f0)
  • Desktop worker CLI: 2026.10.01-e373342
  • Injected worker API key authenticates (fromEnv: false)
  • Then dies on exec-daemon:
Error starting exec-daemon: better_sqlite3.node
was compiled against NODE_MODULE_VERSION 127.
This version of Node.js requires NODE_MODULE_VERSION 137.

better_sqlite3.node SHA256 is unchanged from earlier broken CLIs
(C4B95A94A963258A9EF41B12FD3BB86F0B08A2AC5C5B499FE94DE57A5443682D).
Machine never stays listed under My Machines / iOS Remote Control.