My T3 Code setup: three machines, one rule file, every agent

In the video I show how I work in T3 Code: every coding agent and every account in one app, three machines, and threads that start and talk to other threads. Config files make a bad video, so the details are here: the commands, the rules I learned the hard way, and the part people asked about most, my HQ repo and the fleet sync that give every agent on every machine the same rules.

If you only want T3 Code on one computer, sections 1 and 2 are enough. The rest is for when your agents run on more than one machine.

The setup at a glance

• Three machines: a laptop, my home PC (Linux) and a Mac mini in the office. Each one runs its own T3 Code server.
• Tailscale connects them, so every app sees every machine's projects and threads. The phone app too.
• Linked environments, so an agent on one machine can start and run threads on the other two.
• HQ, a git repo with my list of projects, machines and accounts, my shared skills, and one instruction file that every agent reads.
• /fleet, a small script that copies HQ's skills and that instruction file to all three machines.

1. Install T3 Code

T3 Code is an open-source (MIT) app from the team behind T3 Chat. It doesn't replace your coding agent. It runs the ones you already have (Claude Code, Codex, Cursor, OpenCode and more) as threads in one sidebar, on desktop, web and phone. One line installs the t3 command:

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

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

Then t3 starts it and opens it in your browser. There's also a desktop app on the site. On a machine you want to reach from elsewhere, run it as a background service so it survives reboots:

t3 service install

You need at least one agent installed and logged in on that machine (for example claude or codex). T3 Code uses its login; it doesn't need your API key.

I run the nightly build because new features land there first, and it did break once: one morning's build didn't start at all, and the fix was merged within two hours. If you don't want that, stay on Stable. You switch under Settings → About → Update track, and that one switch moves every connected machine. Updates work the same way: the built-in update updates all of them at once.

2. All your accounts in one picker

Each agent can have several accounts, called instances. You add them under Settings → Providers. A second Claude account is a second config folder. Log in to it once from a terminal:

CLAUDE_CONFIG_DIR=~/.claude_personal claude auth login

Then add a Claude instance in Settings → Providers and point its config folder at ~/.claude_personal. Codex works the same way with CODEX_HOME. Every instance then shows up in the model picker of every thread.

I use separate accounts for separate jobs. My main Claude account does most of the work. A second Claude account works only on my YouTube channel, so its rules and its usage limits stay apart. One Codex account is the only one that can generate images, so it makes the thumbnails. A clean Claude profile with none of my rules is for recording demos. The office Mac mini has its own work accounts with their own limits. Write down what each one is for: your agents need that list too (section 6).

3. Put your machines on Tailscale

Each machine runs its own T3 server, and the apps connect to all of them. To reach them from anywhere without opening ports, I use Tailscale: install it on every machine and on your phone, and log in with the same account. Then publish T3 Code over Tailscale's HTTPS on each machine:

t3 serve --tailscale-serve

If the server is already running (as a service, say), ask it for a pairing link instead:

t3 pair --tailscale

It prints a QR code and a link to an address like https://<your-machine>.<your-tailnet>.ts.net/. Scan the QR code with the phone app, or paste the link in the desktop or web app under Settings → Environments. The desktop app has the same thing as a switch: Settings → Sharing & access → Tailscale HTTPS.

The pairing code is valid for 5 minutes by default (--ttl changes that). Treat it like a password: anyone who has it before it expires can connect to that machine and run agents on it. Keep it out of screenshots and chats.

A machine can have more than one route: LAN, Tailscale, T3 Connect and others. The app tries them and uses the first one that answers.

The phone app

T3 Code has an app for iPhone and Android. It shows the same machines, projects and threads. It's a remote control: the agents run on your computers, so those have to stay on.

4. T3 Connect, or publish-only

T3 Code also has its own remote access, T3 Connect. t3 up sets it up, and it's free for up to 3 machines (phones and browsers don't count). I checked how it works before turning it on. With Connect on, the app reaches your machine through a Cloudflare tunnel on T3's domain. The encryption ends at Cloudflare, so your whole session (messages, files, terminal output) could be read there. T3's own docs call the relay a trusted broker: it can hand out logins to your machine. That's fine if you trust them. I'd rather not need to.

So I use the middle setting, publish-only. There's no tunnel. The relay only gets what it needs for push notifications (project and thread titles, the model and the status), and I reach the machines over Tailscale. On the command line:

t3 connect link --publish-only
t3 service restart

In the desktop app: Settings → Sharing & access, turn Publish agent activity on and T3 Connect off. Push notifications on the phone need this: according to T3's docs, a direct or Tailscale connection alone doesn't send them. If you want nothing to do with the relay, t3 connect logout signs the machine out of T3 Connect completely; you lose push notifications. And telemetry is a separate switch: set T3CODE_TELEMETRY_ENABLED=false on the machine to turn it off.

5. Link the machines, so agents can work across them

This is the step people miss. The machines in Settings → Environments are connections for you: your app can show them. Your agents can't use them. For an agent on the laptop to start a thread on the Mac mini, the two machines need a link.

