Codex Sandbox: Modes, Permissions, and Safe Configuration

For most local Codex development, use workspace-write with on-request. Codex can edit the current workspace and run routine commands, but it must ask before accessing the network or files outside that boundary.

The sandbox limits what a command can access. The approval policy controls when Codex asks you to authorize an action. Disabling approval prompts leaves sandbox restrictions intact; Full Access removes both.

These settings apply to the Codex CLI, IDE extension, and desktop app, not Codex cloud.

What the Codex sandbox protects

Codex runs local commands inside an operating-system-enforced boundary. OpenAI's sandbox documentation describes three modes:

The enforcement mechanism depends on the operating system. Codex uses Seatbelt profiles on macOS. On Linux and WSL it uses Bubblewrap and seccomp, with Landlock available on compatibility paths. Native Windows has its own sandbox implementations. OpenAI documents the current platform details and failure behavior in its permission-profile reference.

A sandbox controls local command execution. Connectors, MCP servers, the built-in browser, computer-use tools, and Codex cloud have separate controls. Review those surfaces independently instead of assuming a local filesystem rule covers them.

Sandbox modes and approval policies are separate

The common approval policies are:

• untrusted asks before commands outside Codex's trusted set.
• on-request lets Codex work inside the configured sandbox and ask when it needs to cross the boundary.
• never prevents approval prompts. Commands still remain inside the selected sandbox unless the sandbox mode also grants full access.

OpenAI recommends workspace-write with on-request: Codex can edit and test the current project, but writing elsewhere or reaching the internet requires approval. See the overview of sandbox defaults for the current combinations.

In the CLI, /permissions opens the active permissions picker. The IDE extension and desktop app expose the same choice under the composer. Use those controls for a session-level change. Put stable defaults in configuration.

Configure a safe default in config.toml

Add the following to ~/.codex/config.toml for a user-wide default:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

The equivalent CLI flags are:

codex --sandbox workspace-write --ask-for-approval on-request

Codex also reads trusted project settings from .codex/config.toml. CLI flags have the highest precedence, followed by project configuration, a selected profile, user configuration, and system defaults. Codex skips project-scoped configuration when you mark a repository as untrusted. The official configuration guide lists the full precedence order.

Keep the project boundary narrow. If a build needs to write to another directory, add that path as a writable root instead of removing the sandbox:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
writable_roots = ["/absolute/path/to/shared-build-cache"]

Codex can keep writing to every configured root until you remove it. Check whether a cache, generated-code directory, or sibling repository can run scripts later with more privilege. A narrow path created for one task is safer than the whole home directory.

Use permission profiles for tighter file and network rules

Beta permission profiles define read, write, and deny rules for local files and outbound destinations. OpenAI says they are under active development and may change. They do not compose with the older sandbox settings: configure either default_permissions and [permissions], or sandbox_mode and sandbox_workspace_write, but not both. The permissions documentation covers profile syntax and platform caveats.

For example, a profile can keep the workspace writable while denying reads of environment files:

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"

Broader entries do not override a specific deny. Codex resolves matching paths with deny ahead of write, and write ahead of read. Test glob behavior on the operating systems your team supports, because Linux, WSL, and native Windows may need bounded expansion for unbounded deny globs.

Allow only the domains a task needs. An allowed destination can still receive any data the command is permitted to read. Local services and private network targets are blocked by default in permission profiles; opening localhost, a private IP, or a Unix socket exposes another surface on your machine.

Do not rely on network restrictions alone to protect secrets. If a command can read a credential and reach an approved host, that host may receive the credential. Deny reads of .env, SSH keys, cloud credentials, and other secret-bearing files that the task does not need. Use short-lived, scoped credentials for the ones it does.

What "disable Codex sandbox" does

danger-full-access removes the filesystem and network restrictions from local command execution. Combined with approval_policy = "never", it is Full Access:

sandbox_mode = "danger-full-access"
approval_policy = "never"

That configuration lets Codex run commands with the access available to your user account and without stopping for approval. A malicious package script, prompt injection, or mistaken command can then read, change, or send anything your account can reach.

When the sandbox blocks a required operation, grant the narrowest exception that solves it:

• add one required writable root;
• allow a specific network destination;
• approve one command when Codex requests escalation;
• create a rule for a known command prefix;
• run the full-access session inside a disposable VM or microVM.

