Repository navigation
Manage Cursor, Codex, and Claude cloud sessions from inside T3 #15644
Description
Related to #15516 (isolated workers), but this is the hosted coding-agent side, not a generic sandbox.
I want T3 to start, list, steer, and stop cloud sessions for Cursor, Codex, and Claude without leaving T3. The parent thread stays the control plane. Each cloud session shows up as work I can follow, the same way a local provider thread does.
What I want:
- Start a Cursor cloud, Codex cloud, or Claude cloud session from a T3 thread.
- See status, the branch or pull request, and a way to steer or stop it.
- Keep the three providers separate. Do not pretend they are one runtime.
This is not a request for T3 to own Daytona, Docker, or E2B. That split is already in #15516. Here the compute is the vendor's own cloud agent.
Reacted by Rob Sale, Gabby Welson, Jack Hullis, Ved, Taras Kornichuk, gertzgal, Uiopak, kyle3728, William Newbery, yu and 30 more
Reacted by mikelawz and Daniel Hagen
Reacted by mikelawz and Daniel Hagen
Reacted by mikelawz and Daniel Hagen
Activity
ggwelson commentedon Oct 5, 2026
+1, this would be a huge unlock — especially on Cursor
artile commentedon Oct 8, 2026
+1. My use case: I move my long work (eval suites, multi-hour builds) from local machines to Claude cloud sessions, and I want T3 to stay the one place where I see and steer all of it.
The Claude CLI already gives most of the surface a first version needs:
claude --cloud "<task>"makes a cloud session for the current repo and prints itsclaude.ai/code/<id>URL.claude -p "<message>" --cloud <session-id>queues a message into a running session (--output-format jsongives{ok, session_id, url}).claude --teleport <session-id>checks out the session's branch and loads its history locally. That could map to "continue this cloud session as a local T3 thread".Docs: https://code.claude.com/docs/en/claude-code-on-the-web
A small first step: an "open in cloud" action on a Claude thread that runs
--cloud, then shows the session link and status in the thread. Cloud sessions use the same plan limits as local Claude Code and have no VM charge, so the cost is the same for users.yu2001-s commentedon Oct 9, 2026
+1
jieyuexing commentedon Oct 10, 2026
Note
Drafted by Claude Opus 5.5 in Claude Code (via T3 Code); reviewed and posted by @jieyuexing.
+1, and I'd like to add two hosted assistants to the same picture: Codex dots (OpenAI) and Grok Bot (xAI, which runs on Cursor's agent platform). They aren't per-task coding sandboxes like Cursor/Codex/Claude cloud sessions. They are persistent assistants with their own cloud computer, memory and schedules, so they overlap with what T3 scheduled tasks do today.
There are two directions, and they need different things from T3:
Assistant → T3.
docs/user/outside-agents.mdalready lets a hosted agent sign in to/mcpover T3 Connect. For Grok Bot,tools/callfails today ([Bug]: MCP returns an empty 400 for in-session requests without MCP-Protocol-Version, so Grok Bot (Cursor client) can't call tools #16906; fix(server): MCP tool calls work when a client omits MCP-Protocol-Version #17277 was closed in favor of the Effect 4.0.2 upgrade in 91a6646, which isn't in a nightly yet). I haven't seen anyone confirm a dot calling T3 tools end to end.T3 → assistant (what this issue is about). I'd like a scheduled task or a delegated task to hand a run to Grok Bot or my dot, keep its link and status in the parent thread, and get the result back, the same way this issue describes for Cursor/Codex/Claude cloud sessions. Neither product documents an external API for this today. Grok Bot is reached through its app, mobile, or a mention on X, and its routines are scheduled in the app. Dots are reached through ChatGPT, Slack or Teams, and their schedules live in the dot's own Scheduled list.
So on the T3 side, a first step could only be:
A real "send to Grok Bot / dot" action would have to wait for those vendors to expose an API.
One question: is Home (#15975) meant to be T3's own answer to dots? If so, it would help to say how Home and an outside dot or Grok Bot should share the work (for example, which one owns schedules), so users don't end up running two schedulers over the same threads.
paintme6lack commentedon Oct 14, 2026
+1
heyiamnotacoder commentedon Oct 16, 2026
+1
ryannzander commentedon Oct 18, 2026
This is the single reason I haven't completely switched to t3 +1
Rototu commentedon Oct 22, 2026
+1 For now this is my only pain point with t3, everything else is already quite great. Have managed some basic workaround leveraging cloud subagents with monitoring scripts, but it's quite unreliable atm, official support would greatly improve the situation.
SasaSlivova-IS commentedon Oct 26, 2026
+1
tibodepauw commentedon Oct 31, 2026
Note
Drafted and posted by GPT-6.1 Sol in Codex (via T3 Code) on behalf of @tibodepauw.
+1. I'd really like to use the Codex Cloud environments included with my ChatGPT plan directly from T3 Code, without maintaining a separate development server.
A first version that lets me select a Codex Cloud environment, start a task, follow its status and send follow-up instructions from T3 would already be useful. Is this integration being considered, and is there a known blocker on the T3 or OpenAI side?
Phicks-debug commentedon Nov 1, 2026
+1, for Codex Cloud and Claude cloud sessions specifically. I want to reach them from inside T3 instead of switching to each vendor's own app.
What would cover it for me:
/cloudcommand in the composer, or a cloud environment I can pick next to my local and remote servers, that starts the thread's task in Codex Cloud or Claude's cloud depending on the thread's provider.Keep the two providers separate under the hood, as the issue says. I just want one entry point for both in T3.
Environment: T3 Code 0.1.6, local server via
npx t3, macOS arm64.EtanHey commentedon Nov 5, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Etan
+1, specifically for Claude cloud sessions, with a use case from running a multi-agent setup out of T3.
We run long lead threads in T3 across two Macs. One of them is a laptop that closes, and when it does, any run on it stops. Claude cloud sessions would be the natural home for that work, but today we can't drive them from T3. T3's Claude driver goes through the Agent SDK, and
claude --cloudrefuses piped/SDK invocation ("--cloudrequires an interactive terminal"). So we launch cloud sessions from a real TTY outside T3, they never appear as T3 threads, and nothing wakes the parent thread when one finishes. We end up watching them by hand.What would cover it for us:
#30009 (launch plus follow-ups through a terminal) already covers the first step for us; the completion wake and thread view are the parts we'd most want after that.
🤖 Generated with Claude Opus 5.5 in T3 Code Nightly
ryannzander commentedon Nov 5, 2026
There's no way dudes are using their claude tokens to generate github issue comments
SasaSlivova-IS commentedon Nov 6, 2026
@ryannzander so what... I think that's the norm nowadays...
965311532 commentedon Nov 7, 2026
+1
juliusmarminge commentedon Nov 12, 2026
Thanks for writing this up. It asks for new behaviour rather than reporting a defect, so it does not belong in the bug tracker and I'm closing it as not planned here. Feature ideas are discussed in Discussions: please post it there.