Linked environments is a beta, off by default. Turn it on under Settings → Labs on every machine. Then, on the machine you work from: Settings → Environments → Linked environments → Link, pick the other machine and the access level. Or from a terminal. On the other machine:

t3 pair --ttl 5m

And on the one you work from:

t3 environment link https://<other-machine>.<your-tailnet>.ts.net/ --pairing-code <code> --access approval-required

The access options are read-only, approval-required, auto-accept-edits, auto and full-access. It's the most an agent from this machine may do over there; an agent never gets more there than it has here. I link all three machines both ways with full access, because they're all mine and only I use them. Start with approval-required instead, and go higher only for machines nobody else touches. You can also just ask an agent ("link my Mac mini") and approve the card it shows.

Two things to know. A link lasts 30 days and doesn't renew itself, so set a reminder or your agents lose the other machines after a month. And the other machine lists the link under Settings → Sharing & access, where you can revoke it.

Once they're linked, try it:

Which machines can you reach? Start a thread on the Mac mini that checks its free disk space.

6. HQ: one repo that knows the whole setup

Now the part that ties it together. HQ is a git repo in my home folder, ~/hq, on every machine. It holds:

• A list of all my projects: what each one is, which machine it lives on, and where.
• A list of my machines: what each one is for and how to reach it.
• My shared skills: every Claude Code or Codex skill I want on more than one machine. When I need a new global skill, say one that lets every machine use Jira as me, I create it in HQ.
• The global instruction files: the rules every agent loads, wherever it runs.
• The fleet config and script that send all of that to the machines.

The git server is a plain bare repo on my home PC; the laptop pushes and pulls from it. Use the exact same remote URL on every machine. T3 Code groups clones of the same repository into one project, and that's also how it finds the right folder when an agent hands work to another machine.

The shared instruction file

One file, ~/hq/global/T3-CODE.md, is read by every Claude and Codex account on every machine. The fleet sync puts it at ~/.agents/T3-CODE.md everywhere, and the global ~/.claude/CLAUDE.md pulls it in with one line:

@~/.agents/T3-CODE.md

Codex reads its global rules from ~/.codex/AGENTS.md instead, so put the same text there (a copy, or a symlink to the same file). A second Claude account has its own config folder, so give it the same line in its own CLAUDE.md.

Here's mine as a template, with the private parts swapped for placeholders:

# Shared rules for every agent on every machine

Loaded by every Claude and Codex account on my machines.
Source of truth: ~/hq/global/T3-CODE.md, copied by /fleet to
~/.agents/T3-CODE.md on every machine. Edit it there only.

Machines: laptop, home PC, office Mac mini. New projects go on
<machine> in <folder>, with <account>, unless I say otherwise.

## Inside T3 Code: use the t3-code tools
- Other machines are linked (Settings → Labs → Linked environments).
  t3_environment_links lists them with their environmentId. Pass it to
  t3_thread_launch, delegate_task, t3_project_list and
  orchestrator_capabilities (accounts and models live there right now).
- Links last 30 days and never renew themselves. Re-link: `t3 pair --ttl 5m`
  on the other machine, then here:
  `t3 environment link <its Tailscale URL> --pairing-code <code> --access approval-required`
- Recurring checks: schedule_task. PRs and CI: watch_pull_request.
- Child work: delegate_task. Waiting: t3_thread_wait / t3_thread_read.

## What the accounts are for
- <main account>: everything, unless a line below says otherwise.
- <second account>: only <project>.
- <image account>: the only one that can generate images.
- <work account> on <machine>: its own limits; check them before long jobs.

## Rules
- Machines connect over Tailscale HTTPS only. Never add an SSH
  environment in a T3 app.
- One T3 server per machine.
- Copying a project to another machine: read ~/hq/<checklist>.md first.

Notice what isn't in it: no ssh commands, no list of which environment is which, no helper scripts. That's new.

Why it shrank from 60 lines to 37

Until this month the file explained how to reach the other machines: my own command-line helper that drove T3 over ssh, which environment was which, and every account on every machine. Once the machines were linked inside T3, each machine's T3 already knew the others. An agent just asks which machines it can reach and which accounts and models are live there, and starts the thread. So I deleted all of that, and the file went from 60 lines to 37.

What's left is what T3 can't know: my defaults, what each account is for, and the house rules. That's the test I'd use for your own file. If the tool can tell the agent, don't write it down.

7. /fleet: send it to every machine

HQ only helps if every machine has the current version. That's the fleet: one config file, ~/hq/fleet.json, and one script, ~/hq/scripts/fleet.py. A Claude skill called /fleet runs it, so any session on any machine can sync. The config has this shape:

