Governing AI Coding Assistants Across Your Fleet: Claude Code, OpenAI Codex, and GitHub Copilot (2026)

Governing AI coding assistants is now a fleet problem, not a per-laptop one, because three different tools with three different permission models are running side by side on machines security never enrolled. A single backend team might have Claude Code reading the repo through its PreToolUse hook, OpenAI Codex running shell commands inside an OS sandbox, and GitHub Copilot completing code inline, all on the same endpoint, each governed by its own config file in its own location. None of the three reports to your security stack by default.

That is the tension this guide resolves. You do not get to standardize on one assistant, and you should not try; developers pick the tool that fits the task. What you can standardize is the governance loop around all of them: inventory what is installed, classify it, set policy, enforce that policy where a real gate exists, and keep an audit trail. This is the umbrella framework that the per-tool deep dives sit under, including the Claude Code security guide, the Codex sandbox and approvals guide, and the Copilot best-practices security guide.

If you want the wider context first, the pillar on securing AI coding agents and CLIs frames why this class of tool is its own security surface. This guide is the operational layer: how to govern all three at once. Start with the fleet inventory view to ground the abstract in what running this actually looks like.

Why does each tool need its own governance approach?

Because each tool decides what it can do, and when it asks you, in a different place using different language. A policy you write for one does not transfer to the others. The three models, grounded in each vendor's official docs:

• Claude Code controls actions through a permission system: a settings.json file holds allow and deny rules, four permission modes (default, auto-accept edits, plan, and a research-preview auto mode) change how aggressively it acts without asking, and a PreToolUse hook can run before each tool call. Settings can be scoped from organization-wide policy down to a personal file, which is exactly why a developer can quietly widen their own.
• OpenAI Codex controls actions through OS-level sandboxing plus an approval policy. sandbox_mode selects read-only, workspace-write, or danger-full-access; approval_policy decides when Codex pauses for sign-off; and on macOS it enforces with Seatbelt while on Linux it uses bubblewrap and seccomp. In workspace-write, network access is disabled by default and .git, .agents, and .codex stay read-only.
• GitHub Copilot controls behavior through org and enterprise policies plus content exclusion, configured by admins rather than living on the endpoint. Content exclusion stops named files from informing inline suggestions or Chat, and policies turn features on or off. Copilot inline completion has no per-action runtime gate the way the other two do.

The takeaway: two of these tools enforce at runtime, one is preventative, and all three keep their controls somewhere your security console cannot see. That gap is the whole problem.

How do the three permission models actually compare?

Put side by side, the differences are sharp. This is the matrix to keep open while you write policy, because it tells you which lever exists for which tool.

Notice the bottom two rows. Only Copilot gives you a central audit trail out of the box, and every tool has some path to relaxing its own guardrails. Both facts shape where you need external visibility. For how a single relaxed setting becomes an incident, see the Copilot VS Code auto-run RCE writeup.

How do you build the fleet inventory first?

You cannot set policy on, or enforce policy against, a tool you have not found. Inventory is step one and the step most teams skip. The questions to answer per endpoint:

• Which assistants are installed: Claude Code, Codex, Copilot, or some combination, and at what version surface (CLI, IDE extension, both)?
• Which MCP servers is each assistant wired to, and what credentials do those servers hold?
• Which local permission files exist, and have they drifted from the org baseline (a widened settings.json, a config.toml set to danger-full-access)?
• Which CLIs, extensions, skills, plugins, hooks, and secrets sit alongside the assistants and extend their reach?

That last point matters because the attack surface is not just the assistant binary. A coding agent's real power comes from everything attached to it. The multi-agent prompt-injection and credential-theft analysis shows how an attacker chains those attachments together. Inventory has to cover the whole stack on each machine, which is what Anomity's fleet inventory is built to enumerate.

How do you set policy that maps to each tool?

Once you can see the fleet, write one policy expressed three ways. The policy intent stays constant ("no coding assistant writes outside its workspace without sign-off"); the mechanism differs per tool. A worked example of a Codex config that keeps writes scoped and network off:

# .codex/config.toml - workspace-scoped, network off, approvals on
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false   # default; only widen behind a proxy allowlist

