> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getunbound.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# OACB

> Apply a security baseline to a coding agent’s own configuration, and verify it holds

OACB is the **Open Autonomous Coding-agent Baseline** — a set of tiers you apply to a coding agent's own configuration, so the agent is constrained before Unbound policies ever see a command.

It is a separate layer from your Unbound policies. Policies decide what an agent may do across your organization; OACB hardens the agent on one machine. You can run either alone, and most teams run both.

<Note>
  Read [the framework](https://github.com/websentry-ai/oacb) before applying `baseline` or higher. Those tiers block commands, and the point of `shadow` is to find out which ones before that happens to a developer mid-task.
</Note>

## Start here

```bash theme={null}
unbound oacb check               # what is installed, and where
unbound oacb apply --tier shadow # log everything, block nothing
```

Leave `shadow` running for about two weeks, read the audit log, then move up:

```bash theme={null}
unbound oacb apply --tier baseline
unbound oacb doctor --tier baseline   # prove the hooks actually block
```

## Tiers

Five, least to most restrictive.

| Tier       | What a developer experiences                                                                |
| ---------- | ------------------------------------------------------------------------------------------- |
| `shadow`   | Silent. Every command is logged, nothing is blocked                                         |
| `receipts` | Warning banners on risky commands, which the developer can abort. **Expires after 30 days** |
| `baseline` | Blocks critical operations, asks before high-risk ones                                      |
| `strict`   | Warns on medium risk, blocks high and critical                                              |
| `paranoid` | Blocks medium, high and critical, and disables auto mode                                    |

Only `audit`, `apply` and `doctor` take `--tier`. On `audit` and `doctor` it defaults to `baseline`; `apply` prompts you to choose when you leave it out.

<Warning>
  `receipts` is the only tier that expires. Thirty days after you apply it, it stops — so it suits a time-boxed rollout, not a steady state. `unbound oacb status` shows the expiry date.
</Warning>

## Agents

`claude-code` (the default) and `codex`.

`diff` is Claude Code only, and so is the `--overrides` flag on `apply` — `apply` itself works on both. On Codex it sets `approval_policy` and `sandbox_mode` to match the tier.

| Agent         | Config it writes                                | Hooks land in      |
| ------------- | ----------------------------------------------- | ------------------ |
| `claude-code` | `settings.json` in your Claude config directory | `hooks/` beside it |
| `codex`       | `~/.codex/config.toml`                          | `~/.codex/hooks/`  |

For Claude Code the config directory follows `CLAUDE_CONFIG_DIR` when you have set it, so OACB installs where Claude Code actually reads.

## Commands

| Command               | What it does                                                                    | Flags                                                                                                     |
| --------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| `unbound oacb check`  | Pre-flight — which agents are installed, their versions, and current OACB state | none                                                                                                      |
| `unbound oacb apply`  | Download hooks and write the agent's config                                     | `--agent` · `--tier` · `--overrides <path>` · `--dry-run` · `--preview-only` · `--yes` · `--print-policy` |
| `unbound oacb audit`  | Score the agent's current settings against a tier and report gaps by rule ID    | `--agent` · `--tier` · `--format <table\|json>`                                                           |
| `unbound oacb doctor` | Run the conformance suite against installed hooks to prove enforcement works    | `--agent` · `--tier` · `--format <table\|json>` · `--verbose`                                             |
| `unbound oacb diff`   | Show the settings delta between two tiers — **Claude Code only**                | `--from <tier>` · `--to <tier>`                                                                           |
| `unbound oacb why`    | Explain the most recent block or warn from the audit log                        | `--agent`                                                                                                 |
| `unbound oacb rules`  | Browse the rule registry                                                        | `--risk <low\|medium\|high\|critical>` · `--search <term>`                                                |
| `unbound oacb status` | Current tier, expiry, and the last 7 days of audit counts                       | `--agent`                                                                                                 |
| `unbound oacb remove` | Strip OACB from the agent's config and delete the installed hooks               | `--agent` · `--dry-run`                                                                                   |

`--from` on `diff` is auto-detected from your settings when you omit it. Every subcommand exits `1` on failure.

### Applying safely

`apply` and `remove` are the two that write to a developer's machine. Both take `--dry-run`, and it is worth using:

```bash theme={null}
unbound oacb apply --tier strict --dry-run    # every step, no files written
unbound oacb apply --tier strict --preview-only # print the policy, install nothing
unbound oacb apply --tier strict --print-policy # resolved policy JSON on stdout
```

For CI or an MDM rollout, `--yes` makes `apply` non-interactive. It still writes a consent record, so there is a trail of what was applied and when.

`apply` backs up the existing `settings.json` before it writes. `remove` uses that backup to put back rules you had before OACB, rather than stripping the file wholesale, and then cleans the backup up.

### Understanding a block

When a developer hits a block, `why` is the fastest route to the reason:

```bash theme={null}
unbound oacb why                       # the most recent block or warn, explained
unbound oacb rules --risk critical     # everything that blocks at this level
unbound oacb rules --search docker     # find a rule by ID or description
```

<Tip>
  If a developer reports "Unbound blocked my command" and nothing shows in your policy logs, check OACB. The two enforce separately, and an OACB block never reaches your Unbound policy history.
</Tip>

## Verify it is working

`audit` and `doctor` answer different questions, and you want both.

* **`audit`** reads the configuration and scores it against a tier. It tells you whether the settings are right.
* **`doctor`** runs real commands through the installed hooks. It tells you whether enforcement actually happens.

Settings can score clean while a hook silently fails, so `doctor` is the one that proves the tier is real:

```bash theme={null}
unbound oacb audit  --tier baseline --format json
unbound oacb doctor --tier baseline --verbose
```

Both accept `--format json` for scripting.

## Removing it

```bash theme={null}
unbound oacb remove --dry-run   # list what would go
unbound oacb remove
```

This removes the OACB block from the agent's configuration and deletes the hook scripts. Rules you had before OACB are restored from the backup taken at apply time.

<Note>
  `--local-hooks` and `--local-managed-settings` on `apply` load hooks and settings from a local directory instead of downloading them. They exist for developing OACB itself and have no place in a normal install or an MDM rollout.
</Note>