Bug: Project CreateAgent cannot dispatch to a connected My Machines worker

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Where does the bug appear (feature/product)?

Cloud Agent / Projects coordinator — CreateAgent placement onto a My Machines (self-hosted) worker.

Describe the Bug

A Project coordinator can list a connected personal self-hosted worker (list-self-hosted-workers: idle, eligibleForSubagent: true, correct repo) but cannot spawn a child onto it.

CreateAgent with:

{ "machine": { "type": "self_hosted_worker", "worker_id": "<id from list-self-hosted-workers>" } }

always returns:

Error creating agent: Tool failed; this may be temporary. Try again.

No error body, no dashboard event, no spawn log. The child is never created.

The same coordinator can spawn managed cloud VMs (CreateAgent without machine, including model: composer-2.5). Those children all have usePrivateWorker: false / privateWorkerId: null.

This blocks watching GitHub PRs from a Project and then running a local tool that needs the operator machine (here: npm run task , which needs local .env). The operator is forced to start that task by hand.

Steps to Reproduce

  1. Start a Project (managed cloud VM).
  2. Connect a personal My Machines worker with the repo checked out. Confirm it appears in list-self-hosted-workers as idle.
  3. From the Project coordinator, CreateAgent with machine: { type: "self_hosted_worker", worker_id: "<that workerId>" } and any short prompt.
  4. Observe the opaque tool error. get-events for the Project run stays empty. list-cloud-agents with isSelfHostedWorker: true stays at 0.

Controls:

  • CreateAgent without machine → succeeds (cloud VM).
  • CreateAgent with machine.type: self_hosted_pool → same opaque Tool failed.
  • CreateAgent with worker_id set to the machineId (not workerId) → proper error: The requested self-hosted worker is not connected. So the create API is reachable; the valid worker-id path dies later with no body.

Expected Behavior

CreateAgent targeting a listed, idle, eligible My Machines worker should create a child on that worker (or return a specific error: permissions, GitHub app, repo mismatch, etc.). It should not swallow the failure as Tool failed; this may be temporary with zero telemetry on the parent run.

Operating System

MacOS
Linux

Version Information

Cursor 3.20.10 (Universal)
Project run model: cursor-grok-4.6-medium
Successful cloud children: composer-2.5

Additional Information

Related: SDK POST /v1/agents with env.type: "machine" does GitHub-app branch validation the dashboard My Machines path skips — SDK can't start a chat with a self-hosted "My Machines" worker

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @tc-gligor, thanks for the detailed report.

For accounts on a Team plan, launching agents on My Machines / self-hosted machines is controlled by team-level toggles, and on your team both of them are currently off. Your Project can still list the connected machine, but the launch itself is rejected server-side. The coordinator then reports that as a generic “Tool failed; this may be temporary” instead of the real reason, which is something we should fix.

  1. Go to cursor.com/dashboard and open Cloud Agents.
  2. Scroll to the Self-hosted Machines section.
  3. Turn on “Enable Remote Control for Team” (this is the one that allows targeting a specific My Machines worker).
  4. If you also want pool-style placement (machine.type “self_hosted_pool”), turn on “Enable Self-hosted Machines” as well.
  5. Start a fresh Project and retry the CreateAgent call with the same worker_id.

Does the child start on your machine after step 5?