@crvouga/dev-fleet 0.0.0-stage → 0.2.0

package/.mise/locks/npm-wrangler/4.156.0/package.json

@@ -0,0 +1,7 @@
+{
+  "name": "mise-npm-install",
+  "private": true,
+  "dependencies": {
+    "wrangler": "4.156.0"
+  }
+}

package/.mise/locks/npm-yarnpkg-cli-dist/4.18.1/aube-lock.yaml

@@ -0,0 +1,24 @@
+lockfileVersion: '9.0'
+
+settings:
+  autoInstallPeers: true
+  excludeLinksFromLockfile: false
+
+importers:
+
+  .:
+    dependencies:
+      '@yarnpkg/cli-dist':
+        specifier: 4.18.1
+        version: 4.18.1
+
+packages:
+
+  '@yarnpkg/cli-dist@4.18.1':
+    resolution: {integrity: sha512-EH+A4TxAtBWXKE0DGQxW9Bo9crXHLJ73mfxjTQJuv8XonNWWTpei8BQ5JjczHJNU9GROTycwMFn8iOvRIZXUcA==}
+    engines: {node: '>=18.12.0'}
+    hasBin: true
+
+snapshots:
+
+  '@yarnpkg/cli-dist@4.18.1': {}

package/.mise/locks/npm-yarnpkg-cli-dist/4.18.1/package.json

@@ -0,0 +1,7 @@
+{
+  "name": "mise-npm-install",
+  "private": true,
+  "dependencies": {
+    "@yarnpkg/cli-dist": "4.18.1"
+  }
+}

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 dev-fleet contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -1,3 +1,358 @@
-# Temporary Holding Version
+# dev-fleet
 
