Operate bay

Roll bay out to many machines

Install bay on every machine, then turn on its hooks for all of them with one merge.

A rollout puts three things in place: the bay program, the skill, and bay's hook entries. The program and the skill belong to each machine. Hook entries belong to the repository, in a settings file on main. So you install on each machine, then merge the hook entries once.

bay install --machine changes no repository, so you can run it on a machine where agents work. Hooks never spread by a bay install in each clone. Every clone takes them from main.

When to use this order

Many machines or accounts: agents on several machines, or under several Claude config folders, share one repository.
Turning on the hooks: the repository merges with bay, and main is about to name [agent] product.
A red `hooks` row: doctor names merging the settings file, not another install.

Roll it out

01
Install the program and the skill on every machine
On every machine, run bay update, then bay install --machine. It writes the skill into every Claude config directory it finds. Install lists where it looks. It writes only the bay program and the skill. It never writes hook entries, a repository's settings or its Git config. On a machine without bay, run the install script first, outside any repository.
sh
```
git config --global --add bay.claudeConfigDirs <dir>   # only a directory bay cannot find
bay update
bay install --machine
```
02
Name the agent product on main
Merge [agent] product = "claude" in .bay/config.toml into main. Each machine's bay doctor now reads the hooks row red until the next step. That red row is normal here, not a fault.
toml
```
# .bay/config.toml
[agent]
product = "claude"
```
03
Merge the hook entries once
In one clone that holds the new main, run bay install. It writes bay's entries into .claude/settings.json, and its result says that file still has to merge. Merge it into main, for example with bay save. Every machine gets the hooks when it takes that change, with no install of its own. On a machine without bay, nothing changes: each Claude Code entry first checks that bay is present.
sh
```
bay install              # writes bay's entries into .claude/settings.json
bay save enable-hooks    # merges that edit into main as one change
```
04
Check each machine
Run bay doctor on each machine after it takes the change. Each doctor pushes its verdict, so bay status --fleet on any one machine shows every machine's. ready counts the green and red machines, and those that never ran doctor. Fix what each red row names. Do not guess.
sh
```
bay doctor           # on each machine
bay status           # on any one machine: fetch every verdict
bay status --fleet   # each machine's verdict, and ready
```

Why this order

bay install reads [agent] from main as this clone last fetched it, so it writes entries only after step 2.
The settings file is on main, so one merge reaches every clone and view.
A bay install in each clone would only leave an uncommitted edit of that file.
Until a clone takes the change, main gives it no bay hook.

What the hooks row says

`hooks` row	What it means	Your step
`off`	Main names no agent product. The row's `recovery` names steps 2 and 3.	Step 2.
red, and main tracks the settings file	The file lacks bay's entries. The row's `recovery` names merging the change that adds them.	Step 3.
red, and no settings file is on main	Nothing holds bay's entries yet. The row's `recovery` says to run install.	Step 3: install in one clone, then commit and merge the new file.
green	This clone holds bay's entries.	Nothing.

With Codex

With product = "codex", the same steps write and merge .codex/hooks.json instead. A Codex entry has no presence check: on a machine without bay, the hook fails, and Codex runs the tool. For the skill, paste the block on Agents and hooks into AGENTS.md.