feat: Cloud Agents

[juliusmarminge]

With seamless handoff

[juliusmarminge]

or...

Remote Agents

A remote agent is any agent that doesn't run directly on your machine. Can be either cloud sandbox or another machine on your network.

Add in a nice FS2 integration and boom 🤯

[robin-liquidium]

would that include being able to work on a remote VPS machine? for example what i am missing from opencode's and codex's desktop apps is the ability to work via a ssh connection. like i would like to add my vps via ssh as a project so i can work remotely on my vps and make changes to my vps from my local computer.

[ashvinnihalani]

I took an initial stab: @juliusmarminge on the initial remote VPS. https://github.com/ashvinnihalani/t3code. I based it off the remote server architecture of visual studio code.

Demo: https://imgur.com/a/uIOjj25

I think a first step is just adding the remote field to the various project stores.

[gabrielemidulla]

That would be neat, especially handling agents remote from anywhere and doing follow ups to remote agents.

[deanjstone]

Verified on a real iPhone (2026-07-23), tested via a Tailscale Serve tunnel (https://lnv-lgn5-wsl.tail00500e.ts.net:8443, tailnet-only — same pattern used for Quick Capture/Launch Agent PWAs) since no macOS box was available for icons:export; user was fine testing with placeholder icon bytes.

Passed:

• Add to Home Screen from Safari
• Standalone launch (no Safari chrome/URL bar)
• Backgrounding + reopening (resumes cleanly, no reload)
• Force-quit + relaunch (clean cold start)

Bug found and filed separately (not fixed inline, per this ticket's instruction): #7 — the sidebar toggle button sits under the iOS status bar in standalone mode, since --workspace-controls-top only accounts for Electron's window-controls-overlay, not the PWA standalone safe-area-inset-top.

Incidental fix needed and applied along the way: while getting a testable build in front of the phone, hit and fixed an unrelated pre-existing gap — a bare local vp preview build (no VITE_HOSTED_APP_URL/VITE_HOSTED_APP_CHANNEL set) throws an unhandled root-route-loader rejection (PrimaryEnvironmentRequestError from fetchSessionState() in src/environments/primary/auth.ts) instead of falling back to hosted-static mode, because bootstrapServerAuth() doesn't wrap its initial fetchSessionState() call in try/catch. This only reproduces when a build has no backend and no hosted-app channel configured (not the case for real deployments, which always set VITE_HOSTED_APP_CHANNEL), so no code change was made — just noting it here in case it's worth hardening later.

Sign-in/core-flow testing was skipped since the test build had no Clerk/cloud config wired up — out of scope for this ticket's goal (install + standalone launch verification).

This closes out the PWA wayfinder map (#1) except for the follow-up in #7.

[zhamann]

Moving this here from #10243 as requested.

I’d like to contribute the Cursor Cloud Agents portion of this. The use case is launching work in Cursor-hosted environments through its API, then viewing progress, sending follow-ups, and cancelling runs from T3.

The initial scope would be one GitHub repo/ref, server-side API credentials, streaming responses, reconnect recovery, and links to the resulting branch or PR.

Would you consider a scoped cursor-cloud provider as an initial contribution toward this, or should it wait for a shared remote-agent execution model?

[Superlapie]

+1 specifically for native Cursor Cloud Agents support.

I'm currently using T3 as the control surface for a remote VPS, with both Codex and Cursor running on that VPS. This works really well, but Cursor Cloud Agents are the biggest missing piece for this workflow.

Ideally, I'd like T3 to remain the single control surface while being able to launch Cursor Cloud Agents for independent tasks, see their status/output alongside my normal Codex/Cursor threads, send follow-up prompts, cancel runs, and get the resulting branch or PR back in T3.

The cursor-cloud provider proposed above makes a lot of sense to me as an initial implementation. Since Cursor already exposes a Cloud Agents API, this seems like it could work without needing to automate Cursor's UI.

From a user's perspective, an ideal workflow would look something like:

T3 → Cursor → Local / SSH / Cloud

Then when choosing Cloud, T3 could let me select the repo/ref, model and task, launch the agent, and treat the resulting cloud run similarly to another T3 thread.

I'm actively using T3 with multiple agents and a remote VPS already, so I'd also be happy to test a Cursor Cloud implementation against a real multi-agent workflow if that would be useful.

Edit: I did a little more digging into Cursor’s Cloud Agents API and this actually looks a lot more realistic than I first thought. Cursor already exposes most of the stuff T3 would need: creating agents, follow-up runs, live streaming, cancelling runs, reconnecting to existing agents, listing models/repos, token usage, artifacts, and getting the branch/PR back when the work is done.

So this doesn’t seem like T3 would need to invent some huge new cloud-agent system from scratch. It feels more like adding a cursor-cloud provider and mapping Cursor’s agent/run events into T3’s existing thread/provider model.

The API is still in public beta, so obviously that’s the biggest caveat, but the actual control surface is already pretty complete. After looking through it, this feels way more feasible than I initially assumed.