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 (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. 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. 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:
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 while a hook silently fails, so doctor is the one that proves the tier is real:
Both accept --format json for scripting.

​
Removing it

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.
--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.