[Feature]: Spawn sessions programmatically, and let sessions message each other

[darenlam]

Problem

There is currently no supported way to create a T3 Code session from outside the UI, and no way for one session to hand work to another. Both come up constantly once you use T3 as a daily driver alongside long-running agents.

Concrete case from today: I was deep in a T3 session on one workstream and wanted to split an unrelated investigation into its own session so the two contexts stayed clean. There was no way to do it from inside the session. The fallback was to spawn the second agent in a different tool entirely, which then ran fine but was invisible from T3 — the work happened somewhere I could not see or reply to it. Splitting work is exactly the moment you least want to leave the app.

What I checked before filing

• No session/thread subcommand on the CLI. t3 connect, t3 project and t3 service exist; nothing creates or addresses a session.
• URL scheme is registered but minimal. t3code:// (and t3code-dev) are registered in Info.plist, but the only route I could find in the bundle is t3code://app, which just focuses the app. No route carries a prompt, project, or model.
• The local port serves the renderer, not an API. The app listens on 127.0.0.1:3773, but /, /api, /rpc, /openapi.json and /health all return the SPA HTML.
• The thread tables are there (projection_threads, projection_thread_sessions in state.sqlite), but writing into a running app's database to fabricate a session is not something anyone should be doing.

So the capability is genuinely absent rather than just undocumented.

Requested

1. Spawn a session programmatically. Any one of these would be enough:

• A deep link: t3code://new?project=<path>&prompt=<text>&model=<id>&agent=<name>
• A CLI subcommand: t3 session new --project <path> --prompt <text> printing the new session id
• A tool exposed to the agent itself, so a running session can split off a child session

The returned session id is the important part — without it there is no handle to follow up on.

2. Let sessions talk to each other. Given a session id, allow sending a message to it and (ideally) subscribing to its completion. That turns spawning into real delegation rather than fire-and-forget.

Why this is worth more than the sum of the two

Together they make T3 able to orchestrate its own work: a session can fan out an investigation, get told when it finishes, and pull the result back — without the user having to shepherd tabs manually or leave the app. Claude Code has this internally (agent spawn plus inter-agent messaging) and it changes how you use the tool. T3 already has the harder pieces: multiple providers, a session store, a project model, and a CLI to hang it off.

Notes

• Permissions should be inherited from the parent session or be explicit on the call, not silently widened — see [Bug]: One submitted prompt spawned a second, invisible agent session on a different model, which ran gh write commands unsupervised #5447 for why an unsupervised spawned session is a real hazard.
• A spawned session should be visibly attributed to its parent in the UI, so it never becomes the "invisible agent" problem in a new form.
• Read-only addressing alone (list sessions, get status) would already be useful and is a smaller first step if the full thing is too big.