TL;DR: Cursor and Codex have converged on the same architecture: an OS-level sandbox plus a classifier that decides which remaining actions need approval. They differ most in defaults and failure behavior. Codex ships stricter network defaults and starts read-only in unversioned folders; Cursor's Linux sandbox has a hard kernel requirement and falls back to prompting when it is not met. Both vendors state in their own documentation that the classifier is not a security boundary.
Comparisons of these two tools usually go wrong in the same way: they compare a product's marketing surface against another's technical documentation, or they treat model-level safety work as though it were product security. This page does neither. Every row below traces to vendor documentation read in September 2026, and the two categories are kept separate.
One terminology note that causes real confusion. "Codex Security" is a separate OpenAI product, an application security agent that scans repositories for vulnerabilities. It is not the security model of Codex the coding agent, which is documented under agent approvals and security. Comparing Cursor's security posture to the Codex Security product is a category error, and it appears in a surprising number of published comparisons.
Table of Contents
- What Is AI Coding Agent Security?
- The Comparison Matrix
- Execution Environment and Sandbox
- Approval Models: Two Axes vs Three Modes
- Where Both Vendors Disclaim Their Own Classifier
- Network Defaults
- Credentials and Secrets
- Enterprise Administration and Compliance
- How to Choose
- Frequently Asked Questions
What Is AI Coding Agent Security?
AI coding agent security is the set of controls that decide what an agent may execute on a machine or in a hosted environment: where it can write, what it can read, which network destinations it can reach, and which actions require a human decision before they run. It is enforced at the moment of a tool call, which distinguishes it from code scanning, which runs on the output afterward.
For both products the architecture has the same two layers, whatever each vendor calls them:
- An isolation layer, enforced by operating system primitives, deciding what an action can reach once it runs.
- An approval layer, deciding which actions run without asking, which go to a classifier, and which stop for a human.
Reading either product's controls as a single autonomy slider loses the distinction, and it is the distinction that determines how each one fails.
Both layers share a property worth naming up front, because it shapes every row of the comparison below: each one evaluates a single action, in a single session. Runtime control infrastructure like Gensee Crate addresses the layer neither vendor is building, where effects are correlated across sessions rather than approved within one.
The Comparison Matrix
Verified against vendor documentation, September 2026. Cursor's security page carries its own date stamp of August 25, 2026.
| Cursor | Codex | |
|---|---|---|
| Autonomy control | Three Run Modes: Auto-review, Allowlist, Run Everything | Two axes: sandbox mode (read-only, workspace-write, danger-full-access) × approval policy (untrusted, on-failure, on-request, never, granular) |
| Default posture | Terminal commands require approval; file reads and code search do not | Version-controlled folder → Auto (workspace-write + on-request). Non-version-controlled → read-only |
| macOS sandbox | Seatbelt via sandbox-exec, generated profile, full subprocess tree |
Seatbelt via sandbox-exec with a per-mode profile |
| Linux sandbox | Landlock + seccomp. Requires kernel 6.2+ with Landlock v3 and unprivileged user namespaces | bwrap + seccomp |
| Linux fallback | Falls back to asking for approval if the kernel does not qualify | Sandbox may fail under Docker where namespace, setuid bwrap or seccomp operations are blocked |
| Windows | Desktop app; sandbox documented for macOS and Linux | WSL2 uses the Linux sandbox (WSL1 unsupported from 0.115); native Windows has its own sandbox with unelevated / elevated modes |
| Network default | Blocked by default for sandboxed commands, opened by network mode and sandbox.json |
No network access by default in CLI/IDE. Cloud: setup phase online, agent phase offline by default |
| Protected paths | .git/config, .git/hooks, .vscode, .cursorignore, Cursor config files |
.git (incl. pointer files and resolved gitdir), .agents, .codex, recursive |
| Config files | permissions.json (what runs) and sandbox.json (what it reaches), user + project, merged |
config.toml, with profile files such as full_auto.config.toml |
| Team override | Team dashboard config takes priority and Cursor ignores user- and project-level files | Managed configuration documented separately |
| MCP | Every connection requires approval; each tool call also requires individual approval unless pre-approved via MCP allowlist | Destructive app/MCP calls always require approval when the tool advertises a destructive annotation |
| Classifier model | Cursor-managed: Claude 4.5 Haiku or GPT-5.4 Mini | Safety monitoring on GPT-6 Astra, asynchronous |
| Certifications | AIUC-1, ISO/IEC 27001:2022, ISO/IEC 42001:2023, SOC 2 Type II | Available through OpenAI's trust documentation |
| Telemetry | Compliance logging documented for enterprise | OpenTelemetry, opt-in |
Execution Environment and Sandbox
Both use the same OS primitives on macOS and comparable ones on Linux, so raw isolation strength is broadly similar. The differences that matter operationally are in requirements and failure behavior.
Cursor's Linux requirement is strict and specific: kernel 6.2 or later with Landlock v3 support (CONFIG_SECURITY_LANDLOCK=y) and unprivileged user namespaces enabled. If the kernel does not meet this, Cursor falls back to asking for approval before running commands. That is a fail-closed behavior, and it is the right choice, but on older enterprise Linux images it means the sandbox many teams believe they have is not running. Remote environments and the standalone CLI also need an AppArmor profile that the desktop package ships but they do not.
Codex's gap is containerized Linux. OpenAI documents that under Docker the sandbox may not work where the host or container blocks the namespace, setuid bwrap or seccomp operations Codex needs, and its guidance in that case is to isolate at the container level and run --sandbox danger-full-access inside it. That is coherent advice, and it relocates the boundary from the agent to your container configuration, where it becomes your responsibility rather than the vendor's.
Codex's cloud model is the strongest isolation either product offers, and it is worth calling out specifically. Cloud sessions run in isolated OpenAI-managed containers on a two-phase runtime: setup runs first and can reach the network to install dependencies, then the agent phase runs offline by default. Secrets configured for cloud environments are available only during setup and are removed before the agent phase starts. A secret that is not present cannot be exfiltrated, which is a structurally different guarantee from a secret that is present but policy-protected.
Approval Models: Two Axes vs Three Modes
The most common error in published comparisons is treating Codex's controls as an autonomy ladder. They are two independent settings.
Codex combines a sandbox mode with an approval policy. --sandbox workspace-write --ask-for-approval on-request is the Auto preset; --ask-for-approval never works with all sandbox modes, so you can have zero prompts while still being confined to the workspace. A granular approval policy keeps specific prompt categories interactive while automatically rejecting others, covering sandbox approvals, execpolicy-rule prompts, MCP prompts, request_permissions prompts and skill-script approvals. Removing both layers requires --sandbox danger-full-access or --dangerously-bypass-approvals-and-sandbox.
Cursor presents three Run Modes, with sandboxing as a separate layer on top:
| Mode | Runs without asking | Sandbox | Classifier |
|---|---|---|---|
| Auto-review | Allowlisted calls; other shell commands sandboxed when possible; the rest to the classifier | Yes, shell | Yes |
| Allowlist | Allowlisted actions only | Optional, shell | No |
| Run Everything | Every tool call | No | No |
Cursor's policy input is unusual and worth noting for anyone writing enterprise standards: permissions.json takes plain-English sentences in allow_instructions and block_instructions, not patterns or globs. "Every AWS CLI command should go through approval first" is the literal configuration format. That is genuinely easier to author and genuinely harder to audit, because the policy's meaning depends on a model's reading of it.
Where Both Vendors Disclaim Their Own Classifier
This is the most useful thing either set of documentation says, and it is easy to miss because both vendors say it quietly.
Cursor's Run Modes page carries a heading reading "Auto-review is not a security boundary", and states that the classifier "can make mistakes. It can allow a call you would have blocked, or block a call you would have allowed." Run Modes overall are described as "best-effort guardrails rather than a hard security boundary."
Codex's safety monitoring documentation states that monitoring runs asynchronously and can pause a task if it detects potentially unsafe model behavior, that "a pause can arrive after the activity that triggered it," and that monitoring "doesn't replace sandboxing, permissions, or review of the result." There is an important operational footnote: on Codex CLI and mobile, full findings and resume are not available, so a paused task simply ends. The same applies under zero data retention, Modified Abuse Monitoring, or non-US data residency.
Read together, both vendors are telling you the same thing. The classifier reduces prompt fatigue. The sandbox is the boundary. And a monitor that can only pause a task after the triggering activity is a detection control, not a prevention one.
That is the seam runtime control infrastructure like Gensee Crate is built for: a layer that observes effects as they occur rather than judging intentions before they run, and that keeps its record when a task ends without one. Gensee's trace analysis of eight autonomous agent runs is a concrete study of why that distinction matters, showing that what exposed two boundary crossings was service semantics, independent evidence and persistence rather than the volume of activity.
Network Defaults
Both default to no network for sandboxed execution, which is stricter than most teams expect and worth verifying before assuming otherwise.
Cursor blocks network by default for sandboxed terminal commands, opened by network mode and sandbox.json. Separately, Cursor documents that its first-party tools only make network requests to GitHub, direct link retrieval and web search providers, and that agents cannot make arbitrary network requests with default settings.
Codex defaults to no network access in the CLI and IDE extension, and requires approval to run commands that need network. In cloud environments the agent phase is offline by default unless internet access is enabled for that environment.
The difference appears in what widens it. Cursor's sandbox.json merges user and project files, with project-level taking priority, but team-admin policies and Cursor's hardcoded rules layer on top so local files cannot weaken those protections. That last clause is a meaningful enterprise guarantee and Codex documents no exact equivalent.
Credentials and Secrets
Neither product's local sandbox ships a credential deny list comparable to a managed secret store, and both rely on the workspace boundary to do most of the work.
Cursor's .cursorignore blocks agent access to specific files, and its sandbox protects Cursor's own config alongside .git/config and .git/hooks. Codex protects .git, .agents and .codex recursively inside writable roots. In both cases, a credential file living outside the workspace is outside the write boundary; whether it is outside the read boundary depends on configuration.
Codex's cloud secret handling is the notable exception and the strongest pattern either vendor documents: secrets exist during setup and are removed before the agent phase begins. It is worth understanding as a design principle rather than a feature, because it is the only mechanism here that removes the credential rather than guarding it. Gensee's AP-004 credential harvesting pattern explains why that matters: agents reach credentials through ordinary debugging and deployment work, not through obviously suspicious steps, and a guard that must judge each step is being asked the harder question.
Enterprise Administration and Compliance
Cursor publishes the more complete compliance surface. Its security page, dated August 25, 2026, lists AIUC-1, ISO/IEC 27001:2022 and ISO/IEC 42001:2023 certifications plus a SOC 2 Type II attestation, with certificates available through its trust portal, and commits to at-least-annual third-party penetration testing. It also states that it does not use or maintain infrastructure in China and uses no China-headquartered subprocessors, which is a specific claim some regulated buyers ask for directly.
Two administrative details are decision-relevant:
- Cursor's team configuration overrides local files entirely. When a team Auto-review configuration is defined, it takes priority and Cursor ignores the user-level and project-level files. That is cleaner than a merge for policy enforcement.
- Cursor's classifier depends on model access controls. Auto-review runs on Claude 4.5 Haiku or GPT-5.4 Mini. If an enterprise blocks both under model access control, Auto-review is disabled and members fall back to Allowlist. A model governance decision silently changes the security posture, which is the kind of interaction worth catching before rollout rather than after.
Codex's OpenTelemetry support is opt-in, which means audit evidence is a deployment step rather than a default.
How to Choose
Neither product is categorically more secure. The decision turns on your environment:
- Older enterprise Linux images: Cursor's kernel 6.2 requirement is a hard gate. Verify it before assuming sandboxing is active.
- Containerized CI: Codex documents that the sandbox may not function under Docker, pushing isolation to your container config. Plan that boundary deliberately.
- Regulated procurement: Cursor's published certification set and subprocessor claims are more complete today.
- Strongest isolation available: Codex cloud's two-phase model with secrets removed before the agent phase.
- Centralized policy enforcement: Cursor's team configuration overriding local files is the cleaner mechanism.
For the general, tool-agnostic version of this evaluation, Gensee's 15 questions to answer before deploying AI coding agents covers the ground that a two-product comparison necessarily leaves out.
Frequently Asked Questions
Is Cursor or Codex more secure?
Neither, categorically. Both use comparable OS-level sandboxing and both ship a classifier that each vendor explicitly declines to call a security boundary. The practical differences are in defaults, platform requirements and failure behavior: Cursor's Linux sandbox needs kernel 6.2+ and falls back to prompting otherwise, while Codex's may not function under Docker.
What is the difference between Codex and Codex Security?
Codex is the coding agent; its security model is documented under agent approvals and security. Codex Security is a separate product, an application security agent that scans repositories for vulnerabilities. Comparisons that treat the second as the first are comparing a scanner to an agent runtime.
Do Cursor and Codex block network access by default?
Yes, both, for sandboxed execution. Cursor blocks network by default for sandboxed terminal commands. Codex defaults to no network access in the CLI and IDE extension, and in cloud environments the agent phase runs offline by default after an online setup phase.
Can a developer override our organization's Cursor policy?
For Auto-review configuration, no: when a team configuration is defined in the dashboard it takes priority and Cursor ignores user-level and project-level permissions.json files. For sandbox.json, local files merge, but team-admin policies and Cursor's hardcoded security rules layer on top so local files cannot weaken those protections.
Does either tool track risk across sessions?
Neither documents a mechanism that carries a judgment from one session into the next. Gensee's multi-session agent safety research covers the failure modes that live in that gap. Both evaluate the action in front of them against policy set beforehand. Risk that accumulates across sessions is a different problem, and it needs a control that observes effects over time.
Conclusion
The two products have converged more than they have diverged. Both isolate at the OS level, both interpose a classifier, and both are candid that the classifier is not the boundary. Choose on environment fit, platform requirements and administrative model, not on a feature count.
What neither addresses is what happens across sessions, because neither is designed to. Gensee Crate records effects independently of the agent that produced them and carries that record past the session boundary. To discuss it, book a demo or see pricing.