Cursor AI agent development, on the real dev box.
Cursor is great at editing code — but only as good as the code and runtime it's pointed at. Point it at a stale local clone and its AI reasons about the wrong tree against the wrong environment. a2a gives you a better target: run a2a ssh <agent>, then connect Cursor over Remote-SSH to the agent's cloud dev box. Cursor's AI edits the real repo, against the real toolchain your agent deploys on.
a2a ssh · <agent>.a2a · Cursor Remote-SSH · prod parity
Cursor is only as good as what it's pointed at.
The usual loop is Cursor on your laptop, editing a clone of the agent repo you cloned some time ago. Its AI reads that tree — but the tree has drifted from production, your local Node and Python versions don't match the deploy image, and half the system dependencies aren't there. So the AI writes plausible changes you can't actually run without mocking the environment, and the gap between 'what Cursor edited' and 'what production runs' is exactly where the bugs hide.
Point Cursor at the agent's cloud dev box.
a2a ssh <agent> opens a scale-to-zero dev box and writes the ~/.ssh/config entry Cursor's Remote-SSH needs. Connect to <agent>.a2a and Cursor — editor and AI — runs against the real repo at ~/<agent>, on Node 20, Python 3.11, and a2a-pack, over your existing ingress with no open port.
Cursor over Remote-SSH
a2a ssh <agent> opens a cloud dev box and writes an ~/.ssh/config entry for <agent>.a2a. Cursor is a VS Code fork, so Remote-SSH -> Connect to Host -> <agent>.a2a just works. The whole Cursor editor — and its AI — now runs against the box, not your laptop.
AI editing the real repo
The agent's git repo is already cloned at ~/<agent> on the box. Cursor's chat, edits, and tab-completion see that real tree — the actual tools, prompts, and handlers you ship — not a stale clone you pulled last week and forgot to sync.
The real runtime under it
The box runs Node 20, Python 3.11, and a2a-pack already logged in, on the same base image family your agent deploys on. When Cursor writes a change, you run it against the real toolchain — no 'works on my machine' gap between what the AI edits and what production runs.
No open port, no bastion
The dev box tunnels SSH over a WebSocket through the same HTTPS ingress your agents already use. Nothing exposes a raw SSH port. Cursor's Remote-SSH rides that tunnel via the ProxyCommand the CLI installs — you connect the way you'd connect to any host, and the security is handled underneath.
Ephemeral keys, scoped grant
Each session authenticates with a throwaway Ed25519 keypair plus a short-lived transport grant scoped to that one box. Cursor never holds a standing production credential — it holds a key that only opens this dev box, and only while you're working.
Scale-to-zero, not always-on
The box wakes on connect and drains to zero after ~5 minutes idle (8h hard cap). Close Cursor and the environment goes away — no idle VM to patch, no long-lived box accumulating state for the next session to inherit.
Cursor on a stale local clone vs. Cursor on the live dev box.
Frequently asked.
How do I develop an agent in Cursor on an a2a cloud dev box?
Run a2a ssh <agent> once — it opens a scale-to-zero cloud dev box and writes an ~/.ssh/config entry so the box is reachable as <agent>.a2a. Then in Cursor open Remote-SSH, Connect to Host, and pick <agent>.a2a. Cursor is a VS Code fork, so that config entry works directly. The editor and Cursor's AI now run against the box, with the agent's repo already cloned at ~/<agent> and Node 20, Python 3.11, and a2a-pack ready.
Does Cursor's AI work over Remote-SSH to the dev box?
Yes. Cursor's Remote-SSH connection runs the editor against the remote box, and its AI features — chat, inline edits, tab completion — operate on the files it sees there, which is the real agent repo at ~/<agent>. You get Cursor's AI editing the actual code you ship, against the actual runtime it runs on, instead of a local clone that has drifted from production.
Is this the same as building an agent with Cursor and the SDK?
No — those are two different things. Scaffolding a new agent locally with Cursor plus the a2a SDK is covered on build-agents-with-cursor. This page is about remote development: connecting Cursor over Remote-SSH to an existing agent's cloud dev box so you edit the real repo against the real runtime. Many people scaffold locally first, then move to the dev box to iterate against production parity.
How does Cursor connect without an open SSH port?
The cluster exposes no raw SSH port. The dev box runs sshd on localhost and tunnels SSH over a WebSocket through the same HTTPS ingress your agents already use; the a2a CLI installs the ProxyCommand that speaks it. Cursor's Remote-SSH rides that tunnel transparently — from Cursor's side it's a normal host connection, with no bastion, firewall rule, or extra attack surface to manage.
What happens to the box while Cursor is connected, and after I leave?
The box wakes on connect and stays up while you're working. It scales to zero after about five minutes of idle time, with an eight-hour hard cap per session. When you close Cursor, the environment drains away — there's no always-on VM to patch or pay for, and no long-lived box accumulating state. Pair it with a2a dev for a hot-reload server and a public preview URL while you iterate.
Related guides.
All guides live in the guides index.
Give Cursor the real agent, not a stale copy.
a2a ssh <agent> opens a cloud dev box — the agent's repo pre-cloned, Node 20, Python 3.11, a2a-pack logged in, on the same base image it deploys on — and writes the ~/.ssh/config entry Cursor's Remote-SSH connects through. SSH tunnels over your existing HTTPS ingress with ephemeral Ed25519 keys and a scoped transport grant; the box scales to zero when you leave. See the dev boxes, or run a2a dev for a hot-reload server and a public preview URL while you build.