# T3 Code: a control surface for agents you already logged in, still on version 0.0.45

> T3 Code is a local server plus mobile, web and Electron clients that drive coding agents you have already authenticated on your own machine. It installs with one command per platform and keeps its documentation in the repository, but it is a 0.0.x project that says to expect bugs, refuses most contributions, and ships preview builds labelled do not install.

**pingdotgg/t3code** — The repository metadata lists TypeScript as its primary language. The metadata lists the MIT license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/pingdotgg/t3code
- Website: https://t3.codes
- Stars: 24,230 · Forks: 6,338
- Language: TypeScript
- License: MIT
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/pingdotgg-t3code

## A pipe to shell installs the server, and the provider login stays yours

T3 Code is a control surface, not an agent. What you install is a local server and a set of clients for driving agents you already have: a mobile app for iOS and Android, a web app at app.t3.codes, and an Electron based desktop app. Installation is a pipe to shell.

```bash
curl -fsSL https://t3.codes/install.sh | sh
```

In PowerShell on Windows the equivalent is:

```powershell
irm https://t3.codes/install.ps1 | iex
```

Then `t3` starts the server and opens the local web app. Read what those lines do before running them. Piping a download into a shell executes whatever the server returns, with your own account's privileges, and nothing in the command itself verifies a checksum or a signature. If you would rather look first, fetch install.sh, read it, and run the file you inspected. The same reasoning applies to the PowerShell form, which downloads and executes in one step with no intermediate file. To look at the product once without changing the machine's setup, `npx t3@latest` runs it from the registry instead of installing anything permanent.

## The preview tags tell you not to install them, and the version is 0.0.45

Every recent release sits in the 0.0.x range. The list holds v0.0.45-nightly.20261002.2561 published on 2026-10-02, plus two preview builds, v0.0.45-preview.20261001.2556 and v0.0.45-preview.20261001.2518, both published on 2026-10-01 and both titled as maintainer test builds that should not be installed.

The consequence for anyone scripting an update is concrete. Do not point an installer at a preview tag, and do not treat the nightly as the download of record, because the highest version number in the list is not the most finished one. The README offers `t3 update` to move to a newer release, and desktop builds come from GitHub Releases or a package registry, so the dependable route is the release channel the project publishes rather than whatever sorts highest. The project also states its own position in one line: it is very very early and you should expect bugs. A 0.0.x number carries no compatibility promise, so pin whatever version you validated, and read the release notes before jumping, since the agent CLIs underneath are versioned on their own schedule.

## Six providers, six login commands, and nothing to fall back on

The harness does not vendor an agent. It drives what is already authenticated on the machine, and at least one provider has to be installed and logged in before use:

```bash
codex login
claude auth login
agent login
grok login
opencode auth login
```

Cursor's command is `agent login` from the Cursor CLI, Grok Build's is `grok login`, and Antigravity is the single exception: it is enabled in Settings and needs no CLI at all.

That prerequisite has teeth for remote use, because the credentials live in the provider CLIs on the host. A provider whose login never succeeded on that machine gives you a session that will not respond from the phone, and the symptom looks like an agent that is busy or absent rather than an installation problem, so check the login on the host before debugging the app. Running more than one identity is a per provider question, not a global one, and the repository keeps separate pages for multiple accounts on Codex and for multiple accounts on Claude.

## t3 service install changes what survives a reboot, and npx changes nothing

The command set is small, and each entry point has a different cost.

```bash
t3 service install
t3 update
t3 --help
npx t3@latest
```

`t3` starts the server and opens the local web app, which is the right choice while you are sitting at the machine. `t3 service install` keeps it running in the background instead. `t3 update` moves to a newer release, `t3 --help` is the full reference, and `npx t3@latest` is the one that installs nothing.

Desktop users have parallel routes, each with its own price: GitHub Releases, `winget install T3Tools.T3Code` on Windows, `brew install --cask t3-code` on macOS, a downloaded package installed with `sudo apt install ./T3-Code-*.deb` on Debian and Ubuntu, and two AUR packages, `yay -S t3code-bin` for stable and `yay -S t3code-nightly-bin` for nightly, with that packaging kept in the repository under packaging/aur. Two of these need elevated rights, and note who ends up updating the app: the cask, the deb and the AUR packages leave your system package manager in charge, while the CLI route leaves `t3 update` in charge. The nightly AUR package is a different stability contract from the stable one even though the two version strings sit close together.

## Copying .env.example leaves a fork pointed at production Clerk and relay

The .env.example file is the clearest statement of how the cloud side is wired. It says that copying it to .env enables T3 Connect against the production deployment, that the identifiers inside are the same public identifiers baked into official release builds rather than secrets, and that no server-side secrets belong in the file. What you get is a Clerk publishable key, a JWT template named t3-relay, a CLI OAuth client id and a relay URL:

```bash
T3CODE_CLERK_PUBLISHABLE_KEY=pk_live_Y2xlcmsudDMuY29kZXMk
T3CODE_RELAY_URL=https://relay.t3.codes
```

There are commented escape hatches too: an Apple team id and a provisioning profile for signed macOS passkey builds, passkey RP domain overrides, a hosted app URL that the CLI's out of band OAuth flow uses and that defaults to app.t3.codes, and an ingest only mobile OpenTelemetry configuration pointing at Axiom. For a self hosted relay, the file points at infra/relay, which deploys it automatically.

The consequence for anyone building their own version is that doing nothing means pointing at somebody else's production deployment, because the instruction in that file is to remove or comment the identifiers out to build with cloud features disabled. Read it before you ship a modified build, and keep server-side secrets out of the file, since the values already in it are public by design and anything you add will not be.

## Documentation is a directory of markdown because there is no docs site

Full documentation lives in docs/, and the README says plainly that there is no docs site yet. The pages you depend on are therefore files in the repository: install and first run, permission modes, keyboard shortcuts, project settings, remote access from a phone or another machine, keeping app and server in sync, source control integrations, separate pages for multiple accounts on Codex and on Claude, and running T3 Code as a background service. Contributors start from docs/internals/overview.md.

That shape has a cost for anyone reading from a phone. A question about remote access or permission modes means reading markdown in a repository instead of a browsable site, and the pages can lag the build you are running, which is exactly why a page about keeping app and server in sync exists. The page list is also the best map of the feature surface available, and the gaps in it are as informative as the entries: the list covers setup, permissions, keys, remote access, updates and source control, and does not cover authentication for the relay, backup of your session data, or a matrix of supported platforms. Nothing here tells you which remote access method is safe on an untrusted network, so read that page before exposing anything.

## Contributions are mostly closed, so forking and vp i is the way in

The project states its contribution policy in blunt terms: it is mostly not accepting contributions yet, small fixes may be considered and big features will not. Support goes to the Discord server, and feature requests go to an Ideas discussion rather than to the pull request queue.

That leaves building it yourself as the real path in, and the build has a prerequisite of its own. T3 Code uses Vite+, so a global `vp` command line tool is needed first.

```bash
curl -fsSL https://vite.plus | bash
```

On Windows the same tool installs with `irm https://vite.plus/ps1 | iex`, and its getting started guide lives at viteplus.dev/guide/. With `vp` in place, `vp i` installs the workspace dependencies. The tree is a pnpm workspace with apps/, packages/, native/, infra/, packaging/, scripts/ and docs/ directories, and package.json shows the shape of the work: dev, dev:server and dev:desktop scripts driven by scripts/dev-runner.ts, a start script filtered to the t3 package, knip for unused files and dependencies, and a Cargo build for a native resource monitor under native/resource-monitor. Read CONTRIBUTING.md before reporting a bug. The last push landed on 2026-10-01, so the code you fork today is still moving.

## Conclusion

T3 Code suits a reader who already runs one of the supported agent CLIs on a machine and wants those sessions on a phone: it is MIT licensed, the install is one command per platform, and the documentation is in the repository you can read offline. It does not suit anyone who needs a stable version contract, a published documentation site, or a project that takes feature pull requests, because all three are ruled out by the 0.0.45 tag scheme, the missing docs site and the stated contribution policy. Before you depend on it, read the page about keeping app and server in sync, decide whether your own build should keep the production Clerk and relay identifiers that .env.example ships, and assume every provider login has to succeed on the host before a remote session works at all.

## FAQ

### what is t3 code

T3 Code calls itself an agent harness control surface: a server you run on your own machine, plus mobile, web and Electron desktop apps that drive coding agents already installed and authenticated there.

### how to install t3code

The CLI route is curl -fsSL https://t3.codes/install.sh | sh, or irm https://t3.codes/install.ps1 | iex in PowerShell on Windows, then run t3. Desktop builds come from GitHub Releases or from winget, Homebrew cask, a .deb package, and two AUR packages.

### is t3 code open source

The repository is MIT licensed. The README says the project was built to be open, and that if it ever goes the wrong direction, everything needed to fork it and build your own version should be available.

### Is T3Code a harness?

Yes, that is the project's own word for it: an agent harness control surface that works with your existing subscriptions on Claude Code, Codex, Cursor, Grok Build, OpenCode and Google Antigravity, as long as those are set up on your computer.

### t3code vs opencode

OpenCode is one of the supported providers rather than a competitor to replace: install it on the machine, run opencode auth login, and T3 Code controls that session from its mobile, web or desktop app.

## Sources

- [Official documentation](https://t3.codes)
- [Official README](https://github.com/pingdotgg/t3code#readme)
- [Project repository](https://github.com/pingdotgg/t3code)
- [Release notes](https://github.com/pingdotgg/t3code/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pingdotgg-t3code