Agentic Coding Model Governance: Operator Guide to Claude Code, Codex, ZCode, and Cursor Enterprise Controls
AI coding agents now read your codebase, execute commands, and push code — all with varying levels of operator control. We compared the governance surfaces of Claude Code, OpenAI Codex, ZCode (GLM-5.2), and Cursor Enterprise so you can enforce the right sandbox, permission, and audit policies before your agents ship their first PR.
Your AI coding agents have more autonomy than most junior engineers. They read entire codebases, execute arbitrary shell commands, call external APIs, and push commits — sometimes across hundreds of files in a single session. The governance question for engineering leaders in mid-2026 is no longer "which model is fastest" but "who controls what the agent can do, and how do we prove it?"
This guide compares the operator-facing governance controls of four major agentic coding platforms — Claude Code, OpenAI Codex, ZCode (GLM-5.2), and Cursor Enterprise — and walks through the minimum viable governance setup for each. Whether you're a platform engineering lead evaluating these agents for a 500-person org or a solo operator running all four behind a routing gateway, this post gives you the checklist.
OpenAI-compatible means a provider exposes a chat-completions endpoint whose request and response shape matches the OpenAI API contract closely enough that an unmodified OpenAI SDK call works against it after swapping three values: API key, base URL, and model name. The minimum surface in practice is POST /v1/chat/completions with messages, model, and an OpenAI-shaped streaming response.
TL;DR — Governance Controls at a Glance
| Control | Claude Code | OpenAI Codex | ZCode (GLM-5.2) | Cursor Enterprise |
|---|---|---|---|---|
| Sandbox type | Seatbelt (macOS) / bubblewrap (Linux) | Cloud microVM (Linux), ACL sandbox (Windows) | Confirmation prompts per command | IDE-level Privacy Mode |
| Filesystem isolation | Write-restricted to working dir + session temp | Container-scoped; write to workspace only | Agent-level file-change approval | Workspace-scoped by default |
| Network isolation | Domain allowlist with proxy enforcement | Internet disabled by default; domain allowlist | No built-in network sandbox | No documented network sandbox |
| Permission model | Deny → Ask → Allow rules; managed settings | Full Access / Suggest / Auto modes | Per-action confirmation dialogs | Global model/MCP/rules config |
| Managed policy distribution | Admin console, MDM, policy helper, settings files | Organization-level Codex policies | Not documented | Admin console (SSO/SCIM) |
| Audit logging | Analytics dashboard, monitoring API, SIEM export | Task-level audit trail, API logs | Not documented | SOC 2 Type II; zero data retention |
| Approval workflows | PreToolUse hooks; /permissions CLI | PR-based review (agent creates branch) | Per-action approval in UI | BugBot PR review (agent-side) |
| Compliance certs | SOC 2; HIPAA BAA (Enterprise) | SOC 2; data not used for training | None documented | SOC 2 Type II; GDPR/CCPA |
Step 1: Define Sandbox Isolation Per Agent
The sandbox is your first line of defense. It determines what the agent's shell commands can touch on the host filesystem and network. Each platform approaches this differently.
Claude Code: OS-Level Sandbox
Claude Code provides the most granular sandbox of the four platforms. On macOS, it uses Apple's Seatbelt framework to restrict every Bash command and its child processes. On Linux and WSL2, it uses bubblewrap with an optional seccomp filter.
Key operator controls:
sandbox.enabled— enforce sandboxing across all projects (user settings) or organization-wide (managed settings)sandbox.failIfUnavailable— hard-fail if sandbox dependencies are missing, instead of falling back to unsandboxed executionsandbox.filesystem.disabled— block all filesystem writes outside explicitly allowed paths (added in v2.1.216, July 2026)- Network domain allowlist — Claude Code proxies all outbound connections through a sandbox proxy; new domains require explicit approval
allowUnsandboxedCommands— control whether commands that fail under sandbox constraints can fall back to unsandboxed execution
// Managed settings (admin console or MDM)
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false
},
"permissions": {
"deny": ["Bash(curl *)", "Bash(wget *)"],
"allow": ["Bash(git *)"]
}
}
Git isolation (v2.1.215–216): Claude Code now creates isolated git worktrees for agent sessions, preventing the agent from modifying the developer's working checkout directly. This addresses a class of issues where agent-initiated commits could corrupt in-progress work.
OpenAI Codex: Cloud MicroVM
Codex takes a fundamentally different approach: every coding task runs inside a cloud-hosted microVM (on Linux) or a custom ACL-based sandbox on Windows. The agent never runs commands directly on the developer's machine.
Key operator controls:
- Internet access disabled by default — Codex tasks run with no network access unless the operator configures a domain allowlist
- Workspace-scoped writes — the microVM mounts a read-only snapshot of the repository, with write access only to the workspace directory
- Execution modes — Full Access (no restrictions), Suggest (requires approval), and Auto (sandboxed automatic execution)
- PR-based output — all agent changes are committed to a branch and surfaced as a pull request for human review
# Codex task with restricted network access
from openai import OpenAI
client = OpenAI()
task = client.codex.tasks.create(
model="codex",
prompt="Fix the failing test in auth_service.py",
sandbox={
"internet_access": False,
"allowed_domains": ["pypi.org"]
}
)
Multi-agent v2: Codex now supports multi-agent workflows where a parent task can spawn child tasks, each running in its own isolated microVM. The operator can set per-task sandbox policies and domain allowlists.
ZCode (GLM-5.2): Confirmation-Based Control
ZCode is the youngest platform in this comparison, launched in July 2026 as Z.AI's agentic development environment built around GLM-5.2. Its governance model is simpler: every sensitive command, file change, and high-permission action requires explicit confirmation before execution.
Key operator controls:
- Per-action approval — the agent pauses before executing shell commands, modifying files, or performing Git operations
- No built-in OS-level sandbox — ZCode relies on confirmation dialogs rather than kernel-level isolation
- Desktop + Remote + Bot control — operators can monitor and approve actions from the desktop app, mobile Remote, or Feishu/WeChat bot channels
- GLM Coding Plan quotas — token-based usage limits with peak/off-peak coefficients
ZCode's governance surface is less mature than Claude Code or Codex. There are no documented managed settings, no MDM distribution, and no network-level isolation. For enterprise teams, this means wrapping ZCode in an additional infrastructure sandbox (Docker, VM, or network policy) if you need hard isolation guarantees.
Cursor Enterprise: IDE-Level Controls
Cursor approaches governance from the IDE side rather than the sandbox side. Its enterprise tier focuses on organizational controls — SSO, SCIM provisioning, zero data retention, and centralized model/MCP configuration.
Key operator controls:
- Privacy Mode — prevents code from being stored by Cursor or LLM providers
- Zero data retention — no training on customer code by Cursor or upstream providers
- Centralized model access — admins configure which frontier models (OpenAI, Anthropic, Gemini, SpaceXAI) developers can use
- MCP controls — global configuration of Model Context Protocol servers
- System-level agent rules — organization-wide rules for agent behavior
- BugBot — automated PR review agent that runs in the background on new pull requests
Cursor's governance is strong on identity and compliance (SOC 2 Type II, SAML SSO, SCIM, GDPR/CCPA) but thinner on runtime sandbox isolation compared to Claude Code or Codex. The agent executes within the IDE's process, with workspace-scoped file access but no documented OS-level sandbox or network allowlist enforcement.
Step 2: Set Permission Policies and Approval Workflows
Sandbox isolation constrains where the agent can act. Permission policies control what it can do within those boundaries.
Claude Code Permission System
Claude Code offers the most granular permission model through a three-tier rule system:
- Deny rules — block the agent from using a tool or matching a pattern entirely
- Ask rules — prompt for human confirmation before execution
- Allow rules — let the agent proceed without prompting
Rules are evaluated in strict precedence: deny → ask → allow. A deny rule always wins, even if a more specific allow rule matches the same call.
Managed settings distribution gives operators four delivery mechanisms, in priority order:
- Server-managed (claude.ai admin console or self-hosted Claude apps gateway)
- MDM-managed (macOS profiles, Windows registry, Linux config files)
- Policy helper (custom executable that computes settings at runtime)
- Enterprise settings file (
.claude/settings.enterprise.json)
// Organization-wide managed settings
{
"permissions": {
"deny": [
"Bash(rm -rf *)",
"Bash(sudo *)",
"Bash(docker run *)"
],
"ask": [
"Bash(git push *)",
"Bash(npm publish *)"
],
"allow": [
"Bash(git status)",
"Bash(git diff *)",
"Bash(npm test)"
]
}
}
PreToolUse hooks extend the permission system with custom logic. You can write a script that Claude Code calls before every tool invocation, returning allow, deny, or ask with a custom message.
Codex Execution Modes
Codex simplifies permissions into three modes:
- Suggest — the agent proposes every action and waits for approval
- Auto — sandboxed execution with automatic approval for safe operations
- Full Access — unrestricted execution (not recommended for production)
The output model is inherently safer for governance because all changes flow through a pull request. The agent cannot merge its own code.
Cursor Enterprise Admin Controls
Cursor provides global configuration at the organization level:
- Model access restrictions (which LLMs developers can use)
- MCP server allowlists (which external tools the agent can call)
- System-level agent rules (behavioral constraints applied to all sessions)
These are configured through the Cursor admin console, distributed via SAML SSO / SCIM provisioning.
Step 3: Enable Audit Logging and Usage Monitoring
Governance without visibility is policy without enforcement. Each platform offers different levels of audit trail.
| Platform | Audit Surface | Export Options |
|---|---|---|
| Claude Code | Analytics dashboard, per-session tool call logs, token usage, cost tracking | Monitoring API, SIEM integration (CrowdStrike Falcon, Splunk) |
| Codex | Task-level audit trail, command execution logs, API request logs | OpenAI API, organization dashboard |
| ZCode | Task execution history in desktop/Remote UI | Not documented; no API export |
| Cursor | SOC 2 audit trail, usage analytics | Admin console; no documented SIEM export |
Claude Code Monitoring Setup
Claude Code's monitoring and analytics surface is the most operator-friendly. You can:
- Track spend per team/project — the analytics dashboard breaks down token usage and cost by user, project, and time period
- Export to SIEM — CrowdStrike and Splunk integrations pull Claude Code audit events into your existing security monitoring pipeline
- Set spend alerts — configure budget thresholds at the workspace level with automatic notifications
Codex Audit Trail
Every Codex task produces an audit trail that includes:
- The original prompt and context
- Every command the agent executed (with output)
- All file reads and writes
- The final diff and commit message
- Task duration and token consumption
This audit trail is accessible via the Codex API and the OpenAI organization dashboard.
Step 4: Configure Gateway-Level Routing Policies
When you run multiple coding agents across your organization, a routing gateway gives you a single control plane for model access, rate limits, and fallback policies — regardless of which agent made the request.
TheRouter routes OpenAI-compatible requests through configured providers, which means any coding agent that uses the OpenAI SDK can be pointed at a gateway endpoint instead of directly at a provider. This lets you:
- Enforce per-team model access — route Team A's requests to Claude Opus 4, Team B's to Codex, and apply different rate limits to each
- Set fallback chains — if Anthropic's API returns a rate limit error, automatically fall back to a secondary provider
- Unify billing — track spend across all coding agents in one billing surface instead of managing separate provider accounts
- Apply request-level policies — log every request, block specific model IDs, or inject system prompts at the gateway level
// Example: routing coding agent requests through TheRouter
import OpenAI from "openai";
const client = new OpenAI({
baseUrl: "https://your-therouter-instance.example.com/v1",
apiKey: "your-therouter-key",
});
// Same SDK call works regardless of upstream provider
const response = await client.chat.completions.create({
model: "anthropic/claude-opus-4",
messages: [{ role: "user", content: "Refactor the auth module" }],
});
For details on model fallback configuration, see the model fallbacks guide.
Production Checklist: Minimum Viable Governance
Before deploying any coding agent to your engineering team, verify these controls are in place:
For Claude Code
- Enable
sandbox.enabled: truein managed settings - Set
sandbox.failIfUnavailable: trueto prevent unsandboxed fallback - Configure permission deny rules for destructive commands (
rm -rf,sudo,docker run) - Set up SAML SSO and SCIM provisioning
- Connect monitoring to your SIEM (CrowdStrike or Splunk)
- Configure spend alerts at the workspace level
- Review and lock
allowUnsandboxedCommands: false
For Codex
- Use Auto or Suggest mode — never deploy Full Access to production teams
- Configure domain allowlists for tasks that need network access
- Set organization-level Codex policies
- Require PR review for all agent-generated changes
- Monitor task audit trails via the OpenAI API
For ZCode
- Wrap ZCode in a container or VM for network/filesystem isolation
- Enable per-action approval for all sensitive operations
- Set GLM Coding Plan quotas to control spend
- Monitor task execution via desktop/Remote UI
- Consider supplementing with an external audit log solution
For Cursor Enterprise
- Enable Privacy Mode across the organization
- Configure SAML SSO and SCIM provisioning
- Set model access restrictions (which LLMs developers can use)
- Configure MCP server allowlists
- Enable BugBot for automated PR review
- Verify zero data retention policy with legal/compliance
Common Pitfalls and How to Avoid Them
Pitfall 1: Treating "sandbox" as a binary. Claude Code's sandbox and Codex's microVM are fundamentally different isolation models. One restricts processes on the host; the other runs processes in a separate VM. Evaluate which isolation model matches your threat model.
Pitfall 2: Ignoring network isolation. Filesystem sandboxing is necessary but not sufficient. An agent that can reach the internet can exfiltrate code, download malicious dependencies, or call unauthorized APIs. Always configure network allowlists alongside filesystem restrictions.
Pitfall 3: Deploying without audit trails. If you can't answer "what did the agent do in the last 24 hours," your governance is incomplete. Set up monitoring before granting agent access to production codebases.
Pitfall 4: One-size-fits-all policy. Different teams need different governance profiles. A security-critical backend team may need strict deny rules and mandatory PR review, while a frontend prototyping team may work better with auto-approve sandbox mode. Use per-team managed settings or gateway routing to differentiate.
What's Next: The Governance Gap
The biggest gap across all four platforms in mid-2026 is cross-agent governance standardization. Each platform has its own policy format, its own audit trail schema, and its own approach to isolation. There is no industry-standard way to define a "coding agent policy" that works across Claude Code, Codex, ZCode, and Cursor simultaneously.
For now, the practical answer is a routing gateway that sits in front of all your coding agents and applies uniform request-level policies — model access, rate limits, spend caps, and audit logging — regardless of which agent runtime is making the call.
We expect this gap to narrow as the Model Context Protocol evolves and as enterprise procurement drives vendor convergence on audit and policy standards.
Sources:
- Claude Code Admin Setup — retrieved 2026-07-23
- Claude Code Sandboxing — retrieved 2026-07-23
- Claude Code Permissions — retrieved 2026-07-23
- OpenAI: Building Codex Windows Sandbox — retrieved 2026-07-23
- ZCode Documentation — retrieved 2026-07-23
- Cursor Enterprise — retrieved 2026-07-23
- Anthropic: Claude Code on Team and Enterprise — retrieved 2026-07-06
- OpenAI: Introducing Codex — retrieved 2026-07-23