Support "Y" style remote SSH host workflow

Ideas Feature Requests
,
1

Feature request for product/service

Anysphere Extensions (Remote SSH, Python, Dev Containers, WSL, C/C++/C#)

Describe the request

Cursor’s remote SSH plugin is quite useful, but I have multiple times run into the fact that there are two distinct use cases:

  1. Remote dev box, where the source code lives, from which the deliverables are built and tested and packaged and deployed.
  2. Remote prod box, where the deliverables are deployed and (alas) sometimes debugged in production.

Cursor handles both cases standalone today, but as far as I can tell, not together when the dev box isn’t allowed to talk to the prod box directly, only the local box is. This is an intentional “Y” arrangement, done to isolate concerns, avoid transitive security violations, etc.

What I think I want — and I ask in full awareness that I am soliciting expertise from those who will feel free to tell me what I actually want :nerd_face: — is a feature in Cursor that lets me open multiple remotes at once, which a single local instance can see, allowing it to coordinate between them.

The need for this is most readily seen in Debug mode for problems where the symptom isn’t well enough characterized yet to reproduce it in the dev environment. While remote SSH’d into the dev box, Debug wants to try commands there to test hypotheses, but between the sandboxing and the mismatch between dev and prod, it can’t.

My concept is that it should be possible to open multiple remotes from the local box over SSH, one to dev and one to prod, then have Cursor understand that when I build and push a binary on the dev box, it can continue testing hypotheses agentically through the other SSH connection. If I am feeling especially brave, I can elect to give Cursor permission to round-trip through the chain:

  • change the code
  • build a binary
  • push to deployment
  • pull the binary
  • restart it in prod
  • test the result in situ

…and then back to dev to continue hypothesis testing, or clean up the instrumentation.

To ground the discussion, I’m doing that deployment step via an OCI image registry that dev can write to and prod can read from, using different credentials. This is one example backing my desire that Cursor coordinate its work over two simultaneous SSH connections. The cheap-and-easy path of giving prod the creds of dev or vice versa is beyond unpalatable, as is shipping the code to the prod box to allow Cursor to work on it in place.

5

Hey, thanks for the detailed and well thought-out feature request. Your Y topology with dev and prod isolation via a local box is explained really clearly.

Quick update on the current state. Right now, one Cursor window is tied to one remote authority, and multi-root over SSH only works within a single host. So today you can’t put dev and prod into one workspace and have one agent coordinate across both. This is a limitation inherited from upstream VS Code, not something we can enable with a setting. I can’t share an ETA for this.

A partial workaround that might fit your setup. Open a local workspace on the box that can reach both dev and prod, then let the agent shell out via ssh dev ... and ssh prod .... Since the local machine can reach both, the agent can build and push to dev, then run checks on prod in the same session. This avoids any direct dev to prod path and avoids sharing creds between hosts. Your OCI registry flow where dev writes and prod reads fits this well. A simpler alternative is two windows side by side, but then one agent won’t have a single shared two-remote context.

I’ll leave the thread open for votes. More signal increases the chance it gets planned. Let me know if the workaround doesn’t cover your case.