{
  "machines": {
    "pc":     { "ssh": "pc",     "home": "/home/<you>",  "hq": true, "hub": true },
    "laptop": { "ssh": "laptop", "home": "/Users/<you>", "hq": true },
    "mini":   { "ssh": "mini",   "home": "/Users/<you>", "hq": false }
  },
  "files": {
    "global/CLAUDE.md":  { "dest": ".claude/CLAUDE.md",  "to": ["pc", "laptop"] },
    "global/T3-CODE.md": { "dest": ".agents/T3-CODE.md", "to": ["pc", "laptop", "mini"] }
  },
  "homes": { "claude": ".claude/skills", "codex": ".codex/skills" },
  "skills": {
    "jira":     { "to": ["pc", "laptop", "mini"], "secrets": [".env"] },
    "calendar": { "to": ["pc", "laptop"], "auth": "per-machine" }
  }
}

python3 ~/hq/scripts/fleet.py sync then does five things, in order:

• Syncs HQ itself. On every machine that has a full HQ clone: commit local changes, pull with rebase, push.
• Links the skills. On those machines, ~/.claude/skills/<name> and ~/.codex/skills/<name> become symlinks into ~/hq/skills/<name>. Edit a skill once and every agent on that machine has the new version. Anything that was there before gets moved to a backup folder, never deleted. A skill can also have a Codex-specific variant in its own folder.
• Copies to the rest. The office Mac mini doesn't get a full HQ clone, only the skills it needs, copied one way with rsync. It's the work machine, so it gets less.
• Copies the secrets. A skill's secret files (an .env with a token, say) go over ssh to the machines that need them, and never into git. Skills marked per-machine never get copied credentials: each machine logs in on its own, because some logins rotate their tokens and a shared copy would lock the other machines out.
• Places the global files, like the instruction file above: a symlink on HQ machines, a copy on the rest.

fleet.py status shows, for every skill on every machine, whether it's linked or copied, whether its secrets are there, and whether its login still works (a skill can name a check command). --dry-run shows what a sync would change before it changes anything.

You don't have to write this by hand. Give your agent the shape and let it build it:

Create ~/hq as a git repo that holds my shared Claude Code and Codex skills (skills/<name>/) and my global instruction files (global/). Make a bare repo on this machine as its remote, and clone it on my other machines over ssh with the exact same remote URL. Then write scripts/fleet.py with "sync", "status" and a --dry-run flag, driven by fleet.json (machines, files, homes, skills). sync should: commit, pull --rebase and push ~/hq on every machine that has it; symlink each skill into ~/.claude/skills and ~/.codex/skills there, backing up whatever was in the way; rsync skills one way to machines without ~/hq; copy each skill's listed secret files over ssh, never into git (list them in .gitignore before the first commit), except skills marked "auth": "per-machine"; and place each global file (symlink on hq machines, copy elsewhere). Start with a dry run and show me what it would change.

8. The house rules

Every one of these comes from something that went wrong.

• Tailscale HTTPS between apps, never an SSH environment. The desktop app can add a machine over SSH, and when it does, it starts or reuses a T3 server there. My first try used that. It started a second server next to the real one, the two raced each other, and their versions drifted apart.
• One T3 server per machine. Same reason. Each machine runs exactly one, as a service.
• Re-link every 30 days. Links expire. Put it in your calendar.
• Pairing codes are passwords. Short expiry, never in a screenshot, a chat or a commit.

9. Threads that talk to each other

Every T3 thread gets T3's own tools (an MCP server) on top of the agent's normal ones. With them an agent can list other threads, start new ones on any machine and any account, send them messages, wait for them, and settle or archive them when they're done. That's what the instruction file's tool names refer to.

Handing work to another agent:

Delegate this to Codex: check the newsletter draft for broken links and tell me what you find.

The child runs as its own thread, and the parent wakes up when it's done. With linked machines that child can run on another machine, in the project with the same repository there.

The way I work now: one main thread per project, and it's the only one I talk to. Every new idea becomes "start a new thread for this". Then I tell the main thread to watch them:

Watch the threads you started. When they have questions, collect them and ask me all at once.

And when 20 or 30 threads have piled up, one cleanup thread handles them:

Look at all my open threads. Order them by which need the least work to settle and finish, and give me the 4 or 5 questions I should answer to move them along.

I answer in one go, the cleanup thread sends each answer to the right thread, and settles the finished ones. It can answer another thread's questions, but it can't approve permission requests. Those still come to you.

One caution. Once an agent can start agents on all your machines, anything that can steer it can too. Don't paste a web page, an email or a random README into a full-access thread and let it act on it unread.

Where to start

Don't build all of this on day one. Install T3 Code on one machine and use it for a week. Add the second machine over Tailscale when you miss it. Write the instruction file once you catch yourself explaining the same setup to every new session, and build the fleet sync when you've copied a skill by hand for the third time.

T3 Code changes almost daily, so check its docs for the current setting names. This post is part of a series on my AI setup; the other videos are below. Questions, or your own version? Get in touch.

Other videos in this series

My AI setup for running 100+ projects

The setup around all my projects: the six things it had to do, and what I use for each.

AI second brain in 15 minutes, with no extra subscriptions

A wiki the AI writes and keeps up to date, so every new session already knows what the last one learned.

Blog post with the prompts