Where does the bug appear (feature/product)?
Cloud Agent (GitHub, Slack, Web, Linear)
Describe the Bug
Opening a Cloud Agent chat in Cursor Desktop fails with a 30-second workspace-resolution timeout. The conversation is not lost: the same agent opens on the web and the transcript is there. Desktop logs WorkspaceResolutionTimeoutError from workbench.glass.main.js and does not include the agent id. The web UI shows Waiting for the environment and Completing setup, while desktop treats that wait as a hard failure.
Two cases from this machine:
Case A. Agent bc-da75d5d2-2074-4882-aaeb-e6c0b3980abb. The VM was already up (hasStartedVm true, status 2, workflow 2). After TLS recovered, the desktop reconnected in about 3 seconds.
Web page: https://cursor.com/agents/bc-da75d5d2-2074-4882-aaeb-e6c0b3980abb
Case B. Agent bc-db7379a9-5596-4658-9042-e8fa54f6884d. hasStartedVm false, status 4, workflow 6. The environment is the account-wide Cloud environment account-all-repos (public id 1beb2e04-ad9f-11f1-bf4b-42ffb4d10ea7). Desktop timed out four times at 30 seconds. The web page loaded the transcript and stayed on Waiting for the environment, with one queued follow-up.
Web page: https://cursor.com/agents/bc-db7379a9-5596-4658-9042-e8fa54f6884d
Steps to Reproduce
- On Cursor Desktop 3.24.12, open a Cloud Agent from the agents list, or open the background-agent deeplink or the background-composer remote URI for one of the ids above.
- Case A: the VM had already started. After the earlier TLS errors cleared, resolve succeeded in about 3 seconds.
- Case B: the VM had not started. Desktop hits the 30-second workspace timeout repeatedly. Today the renderer log shows timeouts around 16:27 and 16:33 local time, plus two earlier attempts. The web page for the second id stays on Waiting for the environment.
- The warmup cache key cloudAgentRepository.cursorServerUrlWarmup.failuresByAgent held 60 cached pod warmup failures. The timeout log lines do not print the agent id.
Expected Behavior
If the conversation exists, the desktop should open it and show the same provisioning state as the web (Waiting for the environment), and keep retrying while DNS or TLS recovers. It should not give up at 30 seconds when the web transcript is already readable. The error should include the agent id and the wait reason, and a stale warmup-failure cache should not keep blocking the open.
Operating System
MacOS
Version Information
Cursor IDE 3.24.12 (stable). macOS 27.0.0 (build 26A5353q). MacBook Air M3, 8 GB RAM.
For AI issues: which model did you use?
Not model-specific. The affected agents were Grok 4.7. The failure is workspace resolution, before a model reply.
For AI issues: add Request ID with privacy disabled
bc-da75d5d2-2074-4882-aaeb-e6c0b3980abb
bc-db7379a9-5596-4658-9042-e8fa54f6884d
Warmup cache recorded 60 pod warmup failures for these agents. No separate request id was logged with the timeout.
Additional Information
Suggested tag, which this new account cannot apply: cloud-agents.
Local network context, not a request to change proxy routing.
Clash Verge (mihomo 1.19.29), TUN on, mixed port, mode global, fake-ip in the 198.18.0.0/16 range, selected node Singapore 11 into GLOBAL. DNS was DoH pinned to the GLOBAL proxy group, so name lookup died with the node (ENOTFOUND and ECONNRESET toward the Cursor API host and the pod hostnames). A command-line request to the API host could return HTTP 200 while the Electron client still reset. A later DNS change stopped pinning lookup to the proxy group and excluded Cursor domains from fake-ip. Live connections still egress through Singapore 11 into GLOBAL, so proxy routing was kept. The desktop timeout still happens for an environment that has not finished starting, because the client does not wait out provisioning or surface the waiting state shown on the web.
Does this stop you from using Cursor
No - Cursor works, but with this issue