t3-fleet-gateway

Let your bots start, follow and pick up coding work on your T3 Code machines.

The gateway is a small server you run next to T3 Code. It gives an outside bot, such as Grok Bot or a Notion agent, one sign-in and one MCP address for all your machines. (MCP is the protocol agents use to call tools.) Through it, a bot can:

• start work in your projects, or pick up a thread you started yourself in T3;
• read the worker's replies and answer its questions;
• get a webhook when a job finishes a turn, asks something or fails.

Every piece of work becomes a job with a stable ID and a history that survive lost connections and restarts. Each job is still an ordinary T3 thread you can open, read and type into.

It is for people who already run T3 Code on one or more always-on machines and want a bot to drive it, without handing that bot T3's own credentials.

T3 Code alone or with the gateway?

T3 Code already covers a lot of this on its own. As of T3 v0.1.6:

• Remote access is built in. T3 Connect, LAN pairing, Tailscale HTTPS and SSH let you reach your machines from other devices. Remote access
• Outside agents get their own MCP endpoint. Each machine serves HTTP MCP with OAuth sign-in. Claude Code, Codex, ChatGPT and other OAuth clients can launch, message, read, wait on and stop threads, and answer worker questions. Launches and sends take a retry key (clientRequestId). Outside agents
• Machines can work together. Linked environments, a Labs beta you turn on for both machines, lets agents on one machine launch and steer work on another; most tools take an environmentId. Link another environment
• It tracks PRs and sends push alerts. Workers link PRs to threads and can watch them. T3's mobile app gets an alert when an agent finishes, fails or needs you (this needs T3 Connect). Linked pull requests · Mobile notifications

You probably don't need the gateway if:

• your agent is Claude Code, Codex, ChatGPT or another OAuth MCP client, and connecting it to each machine is fine;
• your agents run inside T3 and can reach your other machines through linked environments;
• push alerts in T3's app are the notifications you want;
• approving each agent again every 30 days is no trouble.

The gateway does not replace T3's remote access either: it is for bots, not for you on your phone.

Where the gateway helps is a bot that works unattended for weeks, across several machines, and needs waking up when something happens:

| | T3 Code alone (v0.1.6) | With the gateway | | --- | --- | --- | | Bot connection | An OAuth MCP endpoint on each machine | One OAuth MCP endpoint for every configured machine; bearer tokens for bots without OAuth, overlap rotation and per-token usage | | More machines | Linked environments (Labs beta): turn on for both, link with a pairing code | Add the host to the config and enroll it once | | Access per bot | Read only, or a runtime-mode ceiling that applies in every project | Read or Operate per machine, plus optional project allowlists per bot; model, runtime mode and "may start work" per project | | Staying connected | Agent sign-ins and environment links last 30 days, then you approve or link again; no refresh | Bot sign-ins refresh (an unused refresh token expires after 90 days by default); the gateway renews its own T3 credentials and alerts you if renewal fails | | Safe retries | clientRequestId on launch and send | A stored requestId on every start, follow-up, answer, adoption and settle; a lost launch is found again, never relaunched | | Following work | Read or wait on one thread at a time | Jobs with stable IDs, and one work_feed with a cursor across all jobs and machines | | Notifications | Push to T3's mobile app; webhooks only into T3, to trigger automations | Webhooks out to your bot, with filters, delivery health and replay | | Pull requests | Link and watch PRs; a watch wakes the T3 agent | Each job's PRs and their state, readable by bots; optional PR webhooks | | Threads you started by hand | Agents with access can read and message any thread | Adopt a thread so it gets a job ID, feed events, webhooks and a dashboard row | | Operator view | T3's app on each machine; agents under Settings → Sharing & access | One private dashboard for hosts, bots, jobs and webhooks |

Use both. Work in T3 as usual while bots start, adopt and follow gateway jobs. Every job is an ordinary T3 thread you can open.

T3 facts checked on 2026-10-31 against the v0.1.6 docs and tagged source (2359643cffa6). See the gateway compatibility review for contract changes and verification limits. Sign-in lifetime: outside agents, "Remove an agent"; no refresh grant: McpOAuth.ts; link lifetime: link another environment; access levels: outside agents, "Approve a sign-in"; inbound webhooks: webhook automations.

What the gateway adds

Pick up work you started in T3

