Primary question: Do you need one mobile/desktop surface to start, stop, and monitor multiple coding agents that already run on your own machine?
RepoDaily adoption score
RepoDaily rates this as 91/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.
5 source(s) across 4 source category/categories, plus a RepoDaily-specific evidence module when available.
5 workflow step(s), 4 next-action step(s), and 8 command/install signal(s) were detected.
Trending momentum is +253 stars, with maintenance/release/issue signals counted when present.
Risk is marked medium, with 5 security note(s) and 4 explicit skip condition(s).
3 opportunity lens item(s), 4 alternative(s), and 4 type-specific section(s) support differentiation.
License source or license wording is present.
7 AI/agent-related signal(s) were detected in the article text and metadata.
Project overview
T3 Code is a self-described "agent harness control surface" published by T3 Tools Inc. under the MIT License. Rather than introducing yet another large language model or agent runtime, it sits on top of the agents you already have installed — Codex, Claude Code, Cursor, Grok Build, and OpenCode — and exposes them through a unified mobile app, web app, and Electron-based desktop app. The pitch is control and remote access, not model replacement.
The project is written in TypeScript and shipped as a monorepo (`@t3tools/monorepo`) that mixes Node.js, Vite+ (vp), Electron, a Rust-based resource monitor, and mobile targets. The fastest way in is `npx t3@latest`, which boots the local server and web UI with no global install. The README warns plainly that the project is very early, that bugs should be expected, and that contributions are mostly not being accepted at this stage.
What makes T3 Code worth a serious look right now is the combination of scope and access model. It targets five of the most discussed coding-agent CLIs in a single control plane, it is remote-first by design (phone or other machine), and the source is open under MIT so teams can fork if the maintainers change direction. The trade-off is maturity: the contributing policy is explicitly restrictive, the docs are a folder rather than a site, and several provider integrations are still evolving.
Why it is trending now
- Addresses a concrete pain point — coordinating Codex, Claude Code, Cursor, Grok Build, and OpenCode from one surface instead of juggling five CLIs.
- Install-free entry point: `npx t3@latest` launches the backend and local web app in a terminal.
- Cross-platform reach: iOS and Android mobile apps, a web app at app.t3.codes, and an Electron desktop app installable via winget, Homebrew, and AUR.
- MIT-licensed and explicitly designed to be forkable if the maintainers go the wrong direction, per the README's own framing.
- 253 stars over the trend window with a rank of 16 signals real, early pull from developers already invested in coding agents.
Problem it solves
- Each major coding agent ships its own CLI with its own login, status, and control flow, making multi-agent setups tedious to drive from a phone or a second machine.
- Existing wrappers — the README names Codex desktop app, Conductor, Claude Desktop, and Cursor Glass — did not meet the authors' bar for performance, remote-readiness, and openness.
- Teams that want to observe long-running agent tasks while away from the terminal lack a unified, mobile-accessible view.
- Lock-in risk: if a wrapper is closed source or changes pricing, users lose their control surface. T3 Code's MIT license and fork-ready stance directly target this.
How it works
- Install and authenticate at least one supported provider before use: Codex (`codex login`), Claude Code (`claude auth login`), Cursor CLI (`agent login`), Grok Build (`grok login`), or OpenCode (`opencode auth login`).
- Launch the control surface. The fastest path is `npx t3@latest`, which requires Node.js 22.16+, 23.11+, or 24.10+ and starts the T3 Code backend plus the local web app.
- Optionally install the Electron desktop app: `winget install T3Tools.T3Code` on Windows, `brew install --cask t3-code` on macOS, or `yay -S t3code-bin` on Arch Linux.
- Connect from a mobile device or another machine using the remote-access flow described in `docs/user/remote-access.md`.
- Pick a permission mode (documented in `docs/user/permission-modes.md`) and drive your agents through the app instead of switching between five terminals.
What the repo structure tells us
The `package.json` confirms a Vite+ (`vp`) monorepo named `@t3tools/monorepo` with apps and packages filtered through `vp run`. Build scripts target `./apps/*`, `./packages/*`, an `oxlint-plugin-t3code` package, and `./scripts`, which implies the lint rules used by the project are themselves published as an in-repo package.
The desktop app is Electron-based (`@t3tools/desktop`) with platform-specific build targets: DMG for macOS (arm64 and x64), AppImage for Linux x64, and NSIS for Windows (arm64 and x64). A Rust component at `native/resource-monitor/Cargo.toml` is built with `cargo build --locked --release` and tested with `cargo test --locked`, which explains how T3 Code can report resource telemetry for agent processes without a pure-JS dependency.
The docs folder exposes the internal architecture: `connection-runtime.md`, `providers.md`, `remote.md`, `server-updates.md`, `resource-telemetry.md`, `environment-auth.md`, and `t3-connect.md` are all listed under `docs/internals/`. That naming suggests a relay-based connection model where agents run on your machine and apps talk to a local server, with T3 Connect acting as the bridge for remote sessions.
Command surface: exactly what the source pack documents
- Install-free run: `npx t3@latest` (README); CLI help via `npx t3@latest --help`.
- Node.js requirement: 22.16+, 23.11+, or 24.10+.
- Provider logins documented in the README: `codex login`, `claude auth login`, `agent login` (Cursor), `grok login`, `opencode auth login`.
- Desktop install: `winget install T3Tools.T3Code`, `brew install --cask t3-code`, `yay -S t3code-bin`.
- Monorepo scripts: `dev`, `dev:share`, `dev:server`, `dev:web`, `dev:desktop`, `start`, `start:desktop`, `build`, `typecheck`/`tc`, `lint`, `test`, and platform-specific `dist:desktop:*` targets.
- Contributor setup requires the `vp` CLI: install via `curl -fsSL https://vite.plus | bash` (macOS/Linux) or `irm https://vite.plus/ps1 | iex` (Windows), then run `vp i`.
Maintenance and contribution posture
The CONTRIBUTING.md is unusually direct. It states the project is not actively accepting contributions, that opened PRs may be closed, deferred, or ignored, and that large feature PRs are likely to be closed quickly. PRs are auto-labeled with a `vouch:*` trust status and a `size:*` diff label, and external contributors receive `vouch:unvouched` until added to `.github/VOUCHED.td`.
This is a clear signal for anyone planning to depend on T3 Code: the project is in a founder-controlled phase. Small bug fixes, reliability fixes, performance improvements, and tightly scoped maintenance work are what the maintainers are most likely to accept. Large PRs, drive-by features, and opinionated rewrites are explicitly discouraged.
The `engines` field pins Node to `^24.13.1` and `packageManager` to `pnpm@11.10.0`, which means contributors who want to build from source must match a specific, recent toolchain. Combined with the `vp` requirement, the barrier to self-building is non-trivial even though the license permits it.
Integration surface: five providers and three clients
- Supported agent providers: Codex, Claude Code, Cursor, Grok Build, OpenCode.
- Client surfaces: iOS app, Android app, web app at app.t3.codes, Electron desktop app.
- Documented docs paths include remote access, permission modes, keyboard shortcuts, source-control integrations, and Linux background service setup.
- Provider-specific multi-account docs exist for Codex and Claude (`providers-codex.md`, `providers-claude.md`).
Who should pay attention?
Good fit if
- You already run two or more of Codex, Claude Code, Cursor, Grok Build, and OpenCode and switch between their CLIs daily.
- You want to kick off or monitor long-running agent tasks from a phone without leaving a laptop logged in.
- You accept early-stage software and want to influence direction through issues rather than large PRs.
- You prefer MIT-licensed, forkable infrastructure over closed-source agent wrappers.
Skip for now if
- You only ever use a single coding agent and its own CLI is enough.
- You need a stable, production-hardened control plane with a documented SLA and public roadmap.
- Your environment cannot meet the Node.js 22.16+/23.11+/24.10+ runtime requirement.
- You expect to contribute large features — the maintainers are explicit that they will not accept them right now.
Risks and cautions
The license and forkability lower strategic risk, but the project's own README and CONTRIBUTING.md make clear that it is early, buggy, and closed to most outside contributions.
- README states: 'We are very very early in this project. Expect bugs.'
- CONTRIBUTING.md states the project is not actively accepting contributions and that large PRs are likely to be closed quickly.
- Docs are a folder (`docs/`) with no docs site, so onboarding depends on reading markdown directly.
- Build-from-source requires the `vp` CLI, pnpm 11.10.0, and Node ^24.13.1, narrowing the contributor pool.
- Provider integrations depend on the continued availability and CLI stability of five separate third-party products.
- T3 Code controls agents that already run on your machine; the security boundary is local-first, but remote access (phone or other machine) widens the attack surface — review `docs/user/remote-access.md` before enabling it.
- Permission modes are documented at `docs/user/permission-modes.md` and should be set to the most restrictive mode consistent with your tasks.
- Environment authentication has a dedicated internal doc (`environment-auth.md`), which suggests credential handling is treated as a first-class concern.
- License is MIT (Copyright 2026 T3 Tools Inc.), which permits audit, modification, and redistribution — favorable for security review.
- No third-party penetration test, CVE history, or formal security policy is referenced in the source pack, so production deployments should treat verification as the user's responsibility.
Alternatives to compare
| Approach | When to use | Trade-off |
|---|---|---|
Claude Desktop | You only use Anthropic's models and want an official, polished desktop client without multi-agent coordination. | Free client; usage billed through your Anthropic plan. |
Cursor (with Cursor CLI) | Cursor is your primary editor and you do not need to drive other agents from the same UI. | Cursor subscription; CLI login is included. |
Codex desktop app | You work exclusively within the Codex stack and want a first-party experience. | Billed through OpenAI usage. |
OpenCode (standalone) | You want an open-source coding agent runtime on its own, without a unified mobile control surface. | Free and open source. |
What this trend reveals
Mobile-first agent operations
iOS and Android apps are rare in the coding-agent control space. Teams that want to triage agent runs during on-call rotations or while traveling can use T3 Code as the front door to multiple backends.
Confirm each provider's remote-access behavior against `docs/user/remote-access.md` and test one provider end-to-end before rolling out.
Fork-ready baseline for internal tooling
The MIT license and monorepo layout make T3 Code a plausible starting point for an internal agent control plane that a platform team customizes for its own providers, branding, or auth.
Build from source following `docs/internals/overview.md` and the `vp i` setup before committing to a fork strategy.
Niche in multi-account orchestration
Multi-account docs already exist for Codex (`providers-codex.md`) and Claude (`providers-claude.md`), which points at a real use case for contractors and agencies juggling client-specific accounts.
Test switching between two accounts of the same provider in a single T3 Code session and document any gaps.
RepoDaily verdict
T3 Code is an early, MIT-licensed, deliberately forkable control surface that unifies five coding agents behind mobile, web, and desktop clients. Its value depends on whether you actually run multiple agents and want remote control of them; its risk is that the maintainers openly call it buggy and are not accepting feature contributions. Try it via `npx t3@latest` before adopting.