Rules can allow, prompt, or forbid command prefixes outside the normal boundary. They are a better fit for a repeatable exception than expanding access for every command. OpenAI documents their syntax and matching behavior in the Codex rules guide.

Codex sandbox on Windows

Native Windows supports two Codex sandbox implementations:

[windows]
sandbox = "elevated" # or "unelevated"

Use elevated when your machine and organization permit its setup. It creates dedicated lower-privilege sandbox users and uses filesystem permission boundaries plus firewall rules. Setup requires administrator approval, but commands then run under the restricted sandbox identity.

The unelevated fallback derives a restricted token from your current Windows user and applies ACL-based filesystem boundaries. Its offline controls rely on the environment instead of a firewall rule tied to a dedicated user, so OpenAI describes its network isolation as weaker. The Windows sandbox guide recommends elevated when both modes are available.

WSL uses the Linux sandbox model. Choose it when your development workflow already runs inside WSL or when you need Linux-specific sandbox behavior. Native PowerShell users can stay in the Windows sandbox without putting the whole project in Windows Sandbox or a separate VM. OpenAI's engineering account explains why Codex uses restricted users, ACLs, and firewall rules rather than Microsoft's disposable Windows Sandbox product in Building a safe, effective sandbox to enable Codex on Windows.

When the local sandbox needs an outer boundary

The local sandbox limits commands, but it does not isolate the complete host. Use an outer container, VM, or microVM when:

• Codex runs unattended;
• the repository or its dependencies are untrusted;
• the agent needs Full Access for the task;
• multiple tenants run on shared infrastructure;
• you need to destroy the complete environment after each session.

An outer boundary contains the Codex process and its surrounding tools. Containers share the host kernel; VMs and microVMs provide a guest kernel. See our Docker sandboxing and microVM comparison for that choice and the microVM explainer for the mechanics.

Use the AI coding agent sandbox security checklist to compare managed and self-hosted options by isolation, egress, credential handling and persistence.

Claude Code uses different sandbox settings and boundaries; see the separate Claude Code sandbox guide.

How ainclave isolates Codex sessions

For unattended Codex work, ainclave runs the complete agent session in a dedicated Firecracker microVM with its own guest kernel. Deny-default egress is enforced on the host datapath outside the guest, and the destination set is derived from the selected configuration when the session is created. Users cannot edit that list yet.

Codex's sandbox can remain active inside the microVM: it restricts commands within the guest, while the microVM separates the session from the host and other sessions. See ainclave's microVM isolation architecture for the current controls and limitations.

Codex sandbox checklist

• Start with workspace-write and on-request.
• Keep the workspace as the default write boundary.
• Add narrow writable roots instead of the home directory.
• Deny reads of secrets the task does not need.
• Allow only required network destinations.
• Prefer a scoped rule or one approval over Full Access.
• Use the elevated native sandbox on Windows when available.
• Put unattended, untrusted, or multi-tenant sessions inside an outer isolation boundary.
• Test the resolved policy with a harmless read, write, and network request before relying on it.

Frequently asked questions

Does Codex have a sandbox mode?

Yes. Local Codex clients support read-only, workspace-write, and danger-full-access. The sandbox restricts local commands, while a separate approval policy decides when Codex asks before acting.

Which Codex sandbox mode should I use?

Use workspace-write with on-request for normal development. Use read-only for investigation or review. Reserve danger-full-access for a trusted, disposable outer environment where unrestricted command access is intentional.

How do I change Codex sandbox permissions?

Use /permissions in the CLI or the permissions control in the IDE and desktop app. Put lasting defaults in ~/.codex/config.toml, and use a trusted project's .codex/config.toml for project-specific settings.

Can I disable the Codex sandbox?

Yes. sandbox_mode = "danger-full-access" removes the sandbox restrictions. Pairing it with approval_policy = "never" gives Codex Full Access without prompts. Try a narrow writable root, domain allowance, or command rule first.

Does the Codex sandbox block network access?

Restricted modes can block or constrain outbound access, depending on the active configuration. An approved domain can still receive any readable data, so combine network rules with filesystem denies and scoped credentials.

Does Codex work in a Windows sandbox?

Yes. Native Windows offers an elevated sandbox and a weaker unelevated fallback. Codex in WSL uses the Linux sandbox implementation. OpenAI recommends the elevated native mode when it is available.