You have several terminal tabs open, checking whether Codex finished and whether Claude Code is waiting for approval. Every new agent adds another window. The hard problem is not model quality. It is knowing which task is where, and what needs your approval next.

T3 Code addresses that problem as a "control surface." It is not a model provider. It wraps coding agents you have already authenticated in a local server and lets you control them from the web, desktop, and mobile. It supports Codex, Claude Code, Cursor, Grok Build, OpenCode, and Google Antigravity. The license is MIT.

The convenience is real. But the first thing to inspect is not the feature list. It is the permission default. New threads start in Full access, and remote pairing tokens receive every permission, including access management, unless you constrain their scope. This article explains the architecture from the official repository and docs, then proposes a safe first-run sequence.

What T3 Code does

T3 Code calls itself an "agent harness control surface." Concretely:

  • A local Node WebSocket server runs provider CLIs as subprocesses.
  • A web app, an Electron desktop app, and a React Native mobile app connect to that server.
  • You use agents authenticated with your own subscriptions. T3 Code does not pay for model usage.
  • Threads, projects, approval requests, and checkpoints live on the server.

The repository was created on February 8, 2026. As of October 19, it has 28.6k stars, 7.7k forks, and 6,684 commits. The latest stable release is 0.1.0 (October 15); 0.1.1 preview and nightly builds are being tested above it. One preview build is labeled a maintainer test build and says not to install it. The README says the project is "very very early" and to expect bugs, and that it is mostly not accepting contributions. AGENTS.md mentions 500,000 users, but that is the repository's own claim, not an independently verified number.

Installation is simple:

curl -fsSL https://t3.codes/install.sh | sh
# or without installing
npx t3@latest

macOS also has brew install --cask t3-code, and Windows has winget install T3Tools.T3Code. You need at least one provider CLI installed and authenticated. For example, Codex uses codex login, Claude Code uses claude auth login, and OpenCode uses opencode auth login.

Architecture: why a phone can drive an agent on your laptop

The key design choice is that clients do not talk to models directly. Every request goes through a server running on the host. The official AGENTS.md describes the flow:

[Clients]  web / Electron / React Native
      |  typed WebSocket request
      v
[Local server]
  Orchestrator: serializes commands and decides events (no I/O)
      |
      v
  Event sink: commits events, projections, command receipt, and outbox in one transaction
      |
      v
  Effect worker: starts provider turns, captures checkpoints, runs side effects
      |
      v
  Provider adapter -> Codex / Claude Code / Cursor / Grok / OpenCode / Antigravity CLI
      |
      v
  Hidden git ref checkpoint at the end of each turn

The benefit is that state and credentials stay on the host. The mobile app is a thin client; files and provider authentication remain on the machine running the server. The flip side is that any client that can reach the server can drive files and agents on that machine. Convenience and risk come from the same design.

Checkpoints are worth noting too. Each turn ends with a hidden git ref, so the app can diff and restore. That is useful for undoing mistakes, but it is not a security boundary. It does not isolate the commands or file changes the agent made.

Permission modes: convenience traded against control

T3 Code offers four permission modes per thread.

Mode Behavior
Supervised Requests approval for commands and file changes
Auto-accept edits Approves file edits automatically; other actions may still require approval
Auto Uses the provider's automatic review for routine actions and asks about others
Full access Allows commands and edits without approval

According to the docs, the initial default for new threads is Full access. Existing threads and modes chosen in a draft keep their permissions. Projects can override the environment default.

Providers enforce permissions differently. Auto uses automatic review on Codex, Claude, Cursor, and Grok. Providers without an equivalent, including OpenCode and Antigravity, fall back to asking. Grok does not offer Auto-accept edits, and Muse Code offers only Supervised and Full access. Antigravity can still send native approval requests even in Full access.

The team review workflow is covered in Claude Code team code review.

This is where teams need to make a judgment call. The more agents you run in parallel, the more approval fatigue you feel, and the more tempting Full access becomes. But Full access does not mean "the agent is allowed to make mistakes." It means "the guardrail is off." Unless you are in a test repository, start the first thread in Supervised.

