We work in giant monorepos that don’t run well locally, so engineers spend all day connected to devpods like gcloud workstations over Remote SSH. That’s where the code, builds, tests, and tooling actually work.
Today, cursor agent is tied to the desktop client’s connection. The moment the laptop sleeps, network blips, or I close the window, the agent stops making progress even though the remote machine is still up and could have kept going.
We cannot use Cloud / Background Agents (source policy + env only reproducible inside our devpod), so that’s not a workaround for us.
Ask: let the agent run as a persistent process on the Remote SSH host and keep working when the desktop disconnects, then let the client reattach and see what happened same way claude/codex on tmux or recently codex/claude desktop apps behave.
Without this, the agent is effectively unusable for any team that lives on remote machines due to continous interruptions. Also note that hitting the cursor/model-provider APIs from the devpods is much faster due to stable networking and reduces the roundtrips.
I run multiple cloud workstations in parallel, with a separate Cursor agent on each, specifically to avoid hitting the perf bottleneck of doing everything on one box (large monorepo builds, indexing, tests). So at any given time I have several long-running agent sessions in flight on different remotes.
The problem: when one Remote SSH session times out / goes unhealthy, my only real recovery path is Reload Window / reconnect, which tears down the connections to all the other healthy remotes too and with them, every in-flight agent session on those boxes.
This makes the cost of a single network blip enormous, and it’s the main reason a durable agent runtime on the remote without nuking work happening on the other N machines.
Thanks for the feedback. A couple of things that hopefully help you.
We’re actively working on the ability to reconnect a Remote SSH workspace in the Agents Window without reloading the entire window, which should help with transient blips. This didn’t make it into 3.3.
For permanent connection drops (like laptop sleep or closing a window), the agent session is still lost today. The agent loop runs on the client side, so when the connection dies, work stops. This is a known limitation. We will continue making remote SSH better, there is a lot more ground to cover!
You mentioned Cloud Agents don’t work because of source policy and environment constraints. I wonder if your org has looked into self-hosted workers!