-This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
+Keeps a set of development machines in sync: one **manager** and many
+**workers**. One command, `fleet-sync`, brings every machine to the same
+pinned tools, the same coding agents signed in through one proxy, the same
+uptime policy and the same monitoring. Adding or removing a machine is one
+entry in `fleet.json`.
+
+Status: extracted from a working three-machine fleet and in daily use there.
+It has not yet been set up from nothing by a second person; expect rough edges
+and read [what is assumed](#what-it-assumes) first.
+
+## How you use it
+
+You do not clone this repository. dev-fleet is a command you install, and your
+fleet is a small project of your own:
+
+```
+my-fleet/               your repository
+  fleet.json            your machines, your services, the bucket that holds the state
+  package.json          pins the dev-fleet version every machine runs
+```
+
+You run `devfleet` from inside that project and pass it the credentials of a
+storage bucket you own. Nothing else has to be kept:
+
+| What                                                                                    | Where it lives                                                     |
+| --------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
+| The fleet configuration                                                                 | `fleet.json`, in your repository                                   |
+| The version of dev-fleet                                                                | The `@crvouga/dev-fleet` dependency in your `package.json`         |
+| The fleet state: the enrolled workers, the approved revision, the configuration applied | Your bucket (any S3-compatible service)                            |
+| Secrets                                                                                 | The provider `fleet.json` names (`vault`, `sops`, `file` or `env`) |
+| The source, checkouts, tools and reports dev-fleet puts on a machine                    | A cache: delete it and `fleet-sync` rebuilds it                    |
+
+The CLI proxy and the monitoring hub on the manager still keep data of their
+own; [known limits](#known-limits) says what is lost with the manager.
+
+## What it assumes
+
+dev-fleet is opinionated. These are part of it, not options:
+
+- The **manager** is a macOS machine. You run `fleet-sync` on it, and it hosts
+  the shared services (the CLI proxy and the monitoring hub) in Docker Desktop.
+- **Workers** are Ubuntu 26.04 machines reached over SSH. They are stateless:
+  everything on them is rebuilt from Git and your secrets.
+- The fleet state is kept in an **S3-compatible bucket** you own.
+- Machines reach each other over **Tailscale**.
+- Coding agents (Claude Code, Codex, Grok, OpenCode, Antigravity) run through
+  **CLIProxyAPI** on the manager, and **T3 Code** lists one provider per
+  account signed in on the proxy.
+- Machine policy is **Ansible** (`ansible/`), tool versions are **mise** pins
+  (`mise.toml`, `mise.lock`), monitoring is **Beszel**.
+
+What dev-fleet puts on a machine is written in tracked files and pinned to a
+version or digest. [What is declared, and where](docs/declared.md) lists it,
+and what is not pinned yet.
+
+What it does not assume is anything about you: no account, hostname, domain,
+tailnet or repository is written in this code. They live in your `fleet.json`.
+
+## Quickstart
+
+Setting it up with a coding agent? Point it at
+[`llms.txt`](llms.txt) or straight at
+[Set up a fleet from your own project](docs/consumer-setup.md): the whole
+procedure in one pass, including what the agent must ask you for and the
+first sync only you can run. Both ship in the package, under
+`node_modules/@crvouga/dev-fleet/`.
+
+On the manager you need macOS with Git, Node 22 or newer, Docker Desktop and
+Tailscale signed in. You also need an empty private bucket on any
+S3-compatible service (AWS S3, Cloudflare R2, Backblaze B2, MinIO) and an
+access key that can read and write it.
+
+```sh
+mkdir my-fleet && cd my-fleet && git init
+npm init -y
+npm install --save-dev --save-exact @crvouga/dev-fleet
+
+npx devfleet fleet-state --example > fleet.json
+$EDITOR fleet.json                   # your machines, and your bucket under "state"
+
+export DEVFLEET_BUCKET_ACCESS_KEY_ID=…
+export DEVFLEET_BUCKET_SECRET_ACCESS_KEY=…
+npx devfleet fleet-sync --dry-run    # preview
+npx devfleet fleet-sync              # apply
+```
+
+Commit `fleet.json`, `package.json` and the lockfile. Keep the two credentials
+out of Git: pass them from wherever you keep secrets (a password manager's
+`run` command, a git-ignored `.env`, your shell). They are read from the
+environment and never taken from arguments.
+
+`fleet-sync` converges the manager first, then every worker over SSH. It
+fetches the commit your dev-fleet version was published from, sends it and
+your configuration to each machine, installs the pinned toolchain, applies the
+Ansible policy and verifies the result. It prints one table and writes a full
+JSON report. The first run on a machine installs everything, mise included, so
+Git is the only tool it needs beforehand.
+
+`--dry-run` changes no machine. On the manager it checks the release out into
+dev-fleet's cache and installs the Bun that release pins beside any others, so
+that it can run; it never installs the toolchain, publishes the global mise
+configuration, edits shell profiles or touches a worker.
+
+`devfleet` finds the closest `fleet.json` in the directory you run it from or
+above it. `DEVFLEET_CONFIG` names a file elsewhere.
+
+The CLI runs on [Bun](https://bun.sh), which the package brings as a
+dependency. If your package manager does not run dependency install scripts,
+allow Bun's or install Bun yourself; the CLI uses the one on `PATH`.
+
+## The version
+
+Every release of `@crvouga/dev-fleet` is published from one commit and names
+it. The version in your `package.json` is therefore the revision of every
+machine in the fleet:
+
+```sh
+npx devfleet --version               # 1.4.0 (commit 3f2a…)
+npm install --save-dev --save-exact @crvouga/dev-fleet@latest
+npx devfleet fleet-sync              # the fleet moves to that release
+```
+
+Install an older version and run `fleet-sync` to go back. The first worker
+proves a new revision before the others receive it.
+
+## Your project's own tools
+
+On a fleet machine the global mise configuration (`~/.config/mise/config.toml`
+and its `mise.lock`) belongs to dev-fleet: `fleet-sync` publishes it with the
+fleet's pinned tools and the agent worktree roots mise must trust. A project
+pins its own tools in its own `mise.toml` and installs them with
+`mise install --locked` in its checkout. It never publishes a global
+configuration. If anything replaces dev-fleet's, `fleet-status` fails the check
+`tool:global-mise-config` until the next `fleet-sync`.
+
+## Using it from code
+
+dev-fleet has no library API. The package is the `devfleet` command: it
+declares no `main` or `exports`, and nothing under `src/`, `bootstrap/` or
+`ansible/` is a supported import. Any release, a patch included, may change
+them, and some modules read the fleet configuration as soon as they are
+imported. If your project needs something dev-fleet does, ask for a command in
+an [issue](#bugs-and-feature-requests).
+
+## State
+
+Your bucket is the source of truth for everything Git does not hold: the
+roster of enrolled workers, the approved revision, and the configuration
+`fleet-sync` last applied. It is one SQLite database that
+[Litestream](https://litestream.io) replicates to the bucket. `fleet.json`
+says where the bucket is and the command is passed its credentials:
+
+```json
+"state": {
+  "bucket": "my-fleet-state",
+  "endpoint": "https://ACCOUNT.r2.cloudflarestorage.com",
+  "region": "auto"
+}
+```
+
+```sh
+npx devfleet fleet-state             # where the state is, and how it stands with the bucket
+```
+
+The copy on the manager is disposable. **To replace the manager**, clone your
+project on the new machine and run the same two commands:
+
+```sh
+npm ci
+npx devfleet fleet-sync              # with the two bucket credentials in the environment
+```
+
+The roster and the approved revision come back from the bucket, and the
+machine is rebuilt from Git.
+
+Some runs are started by a machine rather than by you: a worker that hands
+`fleet-sync` to the manager, for example. They get no environment, so save the
+credentials on the manager once (in `~/.config/dev-fleet/bucket.json`,
+readable by you alone):
+
+```sh
+npx devfleet fleet-state --init
+```
+
+Without a bucket everything still works from the local copy, and `fleet-sync`
+warns that the manager holds the only one. [docs/state.md](docs/state.md)
+explains how replication stays correct, how to move an existing fleet to a
+project, and which state is not in the bucket yet.
+
+## Add or remove a machine
+
+1. Set up SSH from the manager to the new Ubuntu box (a non-root user with
+   sudo) and join it to your tailnet.
+2. Add it under `workers` in your `fleet.json` and commit:
+
+   ```json
+   {
+     "id": "worker-three",
+     "ssh": "worker-three",
+     "os": "linux",
+     "network": {
+       "tailscaleName": "worker-three.tail0a1b2c.ts.net",
+       "sshPort": 22,
+       "user": "dev",
+       "t3Port": 3773
+     }
+   }
+   ```
+
+3. Run `fleet-sync`. A machine that has only an SSH server and an account
+   with sudo is enough: every pull request proves that against a bare
+   Ubuntu machine, over SSH
+   ([`fresh-box.feature`](features/fresh-box/fresh-box.feature)).
+
+Remove a machine by deleting its entry and running `fleet-sync`.
+
+## Configuration
+
+Your `fleet.json` is validated by
+[`schema/fleet.schema.json`](schema/fleet.schema.json), which the installed
+package carries: `fleet-state --example` prints a complete example that points
+`$schema` at it, so an editor checks the file as you type.
+[`examples/fleet.json`](examples/fleet.json) is the same example.
+
+| Block      | What it declares                                                    |
+| ---------- | ------------------------------------------------------------------- |
+| `source`   | The Git repository nodes accept code from (this one, or your fork)  |
+| `state`    | The bucket that holds the fleet state; never its credentials        |
+| `secrets`  | Where secrets are kept: `env`, `file`, `sops` or `vault`            |
+| `manager`  | The one macOS manager                                               |
+| `workers`  | The Ubuntu workers                                                  |
+| `services` | The proxy's public origin and the monitoring dashboard and accounts |
+| `worker`   | Policy every worker must meet                                       |
+
+Secrets are asked for by purpose (`proxy-client-key`,
+`monitoring-account-password`, `monitoring-tunnel-token`,
+`proxy-tunnel-token`); see [`src/secrets.ts`](src/secrets.ts).
+
+`fleet-sync` records the configuration it applies in the fleet state, so a
+run started outside your project uses the one last applied.
+`fleet-state --export` prints it.
+
+To run your own fork, publish it as your own package and name its repository
+under `source`: the commit a package names must be reachable there.
+
+## Bugs and feature requests
+
+A defect in dev-fleet, or something it cannot do yet, is raised as an
+[issue](https://github.com/crvouga/dev-fleet/issues). From your project that
+is the only way to change dev-fleet, for you and for the coding agents working
+there. Do not patch the installed package, a checkout `fleet-sync` put on a
+machine or a file it manages: the next install or `fleet-sync` replaces them.
+
+The tool says so itself: `devfleet --help` names the issue tracker, and the
+agent contract (`devfleet commands --json`, under `agent.support`) carries the
+rule, what an issue should include and what it must leave out. Agents only
+read it if your project sends them there, so put this in the `AGENTS.md` of
+the project that holds your `fleet.json`:
+
+```md
+The fleet is managed with dev-fleet (`npx devfleet`, pinned in package.json).
+Read `npx devfleet commands --json` before using it. Never edit dev-fleet
+itself: not node_modules, not a clone, not what it installs on a machine. A
+bug in dev-fleet or a feature it lacks is a GitHub issue at
+https://github.com/crvouga/dev-fleet/issues; tell me what is blocked and link
+it. Issues are public: no credentials, hostnames, accounts, domains or
+fleet.json contents.
+```
+
+## Known limits
+
+- Each worker's own login and renewal, and the proxy's backup and recovery,
+  are implemented for the **`vault`** secrets provider only. With `env`, `file`
+  or `sops` the fleet's three shared secrets are read, but those two features
+  are not available yet.
+- The bucket holds the fleet's own state. The CLI proxy keeps its separate
+  encrypted backup (`vault` only), and the monitoring hub's database is not
+  replicated: `fleet-sync` recreates its accounts and systems, but metric
+  history is lost with the manager. See
+  [what is not in the bucket yet](docs/state.md#what-is-not-in-the-bucket-yet).
+- Caches and units on machines still use the historical `personal` prefix
+  (`~/.local/share/personal/fleet`, `/etc/personal-fleet`, unit names). It
+  works, and renaming it needs a migration.
+- The CLI proxy's installed code is a Git worktree of the manager's copy of
+  the source repository (`~/.local/share/personal/fleet/manager/source`).
+  `fleet-sync` fetches that copy again when it is deleted, but the proxy then
+  needs `devfleet cliproxy install` once more.
+- The manager is a Mac host. There is no container image of the manager.
+- `fleet-sync --schedule enable` (unattended runs on a timer) is not available
+  from the published package yet, so nothing re-applies the fleet until you
+  run `fleet-sync`.
+- Not everything on a machine is pinned. [What is declared, and
+  where](docs/declared.md) lists what is and what is not: most of a worker's
+  own packages, the manager's applications and every login are outside it.
+- The reference documents under `docs/` were written for the fleet this came
+  from and are being revised.
+
+## Repository layout
+
+| Path         | What                                                              |
+| ------------ | ----------------------------------------------------------------- |
+| `src/`       | Inventory, orchestration, verification, the report; `src/cli` CLI |
+| `src/state/` | The fleet state database and its replication to the bucket        |
+| `ansible/`   | Machine policy: `ubuntu/`, `macos/`, `monitoring/`                |
+| `agents/`    | Agent launchers T3 runs, and their registry                       |
+| `cliproxy/`  | The CLIProxyAPI service: install, audit, backup, model health     |
+| `bootstrap/` | Toolchain bootstrap and the manager and worker entry scripts      |
+| `schema/`    | JSON schemas for `fleet.json` and the private roster              |
+| `examples/`  | A complete example configuration                                  |
+| `features/`  | What dev-fleet does, as Gherkin features: the tests               |
+| `bin/`       | The entry point of the published package                          |
+
+## Develop
+
+Working on dev-fleet itself is the only reason to clone it:
+
+```sh
+git clone https://github.com/crvouga/dev-fleet.git && cd dev-fleet
+bash bootstrap/bootstrap.sh
+bun install --frozen-lockfile
+bun run check
+./devfleet fleet-status --local      # the CLI, from this checkout
+```
+
+Run from a checkout, `fleet-sync` converges the fleet to the checkout's `HEAD`
+commit (never to uncommitted files). The checkout's `origin` must be the
+repository `fleet.json` names under `source`. Every merge to `main` publishes a release;
+see [releasing](docs/releasing.md).
+
+What dev-fleet does is specified in Gherkin, under
+[`features/`](features/README.md): a `.feature` file states a rule in plain
+words and the steps beside it check it. There are no other TypeScript tests.
+`bun run check` runs formatting, typecheck, lint, every feature and the proxy
+package's Python tests. Features run against `examples/fleet.json` and never
+contact a real machine.
+
+Every pull request runs these checks ([`ci.yml`](.github/workflows/ci.yml)):
+
+| Check                 | What it proves                                                                                                                    |
+| --------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
+| Check                 | `bun run check`                                                                                                                   |
+| Fleet state           | The pinned Litestream replicates the fleet state to a directory and to an S3 API, and a second manager restores it                |
+| Fresh worker over SSH | A new Ubuntu machine with only an SSH server and sudo is bootstrapped by the production code over real SSH, on amd64 and on arm64 |
+| Workflows             | The workflow files pass `actionlint`                                                                                              |
+
+Some scenarios need something a laptop may not have, and are skipped there:
+
+```sh
+DEVFLEET_TEST_FRESH_BOX=1 bun test features/fresh-box     # Docker; tests the HEAD commit
+mise install litestream
+DEVFLEET_TEST_S3=http://127.0.0.1:5000 bun test features/state
+```
+
+## License
+
+MIT. See [LICENSE](LICENSE).

package/agents/antigravity-proxy.ts

@@ -0,0 +1,3 @@
+#!/usr/bin/env bun
+import { runManagedProxy } from './managed-proxy';
+await runManagedProxy('antigravity');

package/agents/audit.md

@@ -0,0 +1,89 @@
+# Agent configuration audit and ownership
+
+Audited against the checked-in tool pins and client source, installed T3 source
+`322f6544dfad0a3c8a0c8cbecf2c7f7874b14268`, and linked vendor documentation.
+This is a compatibility inventory, not a claim that all desktop apps or fleet
+nodes were inspected or authenticated. The execution host exposes Codex, Claude
+and T3 on PATH; the mise catalog additionally includes Gemini, Copilot and OpenCode.
+Cursor and Antigravity are desktop prerequisites, not mise-managed binaries.
+
+| Source/owner                                                           | Installed destination                                                   | Scope                                                                                            |
+| ---------------------------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
+| `mise.toml`, `mise.lock`, `.mise/locks/`; bootstrap                    | Global mise config, shims and installed tools                           | Versions; no authentication                                                                      |
+| `agents/registry.json`; dev-fleet                                      | Dedicated profile outputs described below                               | Endpoint, models, secret references, node model overrides                                        |
+| `cli/lib/agents/render.ts`; dev-fleet                                  | `ROOT/NODE/codex/{direct,proxy}/config.toml`                            | Separate CODEX_HOME, Responses HTTP/SSE provider declaration                                     |
+| same                                                                   | `ROOT/NODE/claude/{direct,proxy}/settings.json`                         | Passed using native --settings; process environment routes proxy                                 |
+| same                                                                   | `ROOT/NODE/opencode/{direct,proxy}/opencode.json`                       | OPENCODE_CONFIG, environment key placeholder                                                     |
+| same                                                                   | `ROOT/NODE/gemini/direct/.gemini/settings.json`                         | GEMINI_CLI_HOME is the profile root; independent native login                                    |
+| `cli/lib/agents/converge.ts`; dev-fleet                                | Each profile's receipt.json; ROOT/backups                               | Nonsecret fingerprints/revision; private migration backups                                       |
+| Existing `opencode/provider-secrets.ts`, OpenRouter package; dev-fleet | Platform OpenCode directory/opencode.json                               | Vault provider catalog, OpenRouter auto policy; existing sync embeds private keys with mode 0600 |
+| Existing OpenCode plugins/bin and cli/lib/links.ts; dev-fleet          | Platform OpenCode plugins/bin, tui.json, notifier files                 | Notification plugins, sounds, platform-derived app paths                                         |
+| `agents/codex-proxy.ts`; dev-fleet                                     | T3 binaryPath points directly into reviewed Git checkout                | Runtime Vault injection; WS_AGENT_NODE is a declared machine value                               |
+| `agents/t3.json`; personal T3 reconciler                               | T3CODE_HOME/userdata/settings.json                                      | Owned provider instances only; plan/apply/import/cleanup and private ownership state             |
+| `../fleet/definition.json`, cli/lib/net; dev-fleet                     | Managed SSH block and VS Code Remote-SSH settings                       | Existing machine aliases, OS/user/identity public paths and T3 ports; no private keys            |
+| `.agents/commands/*.md`; agents:sync                                   | Harness command symlinks                                                | Canonical agent commands; do not edit copies                                                     |
+| Root AGENTS.md, CLAUDE.md, GEMINI.md, .github/copilot-instructions.md  | Repository instruction discovery                                        | Same canonical repository rules                                                                  |
+| Existing cliproxy clients/bootstrap.py and launcher.py                 | ~/.config/cliproxy-fleet; ~/.local/bin/*-fleet                          | Legacy opt-in migration boundary; native settings preserved                                      |
+| Fleet configure                                                        | checkout/node_modules/.fleet-revisions/SHA; .fleet-configuration/*.json | Pinned Git deployment worktrees and per-selection rollout receipts                               |
+
+ROOT is `~/.config/personal/agents` on macOS/Linux and
+`%USERPROFILE%\AppData\Local\personal\agents` on native Windows. Home and platform
+are documented machine-derived inputs. The explicit `--node` ID selects checked-in
+`nodes[ID][TOOL].direct` or `.proxy` model overrides over shared defaults. The local
+fleet roster contains connection aliases/paths, not configuration values or secrets.
+
+The registry is the portable profile source. Native project settings, organization
+policies, MCP servers, skills and plugins can still affect tools through their
+vendor precedence. These are not silently imported from a home directory. Existing
+home MCP definitions, user skills, marketplace caches and desktop settings remain
+unmanaged until reviewed and added to an appropriate canonical repository source.
+Do not treat the registry as a complete export of arbitrary installed applications.
+Usage tracking in CLIProxyAPI/T3 is independent from the inference route.
+
+## Compatibility and authentication evidence
+
+- [Codex configuration](https://learn.chatgpt.com/docs/config-file/config-reference):
+  CODEX_HOME, model_providers, env_key and wire_api. Direct profiles have separate
+  login state. T3 source confirms homePath and binaryPath per provider instance.
+- [Claude gateway](https://code.claude.com/docs/en/llm-gateway-connect) and
+  [settings](https://code.claude.com/docs/en/settings): native settings-file override
+  plus ANTHROPIC_BASE_URL/AUTH_TOKEN. The registry declares `claude-sonnet-4-6`; availability and authentication are checked separately.
+- [OpenCode](https://opencode.ai/docs/config/): OPENCODE_CONFIG merges with native
+  configuration; environment placeholders avoid persisting the proxy key. Direct
+  OpenRouter defaults remain owned by the existing provider sync.
+- [Gemini CLI](https://geminicli.com/docs/reference/configuration/): native settings,
+  GEMINI_CLI_HOME and Google/API-key/Vertex authentication are distinct. Pinned 0.66.0 also supports `gateway` authentication, `GOOGLE_GEMINI_BASE_URL` and a runtime `GEMINI_API_KEY`; the managed proxy adapter uses those native interfaces. Live native-client acceptance remains unverified.
+- [Cursor](https://prod.cursor.com/help/models-and-usage/api-keys): supported API-key
+  setup uses Settings > Models; some features continue through Cursor. No supported
+  unattended portable credential/settings adapter was established; no SQLite edits.
+- [Antigravity](https://antigravity.google/docs/settings): native Google identity and
+  settings are distinct from Gemini CLI. No verified arbitrary proxy-routing adapter.
+- [Copilot](https://docs.github.com/en/copilot/how-tos/copilot-cli): native independent
+  GitHub authentication. No proxy integration is claimed.
+
+Runtime OAuth, auth.json, keychains, T3 pairing/control-plane tokens, SSH private
+keys, session databases, conversations, histories, caches and plugin downloaded
+state are never profile source. Never export or copy them between nodes. Backups
+may preserve preexisting local contents and therefore stay private, outside Git.
+New proxy profiles read only Vault `secret/data/personal/prd` field
+`CLIPROXY_FLEET_CLIENT_API_KEY`; neither generated configs nor receipts contain it.
+Missing access fails without retaining Vault responses. No secret is seeded here.
+
+## Fleet provider routes
+
+The registry’s `proxy.routes` declares the shared accounts (Claude, Codex,
+Gemini, Grok, Muse, Antigravity). Grok Build and the Antigravity CLI are pinned
+native clients with proxy profiles (Grok: `GROK_HOME/config.toml` custom model
+with `env_key`; Antigravity: Gemini API-key mode with `GOOGLE_GEMINI_BASE_URL`).
+Muse runs through the OpenCode harness: native Muse Code only talks to Meta's
+own catalog endpoint. Cursor is not managed (it cannot use the proxy). T3's
+Antigravity instance uses T3's own runtime with the proxy key in T3's per-host
+secret store. See the fleet guide's "Agents on every node".
+Version-specific source evidence:
+[Gemini 0.66.0 gateway interface](https://github.com/google-gemini/gemini-cli/blob/v0.66.0/packages/core/src/core/contentGenerator.ts),
+[CLIProxyAPI 8.0.55 catalog](https://github.com/router-for-me/CLIProxyAPI/blob/v8.0.55/internal/registry/models/models.json).
+A catalog entry is only a supported identifier, not proof that Chris has an
+active account for it. Fleet verifies authenticated availability, inference,
+stream completion and a harmless echo-tool round trip. Native application/T3
+acceptance is recorded separately. Runtime Vault access must work without an
+interactive shell; missing renewal authorization remains action required.

package/agents/claude-proxy

@@ -0,0 +1,5 @@
+#!/bin/sh
+# T3 binaryPath for Claude. The Claude Agent SDK runs any path ending in .ts
+# with node, so T3 needs an extension-less executable; this runs the tracked
+# Bun launcher beside it. No generated copy: this file lives in Git.
+exec bun "${0%/*}/claude-proxy.ts" "$@"

package/agents/claude-proxy.ts

@@ -0,0 +1,3 @@
+#!/usr/bin/env bun
+import { runManagedProxy } from './managed-proxy';
+await runManagedProxy('claude');

package/agents/codex-proxy.ts

@@ -0,0 +1,3 @@
+#!/usr/bin/env bun
+import { runManagedProxy } from './managed-proxy';
+await runManagedProxy('codex');

package/agents/grok-proxy.ts

@@ -0,0 +1,3 @@
+#!/usr/bin/env bun
+import { runManagedProxy } from './managed-proxy';
+await runManagedProxy('grok');

package/agents/managed-proxy.ts

@@ -0,0 +1,55 @@
+/** T3 binaryPath adapter. This file remains in Git; no generated executable copies. */
+import { homedir } from 'node:os';
+import { currentPlatform } from '../src/platform';
+import { agentRoot } from '../src/agents/render';
+import { select } from '../src/agents/registry';
+import { plan } from '../src/agents/converge';
+import { launchProfile } from '../src/agents/launch';
+import { AgentConfigurationError } from '../src/agents/errors';
+import { pinnedPath } from '../src/agents/toolchain';
+
+const SYNC_HINT =
+  'Run devfleet fleet-sync from a terminal to repair this machine.';
+
+export async function runManagedProxy(
+  tool: 'codex' | 'opencode' | 'claude' | 'grok' | 'antigravity'
+): Promise<void> {
+  const args = process.argv.slice(2);
+  // Version probes need no credentials; answering them lets T3 report the real
+  // launch error instead of "unable to determine version".
+  if (args.length === 1 && ['--version', '-v'].includes(args[0]!)) {
+    process.exitCode = await Bun.spawn([tool, ...args], {
+      env: { ...process.env, PATH: pinnedPath() },
+      stdio: ['inherit', 'inherit', 'inherit'],
+    }).exited;
+    return;
+  }
+  try {
+    const selection = select(process.env['WS_AGENT_NODE'] ?? '', tool, 'proxy');
+    const root = agentRoot(homedir(), currentPlatform().name);
+    const result = await plan({ root, selection, revision: 'unverified' });
+    if (
+      !result.previous ||
+      result.previous.fingerprint !== result.fingerprint ||
+      result.files.some((file) => file.state !== 'unchanged')
+    )
+      throw new AgentConfigurationError(
+        `The ${tool} proxy profile for node ${selection.node} is missing or out of date.`
+      );
+    // T3 sets WS_AGENT_ACCOUNT on a provider that is pinned to one account.
+    process.exitCode = await launchProfile(
+      root,
+      selection,
+      args,
+      process.env['WS_AGENT_ACCOUNT'] || undefined
+    );
+  } catch (error) {
+    // Configuration errors carry curated, secret-free messages; others do not.
+    const reason =
+      error instanceof AgentConfigurationError
+        ? error.message
+        : 'Managed provider proxy unavailable.';
+    process.stderr.write(`${reason} ${SYNC_HINT}\n`);
+    process.exitCode = 1;
+  }
+}

package/agents/opencode-proxy.ts

@@ -0,0 +1,3 @@
+#!/usr/bin/env bun
+import { runManagedProxy } from './managed-proxy';
+await runManagedProxy('opencode');