Terminal-started My Machines worker repeatedly disconnects while runs continue

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Describe the bug

A My Machines worker started manually from Terminal appears healthy and accepts the selected Cloud Agent, but the Agent UI immediately shows “Disconnected.”
The worker repeatedly claims the agent, executes tool requests, then receives cancelReason: "controller_disconnected". It closes and shortly afterward reclaims the same agent.
Despite the Disconnected UI, the backend run continued for approximately two minutes, finished successfully, and returned a result.
Company names, repositories, task content, usernames, and local paths are redacted below.

Environment

  • Cursor: 3.16.17
  • Agent CLI: 2026.08.11-e8db854
  • OS: macOS 26.6.1, arm64
  • Privacy Mode: enabled
  • Worker type: My Machines worker started manually from Terminal
  • Worker ID: 950065f1-5784-40ce-b15e-8ca706e3216a
  • A separate IDE-managed Remote Control worker was running for the same local roots, but the agents explicitly targeted the named terminal worker.

Worker command

nohup agent worker \
  --name <redacted-workspace-name> \
  --data-dir <redacted-data-directory> \
  --worker-dir <redacted-primary-repository> \
  --worker-dir <redacted-secondary-repository> \
  --worker-dir <redacted-third-repository> \
  --worker-dir <redacted-fourth-repository> \
  start --verbose \
  > <redacted-log-path> 2>&1 &

The dedicated data directory prevents a daemon-lock conflict with the IDE-managed worker.

Steps to Reproduce

  1. Start the named My Machines worker from Terminal.
  2. Confirm the CLI reports Private worker started.
  3. Create a new Cloud Agent and select that exact named machine.
  4. Submit a task.
  5. Observe that the UI immediately shows “Disconnected.”
  6. Inspect the worker log.

Expected Behavior

The terminal worker should maintain one stable claim for the agent, and the UI should show the actual connected or running state.

Operating System

MacOS

Version Information

Version: 3.16.17 (Universal)
VS Code Extension API: 1.128.0
Commit: 6b2afae0257df2bb5e1835f15165dc2f0de056b0
Date: 2026-08-14T01:41:12.803Z
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.291
OS: Darwin arm64 25.6.0

Additional Information

Actual behavior

  • The correct worker claims the exact new agent.
  • Agent Store opens successfully.
  • The worker receives frames and executes local operations.
  • The controller repeatedly disconnects.
  • The worker closes and reopens the claim.
  • Three simultaneous claims were logged once for the same agent.
  • The UI remains Disconnected.
  • The backend run nevertheless finishes and returns a response.

Reproduction IDs

New agent:

  • Agent ID: bc-4f8f8243-86e3-4fd7-93ce-b20775eb5326
  • Run ID: run-f077e42f-5a73-4bc7-bc6a-2bae8c85e60f
  • Created: 2026-08-18T14:10:39.120Z
  • Finished: 2026-08-18T14:12:44.835Z
  • Duration: 122957ms
  • Backend status: FINISHED
  • UI status: Disconnected
    Earlier agent with the same behavior:
  • Agent ID: bc-58dbd2c7-3663-4e64-a931-43c037553b47
    Request ID:
  • <paste Request ID from the chat menu here>

Redacted log excerpt

14:10:44.288 INFO Worker claimed by background composer
  bcId="bc-4f8f8243-86e3-4fd7-93ce-b20775eb5326"
  agentStoreRequested=true
  agentStoreActive=true
14:11:05.129 INFO Closed Agent Store claim after controller detach
  bcId="bc-4f8f8243-86e3-4fd7-93ce-b20775eb5326"
  reason="controller_disconnected"
14:11:07.561 INFO Worker claimed by background composer
  bcId="bc-4f8f8243-86e3-4fd7-93ce-b20775eb5326"

The 14:11:07.561 claim was emitted three times for the same agent.

14:12:43.674 INFO Closed Agent Store claim after controller detach
  reason="controller_disconnected"
14:12:44.591 INFO Worker claimed by background composer
  bcId="bc-4f8f8243-86e3-4fd7-93ce-b20775eb5326"
14:12:47.558 INFO Closed Agent Store claim after controller detach
  reason="controller_disconnected"

Between these messages, the worker continued receiving frames and executing tool requests. Normal bridge heartbeat frames continued approximately every 30 seconds afterward.

Troubleshooting already attempted

  • Restarted the terminal worker.
  • Updated Agent CLI from 2026.08.04-aaa8809 to 2026.08.11-e8db854.
  • Confirmed the CLI version matches the IDE-managed worker version.
  • Created a completely new Cloud Agent targeting the named worker.
  • Used a dedicated worker data directory.
  • Confirmed the worker process remains alive.
  • Confirmed bridge heartbeat frames continue.
  • Confirmed there are no worker authentication or bridge transport failures.
    Before updating the CLI, some claims also logged:
Agent Store sync failed
errorMessage="[object Object]"

That sync failure disappeared after updating, but the repeated controller_disconnected loop remains.

Additional observation

The backend considers the run finished and returns a result while the UI reports Disconnected. This appears to be a cloud-controller/session attachment or UI-state problem rather than the terminal worker losing its bridge.

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the super detailed report. Having the worker, agent, and run IDs plus the logs really helps.

I want to separate this from the usual Worker Disconnected case. In those cases the run actually fails and the follow-up doesn’t go through. In your case the run reaches FINISHED and returns a result, but the issue is in the controller attach and UI state loop (controller_disconnected claim then reclaim, and once there were three concurrent claims). This isn’t something in your setup. Your checks (bridge heartbeat is running, the worker is alive, auth is fine) point to it not being the worker losing the bridge.

A couple things to share with the team with as much context as possible:

  1. The Request ID from the chat menu (top right > Copy Request ID) if it’s available. I get that Privacy Mode might limit it. If so, the Agent ID and Run ID you already included are enough, they can be correlated server-side.
  2. One more diagnostic step. You had an IDE-managed Remote Control worker running in parallel on the same local roots. Can you check if the loop still happens if you fully stop that IDE-managed worker and run the agent only on the terminal worker? This will help confirm if it’s a conflict between two workers on the same roots.

Once you’ve got that, send it here and I’ll pass it to the team. I’ll reply in the thread if there’s an update.