A control room, not another coding model
T3 Code is easiest to understand as a remote control for agent CLIs already running on a machine. It does not supply a model, subscription, or replacement runtime. Instead, its server launches and manages Codex, Claude Code, Cursor, Grok Build, and OpenCode, then exposes those sessions through web, Electron desktop, iOS, and Android clients.
That distinction is useful. Developers who switch between provider strengths can keep one project interface, see conversations and tool activity, open terminals, inspect diffs, and approve actions without living in five separate products. T3 Code also supports multiple Codex and Claude configurations, including separate work and personal accounts. Provider authentication remains on the server machine, where the underlying CLI expects it.
The server architecture fits the remote promise
The server is the execution boundary. Provider processes, terminals, Git operations, and filesystem reads happen there, not on the phone or browser. Clients connect through an authenticated Effect RPC WebSocket, and methods have individual authorization scopes. The orchestration layer is event-sourced: commands become persisted events, projections form the current state, and event storage plus projection updates share one SQL transaction. This is thoughtful machinery for recovering sessions and keeping several clients in agreement.
Each turn can be bracketed by Git-backed workspace checkpoints stored as hidden refs. T3 Code can show turn and thread diffs and revert both workspace state and provider conversation state. That is more valuable than a pretty chat view. It gives parallel agent work an escape hatch when an edit goes wrong, especially when each task lives in its own worktree.
Source-control support reaches beyond GitHub to GitLab, Bitbucket, and Azure DevOps. Users can clone, publish local repositories, create pull or merge requests, and detect existing reviews. Those features depend on tools and credentials installed on the server, such as GitHub CLI, GitLab CLI, tokens, or Azure CLI. T3 Code coordinates the workflow rather than hiding its dependencies.
Remote access is powerful and needs discipline
A running server can mint a one-time pairing token and QR code with npx t3 pair. The documentation recommends a private network such as Tailscale. Other options include direct LAN access, a headless server, HTTPS endpoints, or a desktop-managed SSH launch that creates a local port forward. The hosted web app connects directly to your backend; it does not proxy project traffic through T3 Code.
Pairing credentials deserve the same care as passwords. The guide warns that URLs can leak through history, screenshots, logs, or copying, even when the token sits in the URL fragment. Sessions and old credentials can be inspected and revoked through the CLI. Binding a server to all interfaces for mobile convenience without a trusted network would expose an execution service that owns terminals, source files, Git state, and authenticated agents.
The permission default is the more immediate risk. New threads start in Full access unless the user chooses otherwise. In that mode, commands and edits proceed without prompts. Supervised mode asks before both and restricts work outside the workspace. Auto and edit-only modes map onto each provider's own approval behavior, so enforcement is not perfectly uniform. Start unfamiliar work in Supervised mode and use Full access only inside a disposable worktree or sandbox, exactly as the documentation recommends.
The one-command install has prerequisites
npx t3@latest starts the backend and local web app without a permanent installation. Desktop builds are also distributed through GitHub Releases, Winget, Homebrew, and the Arch User Repository. This is a strong first-run story.
The hidden work comes before that command. The server requires Node 22.16, 23.11, or 24.10 and later compatible lines. At least one provider CLI must be installed, discoverable on PATH, and authenticated on the server host. Remote SSH launches can fail when a version manager initializes only in interactive shells. Adding multiple providers, account-specific homes, source-control credentials, and remote endpoints turns a quick test into a system that needs deliberate configuration.
Client and server versions also need to match. T3 Code warns about skew and can update some background services, but an update restarts the server and may interrupt active agent work. The guide tells users to finish commands before updating. That is sensible, yet frequent 0.0.x releases make coordination part of normal ownership.
Outstanding polish is the price of velocity
At review time, T3 Code had roughly 17,000 stars, a same-day push, and release 0.0.32 from the previous day. GitHub reported 1,290 open issues and pull requests combined. Current activity includes fixes for worktrees, reconnects, mobile scrolling, provider events, terminal behavior, server memory, and client version transitions. New issue traffic on August 8 covered thread creation, streaming projection work, and remote usability.
This is extraordinary momentum for a repository created in February 2026, but it is not maturity. The README explicitly says to expect bugs, and the project is mostly closed to large outside contributions while maintainers control scope. The latest release alone contains a very long list of fixes and features, which shows responsiveness and continuing instability at once.
T3 Code is worth trying if remote, multi-provider supervision is the missing piece in your agent workflow. Pin matching client and server versions, begin with one provider, use private networking, and keep risky work isolated. Developers who use one agent locally will usually be better served by that agent's native interface.