A bot can take over a thread you started by hand in T3. It lists the project's threads with fleet_threads, then adopts one with work_adopt. The thread becomes a gateway job: the bot can read its history with work_messages, follow it in work_feed, send it follow-ups with work_continue, answer its questions with work_respond and settle it when you are done.

Adoption only reads from T3. It does not change the thread's model, runtime mode or workspace, uses no launch slot, and leaves the thread exactly where it is in T3. You keep typing into it whenever you like; the job records those turns too. jobs release <jobId> stops following it without touching T3.

Adoption is opt-in per bot. The host needs discovery turned on, and you grant the bot threads:read and threads:control on the gateway machine (step 4 of setup). Archived threads, delegated child threads and threads the gateway already follows cannot be adopted. How adoption works.

For a long-running thread you want every bot to use, such as a coordinator, register it yourself as a standing job instead (see Coordinator threads).

One address for all your machines

Bots connect to one HTTPS endpoint, https://<your gateway>/mcp. The gateway connects to each T3 host for them, so adding a machine is a config entry and one hosts enroll command, not a new connection in every bot.

You approve each bot once with a one-time code on the gateway's approval page. Choose Read (follow work) or Operate (also start and steer it), on All machines or only Selected machines. Bots that take only a bearer token get one from clients token. Use clients tokens <client id> to inspect safe token IDs, creation, expiry, last use and recent tool call counts. Rotate with clients rotate <client id> --token-id <id> --overlap 7d, then update the bot privately before the old token expires. clients revoke-token <client id> --token-id <id> revokes one token immediately; clients revoke <client id> revokes them all. Bots never see T3's credentials. Per-host grants.

Limit a bot to approved projects with clients projects <client id> --project <alias> --project @<host>/<projectId>. Repeat --project for each approved project; this replaces the whole list. It applies to every token of that client, including rotated tokens, and takes effect on the next request without a restart. Discovery, job feeds, attention lists, thread access and bot notifications stay inside the list and the bot's machine grants. No list keeps today's access; --no-projects denies all projects and --all-projects removes the restriction. Project access.

How bots reach the gateway

Your bot lives in the cloud; your gateway lives on your machine and listens only on loopback. The bridge between them is a public HTTPS tunnel, such as Tailscale Funnel or Cloudflare Tunnel. That's the hosted bot's only way in: it cannot use your machine's loopback address or private network directly.

flowchart LR
  Bot["🤖 Hosted bot"] --> Tunnel["🌐 Public HTTPS tunnel"]
  subgraph Machine["🖥️ Your machine"]
    Gateway["🚪 Gateway (loopback)"]
    Dashboard["🎛️ Dashboard (separate loopback listener)"]
  end
  Tunnel --> Gateway
  Gateway -->|Private network| Hosts["🛠️ T3 hosts"]
  Operator["🧑‍💻 You"] -->|Private route only| Dashboard

The gateway talks to your T3 hosts over your private network. The dashboard gets its own private route and never goes on the public tunnel. Bots get the front door; you keep the control room.

If the tunnel goes down, bots lose access even while the gateway itself is healthy. doctor and the dashboard's Run checks test the public URL from the gateway machine; a pass there still needs a connection check from your bot. See troubleshooting if the bridge is out.

Jobs that survive lost connections

Bots work over flaky networks and retry. The gateway makes that safe:

• Every start, follow-up, answer, adoption and settle carries a requestId. A retry with the same ID and the same input returns the original result instead of starting a second job or sending the message twice.
• A launch whose response was lost is marked unknown and found again by its [job:<id>] title marker. It is never launched twice.
• work_feed returns events after a cursor. A bot that saves nextCursor misses nothing while it was away.
• Job state lives in a local SQLite database, so a gateway restart picks up where it left off.

Bots answer the worker's questions

When a worker asks a question, the job shows needs_input and work_status includes the full question and its options, in plain text for bots that read only text. The bot answers with work_respond. Permission approvals (running a command, editing a file) stay with you in T3; the bot sees waitingForApproval and can tell you.

A webhook when work needs you

Polling work_feed works on its own. Add a webhook and the gateway sends a small HTTPS notice when a job finishes a turn, needs input, fails, is cancelled or stops waiting on delegated work. Pull request opened/merged events are opt-in. The bot then reads the details through its normal MCP connection.

To connect a Grok Bot routine, paste its URL and header into the private dashboard and click Connect & Test. Filters narrow a connection to projects, hosts, jobs, events or the bot that started the job. On a connection you set up for one bot, that bot can subscribe its own jobs