AI coding agent admin guide·verified October 21, 2026

one policy across claude code, codex, cursor and copilot

Most developers use several coding agents. Write a policy once and enforce it in all of them: which events block in which harness, and where the gaps are.

the short answer

Yes, at the pre-tool gate. Failproof normalizes each harness’s hook events, tool names and inputs into one shape, so a single policy evaluates the same way in Claude Code, Codex, Copilot CLI, Cursor and eight other harnesses. Blocking a tool call before it runs is verified on all twelve. Prompt, stop and post-tool gates vary by harness, so test those on the exact versions you deploy.

Harnesses
12: ten coding CLIs plus Hermes and OpenClaw
Pre-tool blocking
Verified on all twelve
Normalization
29 canonical events; shell tools become Bash with a command field
Varies
Prompt, stop, permission and post-tool gates
Not covered
Gemini CLI; agents outside the twelve get tracing via the SDK

Why One Policy Matters

Developers rarely use just one agent. In The Pragmatic Engineer’s 2026 survey, 70% of respondents used two to four AI tools at the same time and 15% used five or more. The promise to developers is “use whatever agent you like”, and it only holds if the security team does not rewrite every rule per tool. Each vendor’s admin controls are real but separate: Claude Code managed settings, Codex requirements.toml, Cursor enterprise hooks, Copilot policy hooks and managed settings. A normalization layer turns them into one contract.

Blocking Capability by Harness

Capabilities are version-sensitive. Re-test after upgrading an agent CLI, especially for anything beyond the pre-tool gate.

HarnessVerified blocking eventsCaveats
Claude CodePreToolUse, UserPromptSubmit, PermissionRequest, Stop, SubagentStop, PreCompact, several task and config eventsPost-tool and session lifecycle events are observational
CodexPreToolUse, PermissionRequest, UserPromptSubmit, Stop, SubagentStop, PostToolUsePost-tool block replaces the result after execution; hooks need approval or system config
GitHub Copilot CLIPreToolUse, UserPromptSubmit, PermissionRequest, Stop, SubagentStop, PostToolUsePost-tool block replaces the result after execution
CursorPreToolUse, UserPromptSubmit, StopPost-tool and session events are observational
OpenCodePreToolUseStop handling is guidance for a later turn
PiPreToolUse, UserPromptSubmitStop guidance applies to a later turn
Factory DroidPreToolUse, UserPromptSubmit, Stop, PreCompactPost-tool and subagent-stop verdicts are observational
Devin CLIPreToolUse, UserPromptSubmit, Stop, conditional PermissionRequestPermission hooks do not run in every mode
Antigravity CLIPreToolUse, StopPrompt and post-tool verdicts are observational
GoosePreToolUseOther events observational
HermesPreToolUsedeny() blocks; instruct() does not stop the call, it runs with the guidance at the start of its result
OpenClawPreToolUse, UserPromptSubmit, StopPost-tool, session, subagent-stop and compaction events are observational

The Codex Hook-Trust Detail

Codex 0.129 and later only runs hooks from ~/.codex/hooks.json after they are approved interactively. Hooks in the system config (/etc/codex/config.toml) run without approval, so when failproofai config can use sudo it writes a managed block there. Without sudo, and on Windows, the hooks stay in ~/.codex/hooks.json, and failproofai config --status reports Codex as not enforcing until they are approved.

One Policy, Every Harness

ctx.cli names the source harness (for example claude, codex or cursor), so a reason or a rule can differ per agent when it needs to. The built-in block-force-push in the coding agent pack does the same job and is off by default.

import { customPolicies, allow, deny } from "failproofai";

customPolicies.add({
  name: "no-force-push-anywhere",
  description: "Same rule in every agent",
  match: { events: ["PreToolUse"] },
  fn: async (ctx) => {
    if (ctx.toolName !== "Bash") return allow();     // harness-native shell tools are normalized to Bash
    const cmd = String(ctx.toolInput?.command ?? "");
    if (!/\bgit\b.*\bpush\b.*(--force\b|\s-f\b)/.test(cmd)) return allow();
    return deny(`Force-push is blocked in ${ctx.cli ?? "this agent"}. Push a new commit instead.`);
  },
});

Watch for Hooks That Run Twice

  • Cursor can load hooks from third-party tools such as Claude Code, so a Claude Code hook may also fire in Cursor.
  • Copilot accepts Claude-format hooks and treats Bash(...) as an alias for Shell(...) in its managed rules.
  • Duplicate evaluation is harmless for a deny, but it can double-count decisions in your own logs. Check Observe → policy after enabling a new harness.

Known Gaps to Plan For

  • Gemini CLI is not one of the twelve supported harnesses. Govern it with its own system settings and policy engine.
  • IDE-embedded agents that expose no hook surface cannot be gated by any hook-based tool. Failproof can trace Copilot in VS Code through OpenTelemetry (failproofai otel enable copilot), but that is visibility, not enforcement.
  • Cloud-hosted agents (remote sandboxes, cloud agent runs) do not run on the laptop; govern them with the vendor’s cloud controls.
  • Agents you build yourself report through the Python or TypeScript SDK for tracing; enforcement needs a hook at your runtime’s tool boundary.

FAQ

Do I need to configure each harness separately?

failproofai config detects installed agent CLIs and wires hooks for each supported one. Policies are shared.

Can a policy behave differently per harness?

Yes. ctx.cli names the source harness, for example claude, codex or cursor.

What about Copilot in VS Code or the Copilot cloud agent?

Failproof enforces on Copilot CLI and can trace Copilot in VS Code through OpenTelemetry. The cloud agent runs repository hooks and is governed by GitHub’s enterprise managed settings, which also cover VS Code, the Copilot app and JetBrains.

Sources

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

  1. Failproof AI docs: Agent harnesses and enforcement capability
  2. Failproof AI docs: Custom policies (policy SDK)
  3. Failproof AI docs: Use a policy pack
  4. OpenAI Codex docs: Hooks
  5. OpenAI Codex docs: Managed configuration
  6. Cursor docs: Hooks
  7. Cursor docs: Third-party hooks
  8. GitHub docs: Copilot hooks reference
  9. GitHub docs: Enterprise managed settings for Copilot
  10. The Pragmatic Engineer: AI tooling in 2026 survey