Skip to main content
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.
Read the framework 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.

​
Start here

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

​
Tiers

Five, least to most restrictive. 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.
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.

​
Agents

claude-code and codex. audit, doctor, status, why and remove default to claude-code; apply asks which agents to configure (you can pick both), and under --yes applies to claude-code only unless you pass --agent. 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. For Claude Code the config directory follows CLAUDE_CONFIG_DIR when you have set it, so OACB installs where Claude Code actually reads.

​
Commands

--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:
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. With --yes and no --tier, apply installs shadow (log only). apply backs up the existing settings.json before it writes, and remove restores the rules you had before OACB from that backup — your own settings survive both.

​
Understanding a block

These commands report on OACB only. If a policy of yours is not blocking something it should, that is a policy question rather than an OACB one — see A Policy Is Not Blocking. When a developer hits a block, why is the fastest route to the reason:
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.

​
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 without the tier actually blocking, so doctor is the one that proves it is real:
Both accept --format json for scripting.

​
Removing it

Rules you had before OACB are restored from the backup taken at apply time.
--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.