AGENTS.md

T3 Code

T3 Code is a minimal GUI for coding agents. A Node WebSocket server wraps provider CLIs (Codex, Claude Code, Cursor, Grok, OpenCode) and serves web, desktop, and mobile clients.

Private fork requirements

These requirements override conflicting upstream defaults later in this document.

• vp check and vp run typecheck must pass before considering tasks completed.
  • If changing native mobile code, vp run lint:mobile must also pass.
• Keep additional verification focused on the files and packages changed.
  • Use vp test run <test-files> for focused built-in Vite+ tests. Use vp run test only when the affected package specifically requires its test script.
  • Backend changes must include and run focused tests for the changed behavior.
  • Run targeted formatting, lint, and type checks for the affected scope when available.
• When adding or materially changing a fork feature, update the root README's “What the fork adds” section with a concise user-facing description.
• Integrated client verification is normally skipped for private-fork changes when focused automated checks adequately cover the affected behavior. Before launching a local web or mobile environment, assess whether the change has meaningful runtime-only risk. For changes involving cross-client behavior, native UI integration, authentication, environment or working-directory selection, or other behavior difficult to verify statically, explain why integrated verification would be especially valuable and suggest it to the user. Run it when requested or approved, and limit it to the affected client surfaces.
  • Web: use the test-t3-app skill.
  • Mobile: use the test-t3-mobile skill and one representative iOS Simulator or Android Emulator available on the host.
  • Subagents must not independently launch dev servers or repeat integrated client verification unless their delegated task explicitly requires it.
  • Stop dev servers, watchers, and other long-running verification processes when the focused verification is complete.

Project Snapshot

T3 Code is a minimal web GUI for using coding agents like Codex and Claude.

This repository is a VERY EARLY WIP. Proposing sweeping changes that improve long-term maintainability is encouraged.

Core Priorities

1. Performance first.
2. Reliability first.
3. Keep behavior predictable under load and during failures (session restarts, reconnects, partial streams).

If a tradeoff is required, choose correctness and robustness over short-term convenience.

Maintainability

Long term maintainability is a core priority. If you add new functionality, first check if there is shared logic that can be extracted to a separate module. Duplicate logic across multiple files is a code smell and should be avoided. Don't be afraid to change existing code. Don't take shortcuts by just adding local logic to solve a problem.

Private Fork Change Policy

This checkout is a private development build that should remain easy to synchronize with the upstream repository. Prefer narrow, localized changes that reuse existing extension points and avoid unrelated refactors, broad formatting churn, generated-file edits, or architectural rewrites that would make future upstream merges harder. Add only the most important focused tests for private customizations; do not build out production-grade test matrices unless the change is unusually risky. The task completion checks above still apply.

When this policy conflicts with the broader maintainability guidance above, prefer the narrower change that reduces future upstream merge cost, even when a wider refactor would be architecturally cleaner.

Treat local verification as a prerequisite to pushing fork-development branches and opening or updating pull requests. Run the task completion checks above plus every additional locally runnable check relevant to the affected scope, and push the branch only after the applicable checks pass. This does not by itself require launching an integrated app environment; follow the guidance above for those checks. Use the pull request for review and integration, not as a substitute for pre-push verification.

Use dev as the fork's primary integration and build branch. Commit private fork work to dev, base fork-specific feature branches and worktrees on dev, and merge completed work back into dev. Keep main as a clean mirror of upstream/main for synchronization only: do not develop, build fork releases, or commit private changes directly on main. To incorporate upstream changes, first fast-forward main from upstream/main, then merge or rebase that synchronized state into dev and resolve conflicts there. Before editing, committing, or producing a fork build, verify that the active branch is dev or a branch based on dev.

Private Build Helpers

Personal shell helpers from ~/.dotfiles operate on this checkout at ~/SynologyDrive/AIMac/repos/t3code. Run them from a shell with the dotfiles loaded; qh shows the current platform-specific list.

• t3-build: build the packaged Dev desktop artifact (DMG on macOS, AppImage on Ubuntu).
• t3-install-desktop: stop the installed T3 Code Dev app if needed, rebuild and replace it while preserving its application data, then launch it.
• t3-dev (macOS): run the Electron desktop app directly from source for development checks.
• t3-run / qt3: launch or restart the installed packaged Dev desktop app.
• t3-install-ios (macOS): build and install the self-contained iOS release on a connected iPhone.
• t3-build-ios (macOS): archive the production iOS app and upload it to internal TestFlight.
• t3-build-expo (macOS): publish a JavaScript-only Expo (OTA) update to the installed production build; only valid while the runtime fingerprint still matches that binary.

