OpenAI's coding language model, Codex, is designed with a robust multi-layer sandboxing system that enforces strict guardrails for secure execution. However, there may be situations where developers want to operate Codex with fewer restrictions for trusted workflows. This guide provides an in-depth look at what the Codex sandbox is, why it exists, and how one can use the --dangerously-bypass-approvals-and-sandbox flag to disable it.
Disclaimer: Bypassing the Codex sandbox may compromise crucial security measures designed to protect your system and codebase. The information provided herein is purely educational — proceed with caution and only in controlled environments.
Prepping Your Environment: Installing the Codex CLI or Running It in Docker
Before attempting to bypass the Codex sandbox, you need to set up your development environment. This involves installing Codex CLI or running it in a Docker container.
To install Codex CLI, use either NPM or Homebrew:
# Install via NPM
npm install -g @openai/codex
# Install via Homebrew
brew install --cask codex
Once installed, run codex in your terminal to start the Codex CLI. Next, authenticate the Codex CLI by exporting your API key:
export OPENAI_API_KEY="<your-openai-key>"
For Windows users, replace export with the set command.
Alternatively, if you prefer container isolation (highly recommended when bypassing the sandbox), you can run Codex in Docker:
docker run --rm -it -v "$(pwd):/workspace" -w /workspace ghcr.io/openai/codex:latest \
codex --sandbox danger-full-access --ask-for-approval never
This command gives Codex full access inside the Docker container, effectively isolating it from your host system.
Understanding the Codex Sandbox
The Codex sandbox is a security mechanism designed to limit what Codex can do on your machine. According to the OpenAI Codex security guide, the sandbox features include:
- OS-level sandboxing (e.g., Seatbelt on macOS, seccomp/Landlock on Linux) when you run Codex locally (via CLI or an IDE).(Learn more on OpenAI Developers
- Network access is disabled by default, and write permissions are restricted to your current workspace.
- Codex will seek your approval for commands outside your workspace.
- The default approval mode is often set to Auto, meaning Codex can write in your workspace but requires approval for potentially risky operations.
These security measures protect users from potential threats such as executing malicious code, leaking data, or making harmful system modifications.
The Need for the Codex Sandbox
The sandboxing of Codex serves multiple purposes:
- Security: It prevents Codex from writing arbitrarily to your machine outside the workspace.
- Network Safety: It blocks network access unless explicitly permitted, reducing the risk of data leakage or unsafe API calls.
- Controlled Execution: Codex requires user approval for potentially dangerous actions, such as executing commands or modifying system files.
- Isolation: It ensures that Codex operates in a controlled environment, limiting potential damage from buggy or malicious prompts.
Scenarios for Bypassing the Codex Sandbox
There are valid cases where disabling the sandbox may be beneficial, particularly in trusted environments. These include:
- Running Codex inside a Docker container or isolated VM where risks are already managed.
- Needing Codex to execute shell commands, install dependencies, or perform tasks without repetitive user approvals.
- Using Codex in a trusted CI/CD pipeline and granting it higher permissions.
- Understanding the risks and wanting to experiment or prototype features that require full file system or network access.
Bypassing the Codex Sandbox — Configuring & Commanding
Here's how to configure and execute Codex without sandbox restrictions using both CLI flags and config.toml:
Bypassing via CLI Command
To bypass both sandboxing and approval prompts altogether, run the following command:
codex --dangerously-bypass-approvals-and-sandbox
This command gives Codex complete freedom, removing all sandbox restrictions and approval prompts. Use it only in controlled environments.
Bypassing via ~/.codex/config.toml
You can set persistent configurations in your config.toml to disable sandboxing:
# ~/.codex/config.toml
model = "gpt-5-codex"
approval_policy = "never"
sandbox_mode = "danger-full-access"
[sandbox_workspace_write]
network_access = true
# (Optional) define additional writable roots
writable_roots = ["/workspace", "/tmp"]
approval_policy = "never" disables all approval prompts, and sandbox_mode = "danger-full-access" removes sandbox isolation. The [sandbox_workspace_write].network_access = true setting allows Codex to make network calls when in workspace-write mode.
With this configuration (assuming you're comfortable with the associated risks), Codex will operate without seeking approval and will have full filesystem and network privileges.
Testing the Sandbox Behavior
You can investigate Codex's behavior under different sandbox settings using its debug commands:
# On macOS:
codex sandbox macos --full-auto ls /
# On Linux:
codex sandbox linux --full-auto ls /
These commands execute arbitrary shell commands under Codex’s enforced sandbox policy, helping you understand what is permitted and what isn't.
Risks of Bypassing the Codex Sandbox
When the bypass is enabled, Codex can:
- Execute any shell command, including potentially risky or destructive ones.
- Read from and write to any location on the disk.
- Potentially make network calls, depending on the configuration.
Use the bypass feature only when:
- You're running Codex in a secure, isolated VM or Docker container.
- You trust the prompts and are comfortable giving Codex full access.
- You're automating trusted workflows (e.g., CI), not allowing unvetted LLM prompts to run arbitrarily.
Known Vulnerabilities & Bug History of the Codex Sandbox
It's worth noting that certain versions of the Codex CLI have had sandbox bypass vulnerabilities due to bugs in Codex’s path configuration logic. These versions considered a model-generated working directory as writable, even if it should have been isolated. This bug allowed writes outside the intended sandbox boundary. The issue was patched in Codex CLI v0.39.0. If you're considering bypassing the sandbox, ensure your version is up to date to avoid exploitation via known security flaws.
Frequently Asked Questions
Q1. Is bypassing the Codex sandbox recommended for general use?
No — it is only recommended in controlled, trusted environments. Bypassing the sandbox removes security safety nets.
Q2. Does bypassing the sandbox disable all safety prompts?
Yes. The --dangerously-bypass-approvals-and-sandbox flag disables both sandbox restrictions and approval prompts.
Q3. Can I safely run bypass mode inside Docker?
It’s safer — Docker provides isolation. If your container is well-configured, bypassing the sandbox may be acceptable for trusted workloads.
Q4. What if I’m using an older version of Codex CLI?
Older versions (≤ 0.38.0) may have sandbox bugs, including path escape vulnerabilities. Update to the latest version before using bypass mode.
Q5. How do I revert back to sandbox mode?
Simply run Codex without the dangerous flag, or explicitly set the sandbox mode via:
codex --sandbox workspace-write --ask-for-approval on-request
In Conclusion
The --dangerously-bypass-approvals-and-sandbox flag provides Codex with maximum freedom. However, this freedom comes with significant risks. The Codex sandbox exists to protect your system, data, and workflows from unintended or malicious behavior. Only bypass it if you fully understand the implications, are running in a trusted environment, or need unrestricted access for automation.
In a shared, production, or sensitive context, it’s almost always safer to stick with the sandbox and approval prompts. But for controlled experiments, CI pipelines, or trusted containers, bypassing the sandbox can unlock powerful use cases — just don’t take this step lightly.
