macOS self-hosted worker, `agent worker --computer-use start` crashes at startup

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

This has been tested only on an Intel Mac with Tahoe.

On a macOS self-hosted worker, agent worker --computer-use start crashes at startup. The worker re-execs into the signed worker binary (cursor-agent-worker-sea), which immediately aborts with:
Error: Filesystem createRequire is disabled in the self-contained worker SEA

Without --computer-use the worker starts and runs fine. So computer use is unusable on macOS.

Root cause: polished-renderer/native.js calls createRequire(__filename) outside its try/catch. The worker SEA disables filesystem createRequire, so that line throws uncaught. polished-renderer is imported eagerly on the computer-use startup path, so every --computer-use start dies.

Setting CURSOR_AGENT_ALLOW_UNSIGNED_COMPUTER_USE=1 avoids the crash (the worker stays plain node), but then CUCursorService rejects the connection because its local-RPC admission only trusts Anysphere-team peers (requiredTeamIdentifier DCNK4UB866), and node is team HX7739G8FX. Every action returns Computer use failed, even with Accessibility and Screen Recording correctly granted to Cursor Computer Use. So both paths are dead ends.

Steps to Reproduce

  1. agent worker --computer-use start on macOS → crash (createRequire error above).
  2. Retry with CURSOR_AGENT_ALLOW_UNSIGNED_COMPUTER_USE=1 → worker starts, but every computer action returns Computer use failed.

Expected Behavior

–computer-use worker starts, and screenshots/clicks work with the granted permissions.

Operating System

MacOS

Version Information

cursor-agent 2026.09.02-c22c1a3 (current stable per Cursor CLI — Run Agents in Terminal, GitHub Actions and Automations & Scripts).

Additional Information

The agent can work around using osascript calls but that requires giving the terminal heightened permissions, which isn’t ideal.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Yep I can confirm same behavior on my mac

My mac does show exact same behavior too

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

On Apple Silicon macOS, a My Machines worker runs fine via the JS entrypoint (node --use-system-ca index.js worker …). Enabling computer use fails:

  1. agent worker --computer-use start (or the same flags on the JS worker) prints that the macOS CLI is unsigned and downloads a Developer ID-signed SEA to ~/.cursor/cursor-agent-sea/cursor-agent-worker-sea.
  2. That SEA process then crashes. Previously we also hit Filesystem createRequire is disabled in the self-contained worker SEA when using …/versions/<ver>/cursor-agent-worker-sea.
  3. Cursor Computer Use.app can be installed and passes agent worker debug (Computer use Ready: yes, Mac app: yes), but without a surviving --computer-use worker start, computer-use is never advertised to Cloud Agents.
  4. agent update reports already up to date. Pre-placing the app / CUA_SERVICE_APP does not bypass the signed-SEA gate.

Workaround for non-GUI work: keep SEA aside and run the JS worker without --computer-use (shell/git/file tools work).

Steps to Reproduce

  1. macOS Apple Silicon; install Agent CLI; agent login.
  2. Confirm JS worker works:
VER="$HOME/.local/share/cursor-agent/versions/$(ls "$HOME/.local/share/cursor-agent/versions" | tail -1)"
mv -f "$VER/cursor-agent-worker-sea" "$VER/cursor-agent-worker-sea.bak" 2>/dev/null || true
"$VER/node" --use-system-ca "$VER/index.js" worker --name repro-mac --worker-dir "$PWD" --idle-release-timeout 0 start

→ Worker connects.
3. Stop it. Start with computer use:

agent worker --computer-use --name repro-mac --worker-dir "$PWD" start
  1. Observe: “Downloading a Developer ID-signed CLI…”, install under ~/.cursor/cursor-agent-sea/, then SEA crashes (createRequire / broken SEA runtime dump). Worker does not stay up with computer-use advertised.

Optional: manually install CUA; agent worker debug shows Ready/Mac app yes; --computer-use still dies.

Expected Behavior

--computer-use should keep a healthy worker, launch/use Cursor Computer Use.app, and advertise computer-use. Signed SEA (if required) should not crash with createRequire.

Operating System

MacOS

Version Information

  • Agent CLI: 2026.09.02-c22c1a3 (agent update → already up to date)
  • CUA app present: ~/.cursor/cursor-computer-use/Cursor Computer Use.app (0.0.13; notarized Team ID DCNK4UB866)
  • Signed SEA downloaded to: ~/.cursor/cursor-agent-sea/cursor-agent-worker-sea
  • Operating system: macOS 26.6.2 (Build 25G83), arm64 (Apple Silicon Mac mini)

Additional Information

Screenshots / Screen Recordings

N/A — terminal failure. Happy to attach full SEA stderr if useful.

Additional info

  • Docs followed: Computer use and desktop sharing | Cursor Docs
  • Related packaging issues (different symptoms): forum thread on --share-desktop helper missing on macOS (2026.08.25 build).
  • Privacy: Ghost mode off / non-privacy worker visible.

Does this stop you from using Cursor

Yes - Cursor is unusable

Yea I getting this in terminal

Using Developer ID-signed CLI next to this install: /Users/thien/.local/share/cursor-agent/versions/2026.09.02-c22c1a3/cursor-agent-worker-sea
Error: Filesystem createRequire is disabled in the self-contained worker SEA

Hey all, thanks for the confirmations, and sorry for the wait on this.

Quick status update: the current CLI release (2026.09.02) still has this issue, so agent worker --computer-use start on macOS will keep exiting with the createRequire error for now. It affects both Intel and Apple Silicon Macs. I’ve added everyone’s reports here to the internal tracking issue.

We’ll update you here when there’s more to share!

Hey @TWhid,

Following up on this: the agent worker --computer-use start crash on macOS (the createRequire error from the signed worker) is fixed in the current CLI release, 2026.09.08.

Run agent update (or reinstall via Cursor CLI — Run Agents in Terminal, GitHub Actions and Automations & Scripts) and start the worker again. One note: the crash came from the signed worker binary that ships alongside your installed CLI, so make sure the agent you launch is the updated one. agent --version should show 2026.09.08.

Thanks for the report and the confirmations. Let me know if you still hit it after updating.

cc @Thien @jelly_nexus @dafpath

yep it’s working now after new update. thx

Looks good. Thanks.