The fleet updater is a repo script, not a shell helper: run vp run update:machines from this checkout (scripts/machine-update.ts; the maintainer's shell aliases it as t3-update-machines). It offers one arrow/Space selector to opt into remote desktops, the local desktop, and (on macOS) local iOS. Every selected checkout is inspected concurrently and dirty, uninspectable, or non-dev states are reported before mutation; dirty or uninspectable targets fail the run. Clean non-dev targets require a second unchecked batch approval to switch branches. When some targets are eligible and others are excluded, interactive runs ask (default No) before continuing with the eligible remainder, while non-TTY use skips non-dev targets. Local targets share checkout/dependency preparation; remote targets, the local desktop install, and the local iOS build all run concurrently. Explicit --host, --include-local-desktop, and --include-local-ios flags define the complete non-interactive plan. Real subprocess output stays in compact progress rows and retained failure logs, except interactive local iOS temporarily owns the terminal and streams live so Expo can prompt to unlock the phone; the progress rows, including the concurrent desktop install, stay hidden until that build ends. Use --show-failure-logs to display captured failures or --dry-run for fully synthetic preflight, command, and failure verification without spawning update processes.

Upstream project guidance

You can think of T3 Code as an open source "bring-your-own-subscription" alternative to apps like Claude Desktop, Codex App, Cursor Glass and Conductor.

What makes T3 Code special?

We have over 200,000 users who love T3 Code. It's important we maintain the things they love as we continue to iterate on the product. Here's a brief list of the things we can never compromise on.

1. Open at the core

T3 Code is truly open. We share our roadmap, we share how we think about things, and of course we share all our code. A large number of our users run forks. We work in the open, and should strive to stay that way.

2. Performance without compromise

Lots of apps have gotten bogged down with bad tech decisions and "slop". We have not, and we're proud of the performance of T3 Code. We regularly audit for performance regressions, often caused by sending too much data over websockets, css animations causing gpu spikes, lists being hard to render, and more. Make sure all changes are considerate of performance impact.

3. Remote ready

The architecture of T3 Code's websocket layer (npx t3) enables a lot of awesome remote features. These have become core to the product. Whether users are connecting directly over their local network, using Tailscale, or leaning in fully with T3 Connect (our tunnel solution, also in this repo), we need to make sure new features are properly supported.

4. Multi-surface

T3 Code has 3 key app surfaces: web, desktop, and mobile.

Web is kind of two surfaces, as we have the public facing "app.t3.codes" as well as locally hosting the web app through the npx t3 command. Both need to be supported by all new features where reasonable.

Desktop is the main surface most users install first. It's a full Electron app that bundles the server runner as well. The desktop app can also be used as the host server, allowing remote connections from app.t3.codes or the mobile app.

Mobile is a React Native app for both iOS and Android, available on the App Store and Google Play. The mobile app allows for connecting to any T3 Code server to control work remotely.

A note from Theo

I like ambitious ideas, simple systems, and software that feels obvious. Do not preserve complexity just because it already exists. Do not introduce machinery because it looks architecturally impressive. Understand the real constraint, then fight for the smallest model that makes the correct behavior unsurprising.

Channel both "measure twice, cut once" and "yagni". Fight scope creep. Try to honor the dev's intent in both a minimal and realistic fashion.

The rest of this document is meant to help you navigate the codebase and make changes effectively. Think of these instructions less as "hard rules", more as "good defaults". The developer's preferences should be able to override anything here.

Of note: Most T3 Code contributions will come from T3 Code itself, often controlled remotely. This means you should be careful about accessing data, killing dev servers, and other things that may damage the T3 Code instance that the contributor is using.

A small glossary

We need to be on the same page with terminology. When communicating, use this language:

• you means the agent reading this file and changing T3 Code.
• we, us, and maintainers mean Theo, Julius and the people building T3 Code. These are who you are talking to now.
• user means the person using T3 Code to direct coding agents.
• agent means the coding agent a user runs inside T3 Code. Depending on context, that may also include you.
• provider means the agent runtime or harness T3 Code talks to, such as Codex, Claude, Cursor, or OpenCode.
• client means the web, desktop, or mobile UI.
• environment means one running T3 server and the machine, filesystem, provider credentials, and state it owns.
• project means an environment-local workspace record rooted at a directory.
• thread means the durable conversation and work history for a project.
• turn means one user-to-agent cycle, including follow-up work such as checkpointing.
• T3 home means the base data directory. Runtime state normally lives below its userdata directory.

The three ways to hurt yourself

1. Killing by pattern. Never pkill -f, pgrep | kill, or kill a PID you found by matching a name, path, or worktree string. Your own agent process has this worktree's path in its argv, and this machine runs several other dev servers at once. Kill only a PID you captured at spawn, or the owner of your port from ss -H -ltnp after confirming /proc/<pid>/cwd is your worktree.
2. Writing to the live install. ~/.t3/userdata is the developer's real T3 Code database, in use while you work. Reading it and copying from it are fine, and a good way to get real test data (see Test data). Never start a server against it, never open it read-write, never clean it up.
3. Baking in origins. Never set VITE_HTTP_URL or VITE_WS_URL for dev. Dev is single-origin and Vite proxies /api, /ws, /oauth, and /.well-known. Setting them bakes localhost into the bundle and silently breaks every remote browser.

Hit every surface

The most common defect in this repo is a change that works on the path you tested and is missing everywhere else. Before calling frontend work done, walk this list and say which entries applied:

• Entry points. A behavior reachable from the chat view is usually also reachable from Settings, the command palette, and a keybinding. Fixing one is not fixing the feature.
• Clients. Web, desktop (wraps web, adds Electron shell/IPC), and mobile (React Native, separate navigation). Shared logic lives in packages/client-runtime
• Providers. Codex, Claude, Cursor, Grok, and OpenCode each have an adapter. Provider-shaped features need a decision per adapter, even if the decision is "not supported here".
• Contracts. Anything crossing the wire is typed in packages/contracts. Change the schema and the server, web, mobile, and desktop all follow.
• Reverse states. If you added a way in, add the way out and the way to see it. Snooze needs unsnooze. Close needs reopen. A one-way door is a bug.
• Connection modes. Local, remote/relay, and tunnel behave differently. Multi-device and multi-environment cases are real.
• Docs. docs/ splits by audience. Behavior changes that a user would notice belong in docs/user/ (shipped-product voice, no repo tooling or source paths); architecture and contributor changes in docs/internals/; runbooks in docs/operations/; new vocabulary in docs/internals/glossary.md.

Dev servers

• vp i installs. Worktrees get this from the t3.json setup script; if module resolution looks broken, it probably did not run.
• vp run dev starts server and web. In a worktree, state defaults to that worktree's gitignored .t3, which deliberately outranks an ambient T3CODE_HOME so you cannot land on shared state by accident. An explicit --home-dir still wins.
• Ports derive from the worktree path and are stable across restarts, but read the real ones from the [dev-runner] line since occupied ports shift.
• Sharing over the tailnet is three steps: run vp run dev --share in the background, wait for the pairingUrl: line in its output, paste that full URL (token included) in your reply. Do not wire up tailscale serve by hand for this. For this private fork, the "do not open the URL yourself" default above is overridden: open its origin in a controlled browser before handoff to confirm the app loads, because a successful curl is insufficient — browsers reject some otherwise reachable ports.
• The web app requires pairing. Hand over the pairing URL, not the bare origin. A URL without its token is useless to whoever you gave it to. If the token got consumed, mint a fresh one with node apps/server/src/bin.ts pair — note it carries standard scopes, while the startup URL carries admin scopes (needed for Settings → Connections management).
• Stop what you started, by the PID you tracked. See rule 1.

Test data

An empty database is a bad test. Seed your worktree's .t3 with a copy of real data instead of pointing at live state:

• Copy from ~/.t3/userdata (the developer's real data, the most realistic test set) or ~/.t3/dev. Worktree state lives at <worktree>/.t3/userdata.

• Snapshot the database with VACUUM INTO, which is safe even while a server has the source open and yields one consistent file:

  mkdir -p .t3/userdata
  rm -f .t3/userdata/state.sqlite*  # VACUUM INTO refuses to overwrite
  bun -e "new (require('bun:sqlite').Database)(process.env.HOME + '/.t3/userdata/state.sqlite', { readonly: true }).run(\"VACUUM INTO '.t3/userdata/state.sqlite'\")"

  A plain cp is only safe when no server has the source open, and must bring the -wal and -shm siblings along. A live file copy is a corrupt copy.

• Bring secrets and settings.json only if the flow under test needs them.

• Copy in, never symlink. Data flows one way: into your sandbox, never back out.

Verifying

• Smallest proof that the change works. vp test run <files> for the tests you touched, targeted lint and typecheck for the scope you changed.
• Do not run repo-wide checks. No vp check, no vp run -r test, no vp run -r typecheck unless I ask. CI owns the full suite.
• Backend behavior changes ship with focused tests for that behavior.
• The server is event-sourced and its async flows emit typed receipts. Wait on receipts and worker drains, never on sleeps or polling. A test that needs a timeout to pass is wrong.
• Upon request, user-visible frontend changes should get one integrated pass in a real client: test-t3-app for web, test-t3-mobile for mobile. The primary agent does this once after integrating. Subagents do not launch their own dev servers. Ask permission before doing computer use or spinning up browsers.

Pull requests

• Never make a PR unless the developer explicitly asks you to do so.
• Conventional commit titles, plain language: fix(web): new threads no longer spike CPU.
• Body: the problem in a sentence or two, then how you fixed it. End with the model and harness that did the work.
• UI changes need before/after images. Motion or timing needs a short video. Private-fork pull requests are exempt: do not capture images or video for them, and do not launch a client just to produce them.
• Upload PR evidence to GitHub. Never commit PR-only screenshots or assets such as .github/pr-assets/.
• One concern per PR. If the description says "also", split it.
• When babysitting: poll checks and comments newer than the last push, verify each bot finding against the source, fix real ones, dismiss false positives with a written reason. Stay quiet when nothing is new. Stop when the bots are green on the latest commit.

Plans and work artifacts

• Do not commit implementation plans, research notes, or agent scratch files. Keep temporary working material outside the worktree. .plans/ is gitignored only as a safety net for legacy tooling.
• Track active maintainer work in the GitHub issue or project item that owns it. External proposals follow CONTRIBUTING.md and belong in Ideas discussions.
• Put durable architecture, constraints, and decisions in docs/internals/. Update those docs when the product changes so agents find current facts instead of abandoned intentions.
• A merged PR is the implementation record. Close or update its tracking item when the work lands; do not preserve a second checklist in the repository.

How it works

Clients send typed WebSocket requests. The server turns them into commands, a pure decider turns commands into persisted events, and a projector derives the read model the UI renders. Provider CLIs run as subprocesses; per-provider adapters translate their native protocols into orchestration events. Side effects run in queue-backed reactors that emit receipts when milestones land. Each turn ends with a checkpoint, a hidden git ref, so the app can diff and restore.

Full glossary with file links: docs/internals/glossary.md

Where code lives

• apps/server - WebSocket, orchestration, providers, checkpointing. Effect-heavy: read .repos/effect-smol/LLMS.md before writing Effect code.
• apps/web - React/Vite UI. apps/desktop wraps it, apps/mobile is React Native, apps/marketing is the site.
• packages/contracts - Effect/Schema contracts plus small derived helpers. No heavy runtime logic.
• packages/shared - shared runtime utils, subpath exports, no barrel.
• packages/client-runtime - client code shared by web and mobile.
• .repos/ - vendored read-only references. Prefer their patterns over invented ones. Never edit or import from them. Sync with vpr sync:repos when bumping the matching dependency.

Reference repos

• Open-source Codex repo: https://github.com/openai/codex
• Codex-Monitor (Tauri, feature-complete, strong reference implementation): https://github.com/Dimillian/CodexMonitor

Taste

• Complexity belongs at the adapter boundary. Orchestration stays pure, UI stays dumb.
• Inferred types over annotations. any is the enemy.
• Comments describe how a thing is used, and move when the code moves. To be used mostly to describe functions, not to annotate every line of behavior.
• Our users drive agents all day and notice a dropped frame, a lying spinner, and a stale label. No continuously repainting animations; they peg the GPU on high-refresh displays.
• If a rule here fights the task in front of you, say so loudly and get a human sign-off before breaking it.

Additional tips

• Don't verify with browsers or computer use unless the user explicitly agrees or requests it.
• Security is important, but should not be over-indexed on, especially for dev mode/maintainer-only features.