For AI agents: the complete documentation index is available at /cafleet/llms.txt, the full documentation bundle is available at /cafleet/llms-full.txt, and this page is available as Markdown at /cafleet/quickstart.md.

Quickstart

Create a fleet, send a message, and close the team from your coding-agent pane inside tmux or herdr. Use the literal IDs returned by each command. Run each CAFleet command in its own shell-tool invocation.

Install

brew install himkt/tap/cafleet
cafleet setup

Alternatively, extract the binary for your platform from GitHub Releases onto PATH, then run setup. Setup installs embedded skills and presets offline; use --coding-agent to select a backend.

Configure

CAFleet is designed to run inside a coding agent without per-command permission prompts. Each backend has a different config file and permission system:

BackendConfig fileManual configurationInstalled by cafleet setupReference
claude (Claude Code)~/.claude/settings.jsonThe permission profile below that matches the Director's modeThe skillsThe sub-section below
codex (OpenAI Codex CLI)~/.codex/config.tomlThe [sandbox_workspace_write] entries belowThe skills, plus ~/.codex/rules/cafleet.rulesThe cafleet rules file
opencodenonenone requiredThe skills, plus the cafleet agent preset at ~/.opencode/agents/cafleet.mdOpencode

The paths above are defaults. CLAUDE_CONFIG_DIR and CODEX_HOME relocate their skills and presets. OPENCODE_CONFIG_DIR relocates only the Opencode preset; its skills remain under ~/.config/opencode/skills. See Config-dir resolution. Opencode also loads default home configuration alongside the relocated preset directory; same-name agent definitions can merge across these sources.

The snippets below are the recommended starting points for the two backends that need one.

Claude Code

Add the profile below that matches the permission mode your Director session runs in to your user-level ~/.claude/settings.json. Members start in dontAsk mode whichever mode the Director uses, so both profiles pre-approve what members need beyond their broker commands.

BehaviorAuto mode profileOther-modes profile
Director session's permission modeautoAny other mode
The Director's cafleet commandsReviewed by the auto mode classifierPre-approved by Bash(cafleet *)
A member's skill loads, skill-page reads, and file editsPre-approved by the entries both profiles sharePre-approved by the entries both profiles share
cafleet member prompt and cafleet member execPrompt the operatorPrompt the operator

cafleet member prompt and cafleet member exec are under ask in both profiles because the first keystrokes arbitrary text into a member's pane and the second runs an arbitrary command there; the operator confirms each invocation.

A claude member needs no allow rule of its own for the broker commands: cafleet passes them on the member's spawn command line. A deny or ask rule that matches a broker command still blocks a member, and cafleet doctor reports it — see Spawn-time allow rules.

Edit and Write let members write files. They apply to every session that reads the settings file, your own included: each then edits files outside Claude Code's protected paths without a prompt or classifier review. What each profile entry is for names the role that needs each entry and gives the path rule that confines this approval. What members can run covers denied commands and the entries to add for your project's own task commands.

Auto mode

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Skill(cafleet)",
      "Skill(cafleet-design-doc)",
      "Read(~/.claude/skills/**)",
      "Edit",
      "Write"
    ],
    "ask": [
      "Bash(cafleet member prompt *)",
      "Bash(cafleet member exec *)"
    ]
  }
}

In auto mode a classifier reviews each Director command that no rule matches, so the allow list carries no Bash(cafleet ...) entry. defaultMode selects auto mode from user-level or managed settings; a project or local settings file cannot select it.

Other permission modes

{
  "permissions": {
    "allow": [
      "Bash(cafleet *)",
      "Skill(cafleet)",
      "Skill(cafleet-design-doc)",
      "Read(~/.claude/skills/**)",
      "Edit",
      "Write"
    ],
    "ask": [
      "Bash(cafleet member prompt *)",
      "Bash(cafleet member exec *)"
    ]
  }
}

Bash(cafleet *) is the single allow-everything entry that the literal integer-id convention enables — one pattern covers every subcommand the Director runs, for every fleet.

Codex

[sandbox_workspace_write]
network_access = true
writable_roots = ["/home/<you>/.local/share/cafleet"]

network_access = true is required because cafleet's multiplexer backends (tmux and herdr) communicate over a local socket, which the Codex sandbox classifies as network access — without it cafleet commands fail with Operation not permitted. writable_roots grants write access to cafleet's default SQLite DB directory. For writable_roots, use the absolute directory obtained by resolving the selected database file against the invoking working directory, or use the default XDG location.

The Codex rules for cafleet commands allow every subcommand while keeping cafleet member prompt and cafleet member exec prompting; the reference above covers their precedence and where operator customizations belong. A rules directory maintained without the installed file needs the minimum rule set.

Trust the working directory

Coding agents ask for a trust confirmation the first time they start in a new directory, and that first-run prompt stalls a freshly spawned member — it ignores every incoming message until the prompt is cleared. Trust the workspace in advance: launch your coding agent once in the working directory the member panes will run in and accept the prompt, or add a trust entry to the agent's configuration file (see your agent's reference page). Trust is granted per directory, so each git worktree needs its own approval.

Simple example — invoke from a coding agent

You can ask your agent: “Use the cafleet skill to create a team with two members, exchange a message, then shut down the team.” The skill manages the bootstrap and supervision protocol.

For the complete command sequence and backend variations, follow Run a fleet.