How I Use Brigade and T3 Code to Orchestrate Work Across Three Machines

The fleet

My fleet has two Linux environments and one Windows workstation. I control them from T3 Code on desktop, web, and Android. Each server keeps its own credentials, projects, threads, working trees, and T3 database.

1. Install T3 Code on every machine

The current T3 Code install guide requires Node.js ^22.16 || ^23.11 || >=24.10 on the machine that runs the server.

The quickest Linux or Windows test is:

npx t3@latest

That starts the local server and opens the web client.

Linux

Download the Linux AppImage from T3 Code releases, use the Arch package, or run the server through npx:

yay -S t3code-bin
# or
npx t3@latest

For a systemd-based headless Linux machine, T3 can install a user service:

npx t3@latest service install
npx t3@latest service status

Use service update after a T3 upgrade and service uninstall when the host should stop starting T3 at boot.

Windows

Install the native desktop app from PowerShell:

winget install T3Tools.T3Code

You can also run npx t3@latest in PowerShell if you want the server without installing the desktop package.

Treat native Windows and WSL as separate T3 environments. A native Windows T3 process sees Windows paths, the Windows PATH, and Windows provider credentials. A T3 server started inside WSL sees Linux paths, the WSL PATH, and credentials stored inside that distro. Logging into a provider inside WSL does not authenticate the native desktop app.

If a provider binary is not on the server process’s PATH, set its explicit path under Settings → provider instance → Binary path.

2. Add every T3 provider you want to use

T3 Code drives provider CLIs. It does not install or authenticate them. Run these commands on every machine where that provider should be available:

Run the login on the T3 server machine, not on the phone or browser you use to control it. Check Settings in T3 Code after each login. If you want all five providers on all three machines, that is fifteen installs and fifteen logins. Budget the hour.

3. Connect the three environments

Tailscale

T3 Code’s remote-access guide recommends a trusted private network such as a tailnet. Install Tailscale on each machine and the phone, then sign them into the same tailnet.

For a headless server:

tailscale status
tailscale ip -4
npx t3 serve --tailscale-serve

T3 prints a pairing URL and QR code. Add the environment from the phone or another desktop.

For the desktop app, open Settings → Connections, enable Network access, select the Tailscale HTTPS endpoint, and enable Tailscale HTTPS. This uses Tailscale Serve to proxy HTTPS to the local backend.

T3 Connect

T3 Connect is the shorter hosted option:

npx t3 connect

Sign in from the printed link. T3 provisions a managed Cloudflare tunnel and makes the environment available to signed-in T3 clients.

Theo’s July 29, 2026 launch post says T3 Connect is currently free for up to three devices after Cloudflare raised its tunnel limits. The same post says the team may change course if the bill becomes unacceptable. Tailscale and self-hosting remain the fallback.

4. Give projects host-qualified names

The same repository can exist on several machines, and the T3 project picker shows titles, not paths. Register the checkout on each machine with a title that names the host role:

# on the workstation
t3 project add \
  --base-dir "$HOME/.t3" \
  --title "Brigade (Linux workstation)" \
  /srv/repos/brigade

# on the worker
t3 project add \
  --base-dir "$HOME/.t3" \
  --title "Brigade (Linux worker)" \
  /srv/repos/brigade

t3 project rename fixes a title after the fact, and the T3 Command Palette’s Add Project does the same job from the UI. On Windows, use a title such as Brigade (Windows workstation). The title is display identity. It does not change the Git remote.

5. Install T3 Brigade Fleet

T3 Brigade Fleet is the dispatcher. Install Python 3.11 or newer, then:

pipx install git+https://github.com/escoffier-labs/t3-brigade-fleet.git

This installs t3-fleet for controllers and t3-fleet-agent for targets.

Start from examples/fleet.example.toml. Keep the real file outside the repository with owner-only permissions. For each target, configure:

• a generic target ID and platform
• local or reviewed SSH transport
• a fixed t3-fleet-agent command
• the expected hostname and active limit
• each allowlisted repository’s exact local path

Use coordination_mode = "target-authoritative" when several controllers may dispatch. Keep global_active_limit equal to the sum of enabled target limits.

Before sending work:

t3-fleet doctor
t3-fleet capacity

6. Give controller agents the fleet skill

The provider list and the controller list are two different jobs:

• T3 Code providers run the task: Claude Code, Codex, Cursor, Grok Build, and OpenCode.
• Fleet controllers request the task: Codex, Claude Code, Cursor, OpenClaw, or shell.

Import the public t3-fleet-dispatch skill, then project it into each controller harness:

brigade skills lint ./skills/t3-fleet-dispatch
brigade skills import \
  --target "$FLEET_HARNESS_ROOT" \
  ./skills/t3-fleet-dispatch

for target in codex claude cursor openclaw; do
  brigade skills install t3-fleet-dispatch \
    --workspace "$FLEET_HARNESS_ROOT" \
    --target "$target"
  brigade skills sync \
    --workspace "$FLEET_HARNESS_ROOT" \
    --target "$target" \
    --write
done

brigade skills fleet status --target "$FLEET_HARNESS_ROOT"

Run this from the cloned t3-brigade-fleet repository. FLEET_HARNESS_ROOT is the controller user’s profile or harness root, not the fleet checkout.

7. Dispatch from any controller agent

The controller skill follows the same sequence: doctor, capacity, operator approval, submit, then status or wait.

t3-fleet submit \
  --host target-a \
  --repository example-repo \
  --source-revision 0123456789abcdef0123456789abcdef01234567 \
  --title "Verify the public API" \
  --runtime-mode approval-required \
  < prompt.txt

t3-fleet wait \
  --request-id <request-id> \
  --timeout 600 \
  --include-output

Prompt text goes through standard input or a protected prompt file, never the command arguments. Writable work starts from the exact source revision in a target-local worktree.

If you omit model flags, Fleet uses the T3 project’s configured defaultModelSelection. To select another configured provider and model for one request, pass both --model-instance <instance-id> and --model <model-id>. Use IDs from that target’s T3 configuration rather than guessing provider names.

The resulting thread is visible in T3 Code on the target machine, and another approved controller can continue it with the returned request ID.

8. Keep the ownership split

One machine’s OpenClaw hub is the only writer of durable memory. The mirrors on the other two machines are disposable read caches: a session there can recall any reviewed card, but new knowledge travels back as a linted handoff, not as a direct write. Live chats never make this trip. They stay in the T3 environment and provider session that created them.

9. Know the limits

• There is no merged cross-host thread database. One app switches between environments.
• Each deployed target currently admits one active fleet request, so three machines means three configured active slots. That is my configuration, not a T3 Code product limit.
• More machines do not increase a provider subscription’s quota.
• One Windows machine caps WSL2 at 2 GiB with swap disabled, which keeps its WSL-backed lanes unsuitable for heavy jobs until I change that setting.

10. Close the loop with a receipt

When a project result should count, run its verifier through Brigade:

brigade work verify run --target . --command "<project verifier>"

A successful receipt records the verifier command, its exit code, captured stdout and stderr, the target repository, and a timestamp. Attach that file to an outcome or handoff when you need proof the check ran, not the agent’s word.