The same intent in Claude Code is a deny rule plus a PreToolUse hook that inspects the command before it runs; in Copilot it is content exclusion on sensitive paths plus an org policy. The trap is treating these as three separate projects. They are one policy with three encodings. Map each intent to its mechanism in a single table so nothing falls through:

Writing the policy is the easy half. The hard half is knowing whether it is actually in force on every endpoint, which is why detection of drift matters as much as the policy text.

Where can you enforce at runtime, and where can't you?

Be honest about this, because over-promising runtime enforcement is how governance programs lose credibility. Runtime gating exists only where the tool exposes a decision point:

• Claude Code: the PreToolUse hook fires before each tool call and can return allow, deny, or ask. This is a true per-action gate you can wire policy into. The risk is that the hook, like every other setting, lives on the endpoint and can be edited there.
• OpenAI Codex: enforcement is the OS sandbox plus approval prompts. You do not gate individual tool calls with custom logic, but sandbox_mode and approval_policy together decide what runs freely versus what pauses, and the sandbox is enforced by Seatbelt or Landlock, not just convention.
• GitHub Copilot: inline completion has no per-action runtime gate. Governance is preventative: content exclusion and org policy. You shape what Copilot can see and suggest, not whether a specific suggestion executes.

So your enforcement plan is necessarily hybrid: a real gate on Claude Code via the hook, sandbox-and-approval posture on Codex, and preventative configuration on Copilot. The danger is the gaps between these, especially CI and bot contexts where a coding agent runs without a human. See the Claude Code GitHub Action actor-bypass analysis and the Codex branch-name command-injection writeup for how automation contexts slip past assumptions.

What should you check on every endpoint, on a schedule?

Policy decays. A clean fleet drifts as developers install new tools, attach new MCP servers, and tweak local settings. Recurring checks keep the picture current:

1. New assistant installs or version changes since the last scan, including shadow installs on contractor or BYOD machines.
2. Local permission drift: a settings.json widened beyond the org baseline, a Codex sandbox_mode set to danger-full-access, or a Copilot policy exception.
3. New or changed MCP servers, and what credentials or hosts they reach.
4. Any use of bypass modes, especially Codex --dangerously-bypass-approvals-and-sandbox or editor auto-run, on endpoints that hold real credentials.
5. Unvetted skills, plugins, hooks, and CLIs that extend an assistant's reach without review.

Each of these is a known incident path. A malicious project file can drive token exfiltration through a coding agent, as documented in the Claude Code project-file RCE and token-exfil analysis of CVE-2025-59536. The point of the scheduled check is to catch the change before it is the thing your incident review is about.

How does Anomity govern all three at once?

Anomity sits on the endpoint and treats the whole coding-assistant stack as inventory, not as three separate vendor problems. It enumerates eight artifact types per managed endpoint, AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs, then classifies them, so the fleet inventory you need for step one is the thing you already have. That covers Claude Code, Codex, and Copilot together, plus everything wired to them.

On agents that expose a hook, such as Claude Code's PreToolUse, Anomity returns an allow, deny, or log decision on each tool call before it runs, which is the runtime governance gate applied where a real gate exists. Where a tool has no per-action hook, like Copilot inline completion, governance stays where the tool allows it: visibility into what is installed and configured, and alerts when posture drifts. Anomity collects metadata only, with secret redaction happening on the endpoint, so the audit data does not become a new exposure.

The third piece closes the audit gap that local Claude Code and Codex sessions leave open. Anomity keeps a queryable 90-day audit trail of what each assistant did, and routes decisions to SIEM, Slack, email, or Jira, so the incident reviewer asking what ran on a given laptop last quarter gets one answer across all three tools, not a per-tool scavenger hunt. See the audit-trail outcomes and how it works end to end. Anomity complements your Network, EDR, DLP, and GRC tooling rather than replacing it; it covers the agentic layer those tools were never built to see.

Governing AI coding assistants does not require picking a winner among Claude Code, Codex, and Copilot. It requires one framework, inventory, classify, set policy, enforce where a gate exists, and audit, applied to all of them at once. If you want the broader policy scaffolding to build that program on, start with the agentic AI governance guide, or request access to see your own fleet at early access.