Sandboxed Execution

When you give an AI agent the ability to run shell commands and edit files on your machine, safety becomes critical. Codex CLI addresses this with a multi-layered sandbox that restricts what the agent can do.

The sandbox provides three layers of protection:

Why this matters:

Without sandboxing, a coding agent could:

• Delete files outside your project
• Install malicious packages
• Send your code to external servers
• Modify system configuration files
• Execute destructive commands (rm -rf /)

Codex CLI's sandbox makes these scenarios impossible by default. Even if the AI model generates a dangerous command, the sandbox prevents execution.

Codex CLI restricts file operations to your project directory (the working directory where you launched it). This is the most important safety boundary.

What Codex CAN access:

• All files and subdirectories within your project folder
• Files you explicitly reference in your prompts
• Temporary files it creates within the project

What Codex CANNOT access:

• Files above your project directory (no ../ escape)
• Your home directory configuration files
• System files (/etc, /usr, C:\Windows)
• Other project directories
• SSH keys, credentials, or secrets outside the project

See it in action:

Try asking Codex to read a file outside your project:

> Show me the contents of ~/.bashrc

Codex will either:

1. Refuse the request, explaining it's outside the sandbox
2. Attempt a command that the sandbox blocks, then report the failure

Testing the boundary:

> Create a file at /tmp/test.txt with the content "hello"

This will fail because /tmp is outside your project directory. Codex will report that the operation was blocked by the sandbox.

The writable directory structure:

my-project/          ← Codex launched here (root of sandbox)
├── src/             ← Codex can read and write
├── tests/           ← Codex can read and write
├── docs/            ← Codex can read and write
├── package.json     ← Codex can read and write
└── .git/            ← Codex can read (but shouldn't modify)

By default, shell commands executed by Codex CLI have no network access. This prevents commands from downloading malicious payloads, exfiltrating your code, or making unexpected API calls.

Default network behaviour:

When you need network access:

Some tasks legitimately require network:

• Installing dependencies (npm install, pip install)
• Fetching remote resources
• Running tests that call APIs
• Git operations with remotes

Enabling network access:

You can enable network access by adjusting the sandbox mode in your configuration:

# In config.toml
sandbox_mode = "danger-full-access"

Or via command-line for a single session:

codex --sandbox danger-full-access "Install express and create a basic server"

What happens when network is blocked:

If Codex tries to run a command that needs network while it's disabled:

$ npm install express
npm ERR! network request failed
npm ERR! This is a problem with network connectivity.

Codex will report the failure and may suggest enabling network access or offer an alternative approach.

Codex CLI uses two independent axes of control: approval policies (what requires human confirmation) and sandbox modes (what the OS allows).

Approval policies:

You can also use granular for fine-grained per-tool control (auto, prompt, or approve for each tool type).

Sandbox modes:

Setting approval policy:

# Launch with a specific policy
codex --approval-policy on-request

# Or in config.toml
# approval_policy = "on-request"

Setting sandbox mode:

# Launch with a specific sandbox mode
codex --sandbox workspace-write

# Or in config.toml
# sandbox_mode = "workspace-write"

Switching policies during a session:

The /approval command from older versions is deprecated. To change policies, exit and relaunch with the desired flags or update your config.toml.

Knowing when to use each combination is essential for balancing productivity with safety. Here's a decision framework:

Use untrusted + workspace-write when:

• You're working on production code
• You're unfamiliar with what Codex might do
• The task involves destructive operations (deleting files, modifying configs)
• You're still learning Codex CLI
• You want to understand the AI's reasoning step by step

Use on-request + workspace-write when:

• You're doing repetitive refactoring (rename variable across files)
• You trust the file edits but want to control shell commands
• You're working in a git repo with a clean state (easy to revert)
• Speed matters more than reviewing every character

Use never + danger-full-access when:

• You're in a disposable environment (containers, CI)
• The task is well-defined and low-risk (generate boilerplate)
• You're running batch operations you've tested manually first
• You have comprehensive git history to fall back on

Practical example — choosing settings for different tasks:

# Exploring and understanding code → safest settings
codex --approval-policy untrusted --sandbox read-only "Explain the auth flow"

# Refactoring with trust → faster edits
codex --approval-policy on-request "Add type hints to all Python files in src/"

# Generating boilerplate in fresh project → full autonomy
codex --approval-policy never --sandbox danger-full-access "Create a basic Express app"

Safety checklist before choosing settings:

1. Is my work committed to git? (If no → stay with untrusted)
2. Do I understand what Codex will do? (If no → stay with untrusted)
3. Could the task damage other files? (If yes → stay with untrusted)
4. Am I in a production environment? (If yes → stay with untrusted)
5. Is this a repeatable, low-risk operation? (If yes → consider on-request)