One server controls five installed agent CLIs
T3 Code does not provide the model or replace provider subscriptions. Its server starts and controls agent processes already authenticated on your machine, currently Codex, Claude Code, Cursor, Grok Build, and OpenCode. Web, Electron, and mobile clients talk to that server over an authenticated RPC WebSocket. The server remains the execution boundary: provider processes, terminals, Git operations, and filesystem reads happen on the machine that owns the project. The clients display and control those operations from somewhere else.
That architecture makes sense for developers juggling several agents or machines. Threads can survive beyond one terminal window, worktrees can isolate tasks, diffs and checkpoints expose what changed, and a phone can monitor a long run. The latest v0.0.33 release includes fixes for background subagents, Codex follow-ups, provider sessions, remote projects, usage counts, and desktop or mobile behavior. The release list is long because the product coordinates many moving pieces rather than offering one chat box.
What happened when we ran it
Our sandbox cloned commit 9996038 and counted 16,052 files, roughly 2,509,419 source lines, and 202.2 MB checked out. Installing the pnpm workspace succeeded in 157 seconds, pulling 1,783 packages and using 2,921 MB on disk. The build completed successfully in 60 seconds. Those figures make source contribution a substantial commitment even though the user-facing trial is a single npx t3@latest command.
Vitest completed in 728 seconds with 2,705 tests passed, 0 failed, and 7 skipped out of 2,712. That is the strongest part of the case for T3 Code: our run exercised a large suite to completion rather than merely proving the application bundles. The repository also had 13 CI workflow files and monorepo workspaces. There was no root Dockerfile or tests directory, so test organization lives inside the packages rather than one obvious top-level folder.
Full access is the default permission mode
The permissions guide defines Supervised, Auto-accept edits, Auto, and Full access. New threads begin in Full access unless the user selects something else, and that mode lets the agent run commands and edit files without approval. The docs recommend it for a worktree or disposable sandbox. On a valuable repository, Supervised is the sensible opening position. The exact enforcement also varies by provider, so a familiar label can map to different underlying approval and sandbox systems.
Remote control raises the stakes because the server can reach projects, terminals, Git state, files, and authenticated providers. Pairing begins with a one-time token and becomes a session. The docs warn that pairing URLs should be handled like passwords and can leak through browser history, screenshots, logs, or copying. Tailscale or another trusted private network is the recommended route. A plain LAN HTTP backend also cannot connect through the hosted HTTPS app because browsers block mixed content.
Node versions and provider setup narrow the easy path
The install-free server requires Node 22.16+, 23.11+, or 24.10+, which excludes many machines left on earlier Node 22 builds. At least one provider CLI must already be installed and logged in. Source contributors add the global Vite+ vp tool and a 2,921 MB dependency footprint from our run. Desktop users get packaged releases through GitHub, Homebrew, winget, or AUR, which is the better route unless they intend to modify the product.
Remote SSH launch is thoughtful but still operational work. The desktop app probes the remote host, starts or reuses a server, and forwards its loopback port. Non-interactive shells can fail to find Node installations managed by tools that only initialize in interactive profiles. Client and server versions also need to match; the product shows an update action and may restart the server. Finish active agent and terminal work before updating because the connection briefly disappears.
Version 0.0.33 still earns its warning label
The README calls T3 Code very early and says to expect bugs. GitHub's open count was 1,607 issues and pull requests, which reflects both heavy activity and a large queue. Current reports include iOS controls becoming unresponsive during long-running threads, Android file actions being absent, Grok skills failing to load, and crashes associated with several subagents after an operating-system update. These are relevant because remote control, provider parity, and long agent runs are the product's main reasons to exist.
Development health is plainly strong: v0.0.33 shipped on August 10, 2026, the repository was pushed on August 25, and the release credits many outside contributors. The maintainers also say they are mostly not accepting broad contributions yet, preferring small fixes while the design moves quickly. That is healthy boundary-setting, but it means a team should not assume a large feature proposal will be taken upstream. Forkability exists under MIT; collaboration policy remains selective.
T3 Code is worth adopting when remote supervision changes how often you can use coding agents. Our 2,705 passing tests and successful build give it more substance than the v0.0 tag suggests. Start with one provider and one disposable worktree, set Supervised mode, pair over a private network, and test stop, reconnect, checkpoint, and update behavior before trusting a long task. If you only use one agent at your desk, its native CLI avoids 1,783 extra packages and an additional security boundary.