How to roll out Claude Code (and other coding agents) to an engineering team safely

the short answer

Start with a baseline: scan existing agent history offline to see what agents already do. Then install a harness-agnostic policy client on every machine, turn on the coding agent pack’s defaults, and deploy your own high-impact policies in observe mode first. Read a week of real decisions, fix false positives, then enforce. Developers keep their IDE, terminal and agent; the same policies apply to Claude Code, Codex, Cursor and the rest.

Baseline: failproofai audit: offline scan of existing agent history, no account
Install: npm install -g failproofai then failproofai config
Pack defaults: 10 of the coding agent pack’s 39 policies switch on, and enforce immediately
Observe first: Your own policies, as Cloud deployments, for a week before enforcing
Coverage check: Admin → enforcement shows every machine’s deployment and last check-in

Three Principles That Keep Developers on Your Side

Gate effects, not tools. Block terraform destroy, not Terraform. Block DNS changes, not the AWS CLI.
Do not mandate a toolchain. If the policy only works in one IDE, developers move to another one. Pick a layer that covers every harness they use.
Explain every deny. A reason that tells the agent what to do instead keeps the task moving and stops the agent from hunting for a workaround.

The Four-Week Plan

Pack policies turned on with failproofai policies add enforce on that machine immediately; they have no per-policy observe switch. Observe mode is a property of Cloud deployments (and of packs published with an observe effect), which is why the plan puts your own, riskier policies through Cloud deployments.

Week	Goal	Done when
1. Baseline and pilot	Run `failproofai audit` on a few laptops to see past risky patterns; install on 5 to 10 pilot machines including two admins	Pilot machines visible under Admin → enforcement, first events in Observe → Events
2. Observe	Publish your own policies and deploy them in observe mode to the pilot; backtest drafts against past traffic	A week of decisions read under Observe → policy; false positives listed
3. Fleet install	Push the client to every machine through MDM or onboarding; keep your own policies in observe fleet-wide	Coverage near 100%; machines missing a policy are known
4. Enforce	Switch tested policies to enforce, strictest first for admins and on-call	Every intended machine reports the enforce deployment

Install on a Machine

failproofai config installs the failproofaid service (root once, via sudo -n), wires hooks for every agent CLI it finds, and enables no policies on its own; the pack command is what turns guardrails on. The machine key preset also adds jev:evaluate, which turns on Cloud Jev review in observe mode unless you pass --no-transcripts. In MDM or CI, set FAILPROOFAI_CLOUD_TOKEN from your secret store and run the same commands non-interactively. See deploying with Jamf or Intune.

Codex only runs hooks from ~/.codex/hooks.json after a user approves them. When failproofai config can use sudo it writes them into /etc/codex/config.toml instead; without sudo, failproofai config --status does not count Codex as enforcing until the hooks are approved. Plan for that when you count coverage. In restricted networks, FAILPROOFAI_PACK_BASE_URL points pack fetching at a mirror and FAILPROOFAI_NO_DOWNLOAD=1 refuses downloads while installed packs keep enforcing.

npm install -g failproofai
read -rs FAILPROOFAI_CLOUD_TOKEN && export FAILPROOFAI_CLOUD_TOKEN   # machine key (events:add, policies:pull)
failproofai config                                                  # daemon, hooks for every detected agent, Cloud connection
failproofai policies add FailproofAI/policies                       # coding agent pack: its 10 defaults
failproofai config --machine-label platform-alice-mbp               # after config: renames a connected machine
failproofai config --status

A Starter Policy Set

Policy	Effect	How it gets there
`block-env-files`, `protect-env-vars`	deny	Pack default
`block-push-master`, `block-sudo`, `block-curl-pipe-sh`	deny	Pack default
`block-force-push`	deny	Off by default: `failproofai policies add block-force-push`
`warn-destructive-sql`	warn (the call continues)	Off by default: `failproofai policies add warn-destructive-sql`
`terraform-plan-only`	deny destroys and local applies, with a redirect to a PR	Your policy: publish, then deploy in observe
`protect-route53`	deny Route 53 mutations, with a redirect to the dns/ module	Your policy: publish, then deploy in observe
`agents-use-approved-aws-profile`	deny	Your policy: publish, then deploy in observe

Publish, Deploy in Observe Mode, Read the Results

Observe records what a policy would have done and blocks nothing. Read Observe → policy for evaluated actions, blocks, block rate, unguarded actions and activity while paused, then open the linked sessions. Each match is either a real attempt worth blocking or a false positive to fix before enforcing. fp policies and fp fleet are session-only: they exit with an error under an API key. fp fleet deploy replaces the machine’s policy set with the computed result (--add keeps what is there), and applies without asking under --yes, --json or a non-interactive shell.

uv tool install fp-cloud-cli
fp login                                                     # fleet and policy commands need a signed-in session
fp policies test ./terraform-plan-only.policy.mjs --command "terraform apply" --expect deny
fp policies publish terraform-plan-only ./terraform-plan-only.policy.mjs
fp fleet list
fp fleet deploy <machine-id> --add terraform-plan-only:observe
# a week later
fp fleet deploy <machine-id> --add terraform-plan-only:enforce

Enforce, Then Watch Coverage

Switch one policy at a time to enforce, starting with the ones that had zero false positives.
Wait for machines to check in, then confirm under Admin → enforcement that every intended machine reports the new deployment. fp guardrails summary --since 7d gives coverage and block totals from a terminal.
Filter for machines missing a policy and machines that stopped reporting. Those are your real gaps.
If a rollout blocks valid work, roll back exactly: fp fleet history <machine-id> then fp fleet rollback <machine-id> <generation>, or fp policies disable <policy-id> to take one policy off every machine. See policy-as-code.

What to Tell Developers

What is blocked and why, in one paragraph, with the three or four policies that matter.
That their own terminal commands are not gated; only the agent’s tool calls are.
Where to report a false positive, and that a fix is a new policy version, not an argument.
Whether transcripts are collected. Connecting to Cloud sends transcripts by default; --no-transcripts keeps content local while still reporting decisions.

FAQ

How long does a rollout take?

A pilot can be live in a day. Most teams spend one to two weeks in observe mode before enforcing their own policies, because that is where false positives surface.

Do developers need to change how they work?

No. They keep their IDE, terminal and agent. They will occasionally see an agent explain that an action was denied and what to do instead.

Can I start without the cloud?

Yes. failproofai config without a key plus a policy pack enforces locally and sends nothing to Cloud. You add Cloud when you want central deployment, observe mode and fleet telemetry.

What if a machine never picks up the policy?

Coverage under Admin → enforcement shows last check-in and reported deployment per machine. A machine that never pulled is visible, not silent.

Sources

Checked against the sources below on October 21, 2026. Harness settings, hook capabilities and cloud features change between versions.