On a long-lived My Machines worker started from the terminal (systemd service, not IDE Remote Control), Cloud Agent runs often enter a claim/detach loop:
Worker claims the agent (Worker claimed by background composer, Agent Store opens).
Shortly after, the claim closes with cancelReason / reason controller_disconnected (Closed Agent Store claim after controller detach).
The same bcId is claimed again (sometimes multiple overlapping claims within seconds).
Bridge heartbeats continue; the worker process stays up (no crash, no OOM, no sleep, no --idle-release-timeout exit). Auth token refresh reconnects in under a second when it happens.
Each detach appears to reset Agent Store / session attachment mid-exploration. The model then re-orients (re-lists tree, re-reads rules, rediscovers tools, resumes checklists) instead of continuing the task. For a trivial one-file null-guard this has stretched a run to many hours with little useful progress until an external interrupt forced commit/PR.
Worker: My Machines, terminal/agent worker start under systemd (single named worker; not intentionally running a parallel IDE-managed worker on the same roots)
Privacy Mode: enabled
Agent CLI: current stable at time of observation (can provide exact version on request)
Repos: multiple --worker-dir checkouts on the same machine
Steps to Reproduce
Start a named My Machines worker from the terminal and keep it running.
Launch a Cloud Agent targeted at that worker on a real multi-file repo (git discovery / explore phase matters).
Give a small coding task (e.g. null-safe access in one helper).
Watch worker logs during early exploration (branch/worktree discovery, reads).
Expected Behavior
One stable claim for the agent until the run finishes or the user cancels. Controller detach should not flap. The model should keep task state across tool calls without re-booting orientation every few minutes.
Actual Behavior
Repeated controller_disconnected → close claim → reclaim same bcId
Occasional burst of multiple claims for one agent in ~20s
Agent Store reset mid-run → model thrash / “lost thread”
Worker process and bridge remain healthy
Trivial fixes become non-viable on self-hosted vs the same change in a local Cursor Agent session on a developer machine
Log pattern (redacted)
INFO Worker claimed by background composer
bcId="bc-…"
agentStoreRequested=true
agentStoreActive=true
INFO Closed Agent Store claim after controller detach
bcId="bc-…"
reason="controller_disconnected"
INFO Worker claimed by background composer
bcId="bc-…" # same id; sometimes logged multiple times in a short window
Bridge heartbeat frames continue (~30s) across the flap. No transport/auth failure in the worker log around those events (aside from routine token refresh).
Notes for eng
Please treat this as the controller/session-attachment class (as in the Aug 2026 thread), not classic “Worker Disconnected / machine asleep.”
Flapping is most damaging during explore/git discovery, when Agent Store reset forces full re-orientation.
Happy to share redacted bcId / runId pairs and a longer log slice privately if useful.
This issue stops me from using Cursor self-hosted Cloud Agents on non-trivial or even trivial autofix workloads. Local Agent in the IDE remains usable; self-hosted is not reliable enough for unattended runs.
Update: Since filing, upgraded the worker CLI to 2026.09.18-9a7762b; will report back if the claim/detach loop still occurs.
Quick separation of the two things happening here:
The claim → “Closed Agent Store claim after controller detach” → reclaim cycle is expected. Each step opens its own short-lived connection to the worker and the claim is reopened between steps by design, so that’s not a flap and not where task state is lost. Your worker/bridge staying healthy is exactly right, so this part isn’t on your end and isn’t the cause of the re-orientation.
The “lost thread” re-orientation is the real thing to chase. It shows up when the context window is nearly full early in a run, so the agent has to summarize after almost every step. That usually comes from a large always-on payload across the worker’s repos: always-applied rules, skills, AGENTS.md, and MCP tool definitions. Trimming those (scope rules/skills per-repo or make them agent-requested, and drop MCP servers you don’t need for the run), or using a larger-context model if you have one available, is the reliable lever. This is an issue we’re tracking.
One quick diagnostic: if the Shell tool on that worker is also coming back with “no exit status”, it makes this much worse. On your updated CLI (2026.09.18), try a run with the prompt “run echo hello and show the output” — if it doesn’t print hello, send your agent --version, the worker log lines from that minute, and a bcId, and I’ll dig in.
Thanks @mohitjain — follow-up with the Shell check and a controlled A/B after recycling the worker.
Bottom line: after restarting the worker onto CLI 2026.09.18 and uninstalling GitHub MCP (using gh instead), My Machines Cloud Agents are working well again for us — a trivial autofix completed cleanly in ~25 minutes with a small transcript. If anything regresses I will report back here; happy to send more log slices or bcId details if useful.
Shell check (your repro)
Before recycling the long-lived worker process:
Host CLI was already 2026.09.18-9a7762b, but the running cursor-worker process was still on 2026.09.02-… (started days earlier).
Cloud Agent Shell: echo hello → no stdout, no exit status (same for agent --version via Shell).
bcId: bc-6b45f16e-f05a-58ce-83b0-1ec85fdbf7b8
Aftersystemctl --user restart cursor-worker.service (worker now on 2026.09.18):
Shell: stdout hello, exit 0; CLI via Shell reports 2026.09.18-9a7762b.
bcId: bc-da752969-8fa1-538b-b720-248d21562d37
So on My Machines, upgrading the CLI binary alone is not enough until the worker unit is restarted; otherwise agents keep the old runtime (and we hit the broken Shell plumbing).
A/B: thrash vs healthy run (same class of trivial null-guard autofix)
Prior thrash run (old worker + GitHub MCP enabled / flaky)
Post-restart run (2026.09.18 + GitHub MCP uninstalled)
Time to PR
~all day / never clean
~25 min
Transcript
~12.5 MB / ~3800 lines
~1.1 MB / ~200 lines
get_mcp_tools
157
3
mcp calls
640 (mostly GitHub get_file_contents ×~320)
1 (non-GitHub)
Shell
357
~9
bcId
bc-2d06752e-bce5-5ada-9732-5ee83930012d
bc-06bf0363-5a89-51d3-85ce-89614f368d49
Launch prompt size was small (~5.6 KB) on the thrash run — not the main context pollutant. The transcript is dominated by MCP rediscovery + GitHub file reads, not claim/detach alone.
GitHub MCP auth (separate, but related)
In Cursor desktop, GitHub MCP stayed on HTTP 401AuthenticateToken authentication failed even after re-auth. While the plugin was still installed, a short Cloud Agent smoke on the same worker could still use GitHub MCP successfully once (bcId bc-c11bfaf0-5c31-584f-99af-677097b2a4ae). After uninstalling it, a second smoke’s catalog had no GitHub server; gh still worked (bcId bc-8a7ca205-edad-5b5c-8763-7edc4ea17942).
We are leaving GitHub MCP uninstalled on this account and relying on gh for Cloud Agents. The thrash pattern matches “GitHub MCP in bad/looping shape + old worker/broken Shell”, not model loss from claim→detach by itself.
Again: things look healthy on our side now. I will ping this thread if we see a recurrence, and I can share more details on request.