Every team I have worked with this year has the same problem. They adopt Claude Code. Then they add Codex. Then Gemini CLI. Three coding agents, each with its own config, its own rules file, and its own idea of what it is allowed to do. Nobody on the team can answer a simple question: "what are the agents actually allowed to touch in production?"
The fix is one guardrail file the agents read before they touch anything. That is the whole of agent-guardrails. This note is the short version of the argument.
The problem with per-agent rules
Per-agent config sounds fine until you have more than one agent. Then you have the same policy written three times in three dialects, and they drift. Claude gets a rule about not running migrations. Codex gets the same rule phrased differently and misses an edge case. Gemini does not get it at all. The team thinks the guardrails are in place. They are not - they are in place for one agent, approximately.
If your safety policy is written in the agent's native config format, you do not have a safety policy. You have three safety policies and a drift problem.
One file, read by all of them
A guardrail file is agent-agnostic. It says, in plain language: these commands are forbidden, these paths are read-only, these actions require confirmation, this is the production environment and these are the rules that apply only here. Each agent's adapter translates that one file into the format the agent expects - a Claude command, a Codex rule, a Gemini instruction. One source of truth, N adapters.
Why a file and not a service
You could build this as a server the agents call. I considered it. It is the wrong default for one reason: a file reads at the start of a session and costs nothing. A service is a dependency, a failure mode, and a thing you have to run in every environment - including a developer laptop on a train. The guardrail needs to work offline and offline-first means a file.
The trade-off is that a file cannot enforce rules at runtime the way a server can. It relies on the agent honoring what it read. For the threat model that matters most - the agent doing something it was not supposed to because nobody told it not to - that is enough. For a hostile or compromised agent, you need real sandboxing on top. The guardrail file is the first layer, not the last.
When this is worth it
- One agent, one repo, one person. Probably skip it. The agent's own config is fine.
- One agent, a whole team. Worth it. Shared rules stop the drift between teammates.
- Multiple agents. Required. This is the entire reason the project exists.
- Production access. Required, and pair it with real isolation - not just a rule.
Where it is
Open source: roboticforce/agent-guardrails. There is a longer how-to on the blog - one guardrail policy, three agents - if you want the setup walk-through. This note exists because the walk-through buries the thesis, and the thesis is the part worth arguing about.