Self-hosted worker connects successfully and shows in the Cloud Agents dashboard, but tasks sent from the web UI at agents console never reach the worker. The worker receives heartbeat frames every 30s but no
task dispatch frames.
However, dispatching via the API works perfectly:
curl -X POST “https://api.cursor.com/v0/agents” \
-H “Content-Type: application/json” \
-u “$CURSOR_API_KEY:” \
-d ‘{
“prompt”: {“text”: “list the files in the root directory”},
“usePrivateWorker”: true,
“source”: {“repository”: “”}
}’
The worker immediately picks up the task: Worker claimed by background composer and begins executing.
Steps to Reproduce
Be on a team with Privacy Mode enabled
Install the agent CLI:
From inside a git repo with a valid remote, start a worker:
agent worker start --api-key “$CURSOR_API_KEY”
Confirm worker connects — logs should show Starting to iterate over stream frames and heartbeat frames arriving every 30s
Go to agents UI → select “Self-hosted” → select the matching repo → send a task
Expected: Worker logs show Worker claimed by background composer and task executes
Actual: Worker only receives heartbeat frames. Task never arrives.
Now dispatch the same task via API:
curl -X POST “https://api.cursor.com/v0/agents” \
-H “Content-Type: application/json” \
-u “$CURSOR_API_KEY:” \
-d ‘{
“prompt”: {“text”: “list the files in the root directory”},
“usePrivateWorker”: true,
“source”: {“repository”: “”}
}’
Worker immediately receives the task and begins executing.
Expected Behavior
Web UI should dispatch the task and start the remote worker successfully.
Operating System
Linux
Version Information
CLI version: 2026.03.30-a5d3e17
macOS (also reproduced on Amazon Linux 2023 EC2 instance)
I’m going to add here that following-up on the same task from the web UI works successfully. Issue seems to be with initial task dispatch on a new task.
After further testing, the POST /v0/agents with usePrivateWorker: true workaround I described above only worked once (at ~14:29 UTC today). Every subsequent attempt has failed with identical symptoms — task sits in CREATING then goes to ERROR, worker never receives
anything beyond heartbeat frames.
To isolate variables, I tested:
3 separate EC2 instances (fresh Amazon Linux 2023, no proxy/VPN, clean installs each time)
2 different personal API keys
With and without source.ref, simple and complex prompts
Matching and mismatching API keys between worker auth and dispatch auth
With and without --idle-release-timeout
Cleared state (agent logout, deleted agent-cli-state.json) and completely pristine installs that never went through a logout cycle
In all cases:
Worker connects successfully, registers in the backend (GET /v0/private-workers shows it as idle)
POST /v0/agents returns CREATING successfully
Worker receives only heartbeat frames (every 30s), never a task dispatch frame
Task eventually transitions to ERROR or EXPIRED
The one successful dispatch at ~14:29 UTC was the very first POST /v0/agents call with usePrivateWorker: true on this account. Every attempt after that — even with identical parameters — has failed.
Thanks for the thorough report, especially the API vs web UI comparison and the exhaustive testing across multiple EC2 instances.
This is a confirmed bug on our side. Other users have also reported the same behavior in this thread and this earlier thread. Our team is aware and actively investigating a fix.
The issue is that the backend retains a reference to a previous worker identity, and when it tries to dispatch a task, it looks for that old identity instead of the currently-connected worker. This affects both web UI and API dispatch once the stale reference gets stored.
To try to recover:
Kill any running worker processes
Full logout: agent logout
Clear local worker state: echo '{"version":1,"workerIdsByDisplayName":{}}' > ~/.cursor/agent-cli-state.json
Fresh login: agent login
Start the worker: agent worker start --api-key "$CURSOR_API_KEY"
Create a brand new session in cursor.com/agents (not from a snapshot or previous session)
The key step is agent logout before agent login. A re-login alone doesn’t reset the backend’s reference to old worker IDs. This recovery was confirmed by another user in this thread.
Privacy mode is not the cause here. The dispatch path is the same regardless of privacy mode settings.
Let me know if the recovery steps help, or if you have any other questions.