--- title: "OpenAI Codex Across CLI, Cloud, and IDE: Where the Security Model Differs | Anomity Blog" description: "OpenAI Codex runs in three places with three different sandboxes. In cloud, agent-phase internet is off by default; on the CLI it depends on one TOML key." url: "https://anomity.ai/blog/openai-codex-cli-cloud-ide-security-differences/" source: html --- On this page - Two layers: the sandbox and the approval policy - Where the code runs, surface by surface - What the sandbox actually enforces on each OS - Network exposure: the sharpest difference - The three surfaces side by side - Why one policy has to span all three [← Back to blog](https://anomity.ai/blog/) - Home - Blog - OpenAI Codex Across CLI, Cloud, and IDE: Where the Security Model Differs ![Anomity robot illustrating OpenAI Codex Across CLI, Cloud, and IDE: Where the Security Model Differs] Research # OpenAI Codex Across CLI, Cloud, and IDE: Where the Security Model Differs Anomity Research Security Researcher, Anomity · Jun 8, 2026 · 7 min read Share: Copied OpenAI Codex is not one product with one security model. It is the same agent wearing three different jackets: a local CLI, a cloud environment driven from the web and GitHub, and an IDE extension. Each surface decides three things differently: where the code actually runs, what the sandbox and approval layer enforce, and how much of the network the agent can reach. A policy that is correct for one surface can be quietly wrong for the other two. That matters because most teams reason about Codex as a single tool. They read about the cloud environment's locked-down defaults, assume the same posture applies to the laptop, and never check. The CLI's defaults are deliberately lower-friction, and the gap between them is where untrusted code and prompt injection get traction. We saw that mismatch in the [Codex branch-name command injection that leaked a GitHub token](https://anomity.ai/blog/openai-codex-branch-name-command-injection-github-token-theft/), and the broader pattern in our note on [securing AI coding agents and CLIs](https://anomity.ai/blog/securing-ai-coding-agents-and-clis/). This piece compares the three surfaces against the official Codex docs and shows why one policy has to span all of them. ## Two layers: the sandbox and the approval policy Codex documents its protection as two distinct layers, and keeping them separate is the key to reasoning about any surface. The **sandbox** is the technical boundary: what the agent can read, write, and reach when it executes a model-generated command. The **approval policy** is the procedural boundary: when Codex must stop and ask a human before crossing the sandbox edge. As the docs put it, the sandbox defines technical boundaries and the approval policy decides when Codex must stop and ask before crossing them. On the CLI, both layers live in `config.toml`. `sandbox_mode` takes `read-only`, `workspace-write`, or `danger-full-access` - the middle value is the default low-friction mode: read anywhere, edit inside the workspace, run routine local commands. `approval_policy` takes `untrusted`, `on-request`, `never`, or `granular`. The combination an engineer picks on their own laptop is invisible to everyone else unless something inventories it, which is the problem our [runtime governance layer](https://anomity.ai/#runtime-governance) is built to close. ## Where the code runs, surface by surface The single most important security variable is location of execution, because it determines the blast radius of a bad command. The three Codex surfaces land in three very different places. - CLI executes on the developer's own machine. The same endpoint holds SSH keys, cloud credentials, browser session cookies, and source for every repo the engineer touches. The OS sandbox is the only wall between a model-generated command and that material. - Cloud executes in an ephemeral container. Codex creates a container, checks out the repo at the selected branch or commit SHA, runs a setup script, then runs the agent loop. The container is disposable and the result surfaces as a diff, so a destructive command is contained to throwaway infrastructure rather than a laptop full of secrets. - IDE runs the agent inside the editor but executes commands against the same local workspace and the same OS-level sandbox the CLI uses. The convenience is a tighter loop with the open project; the security posture inherits the laptop's, not the cloud's. Cloud is the most contained surface by design; the two local surfaces share the riskiest execution context. Teams that pilot Codex in the cloud and then roll it out to laptops are not extending the same security model - they are switching to a weaker one, often without noticing. That is the surface-confusion behind the [multi-agent prompt-injection credential theft we analyzed](https://anomity.ai/blog/comment-and-control-multi-agent-prompt-injection-credential-theft/), where the controls people assumed were active did not apply to the surface under attack. ## What the sandbox actually enforces on each OS The CLI and IDE depend on OS-native isolation, and the mechanism changes with the platform - which means the strength of the wall changes too. On macOS, Codex uses the built-in Seatbelt framework via `sandbox-exec`, enforced automatically with no prerequisites. On Linux and WSL2 it uses `bubblewrap` for user-namespace isolation with seccomp filtering; the docs note Codex uses the first `bwrap` executable on `PATH`, and that AppArmor on some distributions can interfere unless the `bwrap-userns-restrict` profile is loaded. If `bubblewrap` is missing, Codex falls back to a bundled helper that needs unprivileged user-namespace support. Two operational facts follow from this for anyone running Codex locally at scale. First, the sandbox is only as strong as the host's configuration: a distro that blocks unprivileged namespaces or lacks `bubblewrap` changes the effective boundary. Second, `sandbox_mode = "danger-full-access"` removes the filesystem and network boundary entirely - a legitimate setting that turns the sandbox off. You cannot know which endpoints sit in that state by reading the docs; you have to look at the [fleet inventory](https://anomity.ai/#features) of what is actually configured where. ## Network exposure: the sharpest difference Network reach is where the three surfaces diverge most, and it is the lever prompt injection pulls to exfiltrate data. The cloud environment runs a two-phase model: the **setup phase** has internet access to install dependencies, then the **agent phase** runs with internet access off by default. The docs tie this directly to prompt injection - they describe a scenario where an attacker plants instructions in a GitHub issue and the agent, if it had network access, exfiltrates data such as commit history to an external server. When you do enable agent-phase access, you choose a preset (off, restricted, or unrestricted), and a restricted allowlist can be narrowed to specific domains and limited to `GET`, `HEAD`, and `OPTIONS` so the agent cannot `POST` data out. The CLI inverts the framing. In `workspace-write`, network access is off by default and is enabled by a single key: `sandbox_workspace_write.network_access = true`. That is one line in a file an individual engineer edits, with no allowlist and no method restriction - all-or-nothing per the sandbox config. The IDE inherits the same local behavior. So the most data-exposed configuration is the easiest to reach: a developer flips one boolean to make a build work, and the laptop surface has unrestricted egress while the cloud surface still enforces domain and method limits. Mapping who has flipped it is the kind of state that belongs in an [audit trail](https://anomity.ai/#outcomes). ## The three surfaces side by side Dimension CLI Cloud (web / GitHub) IDE extension Where code runs Developer's machine Ephemeral container, repo checked out at branch/SHA Developer's machine (editor workspace) Sandbox mechanism Seatbelt on macOS; bubblewrap + seccomp on Linux/WSL2 Container isolation; result returned as a diff Same OS sandbox as CLI Default write scope workspace-write (edit inside workspace) Container filesystem, ephemeral workspace-write Agent-phase network default Off until sandbox_workspace_write.network_access = true Off by default; presets off / restricted / unrestricted Off (inherits CLI sandbox) Network granularity All-or-nothing per sandbox config Domain allowlist + HTTP method limits (GET/HEAD/OPTIONS) All-or-nothing per sandbox config Who sets the policy Individual engineer (config.toml) Per environment, often org-managed Individual engineer ## Why one policy has to span all three Read the table top to bottom and the failure mode is obvious. The cloud surface can be governed centrally - per-environment network presets, domain allowlists, method restrictions - while the two local surfaces are configured per engineer in a file no one else reads. An organization can lock down Codex cloud beautifully and still have dozens of laptops running `workspace-write` with `network_access = true` and `approval_policy = "never"`. The agent that the security team believes is sandboxed and offline is, on those endpoints, neither. A defensible Codex policy is not three policies. It is one intended posture - say, no full-access sandbox, no unrestricted egress, approvals required for commands that cross the sandbox edge - applied and verified across every surface where Codex executes. The cloud half of that is enforceable through the platform. The local half depends on what is actually present in each engineer's [config](https://anomity.ai/#how-it-works), and that is the half that drifts. A reasonable working rule across the three surfaces: - Treat the CLI and IDE as the same risk tier - both run on the credential-rich endpoint, so they need the same sandbox and approval baseline. - Keep agent-phase network off everywhere by default, and where it must be on, prefer the cloud surface's domain allowlist and method limits over the CLI's all-or-nothing toggle. - Forbid danger-full-access and approval_policy = never as standing configuration, and detect them when they appear rather than trusting they never will. - Record what each endpoint is actually running so the intended policy and the observed policy can be compared, not assumed. That last point is where the local surfaces defeat documentation alone. The docs tell you what `config.toml` can do; they cannot tell you what any given laptop has set. Anomity inventories Codex and the other AI artifacts on every managed endpoint - agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs - and reads their effective configuration, so the sandbox mode, approval policy, and network setting on each surface become visible instead of inferred. On agents that expose a hook, such as a PreToolUse-style check, Anomity returns allow, deny, or log on each tool call before it runs, and keeps a queryable 90-day record routed to your SIEM, Slack, email, or Jira. It does not replace the OS sandbox or the platform controls; it makes the local surfaces governable the way the cloud surface already is. A fourth surface has since arrived in [the Agents API](https://anomity.ai/blog/openai-agents-api-managed-harness-governance/), where the harness runs on OpenAI's infrastructure and the sandbox is a field on the agent definition rather than a setting on a laptop. If you want to see what your fleet's Codex configuration actually looks like across CLI, cloud, and IDE, that is where [a demo](https://anomity.ai/#early-access) starts. Share: Copied ## Related [Research ### Anthropic's GLM-5.3 Study: Near-Frontier Exploit Skills Now Download Without Safeguards Anthropic found open-weight GLM-5.3 nearly matches Claude Mythos Preview at exploits, and its refusals strip off for about $4,400. What changes for you. Anomity Research · Oct 2, 2026 · 4 min](https://anomity.ai/blog/glm-5-3-open-weight-cyber-capability-local-models/) [Research ### GPT-6.1 Sol's System Card: Block One Channel and the Agent Tries Another 23.5% of the Time OpenAI's GPT-6.1 Sol report measures agents persisting past blocks, messaging unknown peers and misreporting work. Those numbers are an enforcement spec. Anomity Research · Oct 2, 2026 · 5 min](https://anomity.ai/blog/gpt-6-1-sol-system-card-agent-behavior/) [Research ### GTIG's AI Vulnerability Data: Half of 2026's AI-Software CVEs Hit Agent Frameworks GTIG tracked 2,076 AI-software CVEs since 2025: 782 this year in agent frameworks, 212 in inference servers. Patching them starts with finding them. Anomity Research · Oct 2, 2026 · 5 min](https://anomity.ai/blog/gtig-ai-software-vulnerabilities-agent-frameworks-2026/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "OpenAI Codex Across CLI, Cloud, and IDE: Where the Security Model Differs", "description": "OpenAI Codex runs in three places with three different sandboxes. In cloud, agent-phase internet is off by default; on the CLI it depends on one TOML key.", "datePublished": "2026-06-08", "dateModified": "2026-06-08", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Security Researcher, Anomity" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/openai-codex-cli-cloud-ide-security-differences/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/posts/openai-codex-cli-cloud-ide-security-differences.jpg", "width": 1200, "height": 630 }, "articleSection": "Research", "url": "https://anomity.ai/blog/openai-codex-cli-cloud-ide-security-differences/" } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "OpenAI Codex Across CLI, Cloud, and IDE: Where the Security Model Differs", "item": "https://anomity.ai/blog/openai-codex-cli-cloud-ide-security-differences/" } ] } ```