Remote access: a pairing link is a password

T3 Code offers three remote paths:

  • T3 Connect: a tunnel that links environments through an account without router forwarding
  • LAN or private-network pairing: a QR code or link on the same network
  • Tailscale HTTPS or SSH: use existing network and key management

The docs repeatedly say to treat pairing URLs and authorization codes as passwords. Do not put them in screenshots, logs, or bug reports. The reason is simple: whoever has the link can reach the environment.

Scope also needs to be explicit. According to the docs, pairing tokens and issued bearer sessions get every permission, including access management and T3 Connect management, when --scope is omitted. If you want read-only access, narrow it:

npx t3 pair --scope orchestration:read --scope relay:read

terminal:operate and orchestration:operate are especially powerful because they can drive terminals and agent execution. A client that should not manage access also needs to go without those scopes. filesystem:read, filesystem:write, and source-control:write separately govern direct file access and Git changes.

Know how to revoke access. On the host, Settings → Connections lets you revoke client sessions. On the command line, use t3 auth session list and t3 auth session revoke <id>. Revoking a pairing link is not the same as revoking an existing session. Blocking new pairings does not necessarily disconnect a client that already paired.

Browser tabs also run on the host. The first tab downloads a headless Chrome build of about 120 MB, and multiple devices see the same tabs. Audio does not play on your device, and downloads stay on the host until the tab closes. In a remote environment, remember that sensitive pages leave traces on the host.

A simple threat model:

Access path Who can reach it Default scope Mitigation
Local process on the same machine The OS user Full Separate OS account or dedicated machine
LAN pairing Anyone with the link Full unless --scope is set One-time link, private network, revoke after use
T3 Connect Account and linked devices Full unless --scope is set Account security, minimal scopes, deregister
SSH Holder of the SSH key Server permissions Key management, session revocation

A safe first-run checklist

If you are adopting T3 Code, start here.

  1. Begin with a test repository. Avoid environments with production credentials or customer data.
  2. Switch the first thread to Supervised. Confirm that the default is Full access.
  3. Run it under a dedicated OS user or inside an isolated VM/container when possible. T3 Code is not a sandbox.
  4. Give remote pairings only the scopes they need. Do not omit --scope.
  5. Keep pairing links and codes out of screenshots, issues, and logs.
  6. Prefer LAN, Tailscale, or SSH over direct public exposure.
  7. Revoke sessions with t3 auth session revoke when you are done.
  8. Review the checkpoint diff before accepting changes.
  9. Do not run untrusted repositories in Full access.
  10. Treat it as a preview build and plan for updates and bugs.

The checklist is not an argument against T3 Code. It is an argument for treating the control surface like an admin console. The more agents a team runs in parallel, the more important it is to know who approved what.

What not to expect

T3 Code is not a model. It does not make an agent smarter. It is not an isolation sandbox. Anything a provider CLI can do, an agent in T3 Code can generally do too. What it adds is an operations layer: thread management, an approval UI, checkpoints, and multi-device access. If you need isolation, see the Copilot local sandbox guide. The model/harness distinction is covered in Model vs. harness.

It is also early. The README warns about bugs and says big feature contributions are not being accepted. The repository has more than 1,400 open issues and 1,400 open pull requests. Plan around preview releases.

Finally, "one screen" does not mean "one permission." Bringing multiple providers into one UI also concentrates approval flows. That convenience is a concentration of attack surface. Lowering default permissions, narrowing remote scopes, and revoking sessions matter as much as the features.

Conclusion: a control surface is a permission design, not just a convenience

For developers running several coding agents in parallel, T3 Code offers clear value. You can see task state, approve work, and compare checkpoints without switching terminals. Seeing the same environment from web, desktop, and mobile is useful for remote work.

But turning it on means operating a small admin console. The default is Full access, and an unscoped pairing token gets every permission. The first setting to change is not the model or the theme. It is the permission.

References

Go deeper with a course

The more coding agents you run, the more the important work shifts from choosing a model to binding project rules and verification into the working environment and designing approval points. The next step is learning to run Claude Code as a controlled workflow rather than by feel.