Remote Control from Mac to Windows spawns cursor-agent locally and fails with ENOENT on /c:/... paths

Support Bug Reports
,
1

Title: Remote Control from Mac to Windows spawns cursor-agent locally and fails with ENOENT on /c:/... paths

Description:

When using Cursor Remote Control from a Mac client to a Windows machine, the Cursor extension incorrectly tries to spawn the cursor-agent worker on the local Mac (leonMacBook Pro) instead of on the remote Windows host.

It passes a Windows-style workspace path (/c:/Users/zhengjiannan/code) into the local Mac process. macOS cannot resolve that path, so spawning fails:

Workspace roots: /c:/Users/zhengjiannan/code
Spawning worker "/c:/Users/zhengjiannan/code @ leonMacBook Pro"
Worker process error: spawn .../cursor-agent ENOENT
Activation failed: Failed to spawn cursor-agent-worker: no pid

Expected behavior:

The Remote Control session should spawn cursor-agent / cursor-agent-worker on the remote Windows machine, using a path that is valid in that Windows environment.

Actual behavior:

The Mac client attempts to start the worker locally and feeds it a Windows drive-letter path (/c:/...). That path is invalid on macOS, so the worker fails immediately with ENOENT / “no pid”.

Notes:

  • The same flow works when initiated from Windows, because the Windows environment can correctly interpret the /c:/... path.
  • This appears to be a cross-platform path / host-targeting bug in Cursor Remote Control, not a user configuration issue.
2

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 (cursor.com/agents, 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!

7

Version: 3.12.30
VS Code Extension API: 1.128.0
Commit: 63a2996a10d9e476b6c28e951dd7691d9c0cf480
Date: 2026-07-21T22:50:03.568Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

10

Also confirmed: Windows → Windows Remote Control works normally. The issue only happens when controlling a Windows machine from a Mac client. That strongly suggests the bug is in the Mac client’s remote worker spawning / path handling, not in the Windows host itself.

16

Thanks for the detailed report. We reproduced this end-to-end and are tracking a fix internally.

For now, please start the chat on Windows, then open that existing chat on your Mac. That currently doesn’t reproduce the bug. The issue occurs when creating a separate new chat from the Mac for the Windows workspace.

We greatly appreciate you raising this bug and we’ll keep you updated on the status of it.

17

你好则解决了吗？