# Roll bay out to many machines

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

Source: https://getbay.io/docs/rollout (HTML).

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

1. **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
```

2. **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"
```

3. **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
```

4. **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`.