AI Native Notes

Official References: Sandboxing · Config Basics · Cloud Environments · Review

Curriculum path

Codex Getting Started — basic flow first
Codex Instructions — AGENTS.md and config
Codex Sandboxing — permissions, approvals, writable roots, cloud runtime ← You are here
Codex Task Design — task sizing and finish lines
Codex Skills — package repeated work
Codex MCP — connect outside systems
Codex Reviews and Automations — unattended but reviewable workflows

Official docs used in this guide

Differences between read-only, workspace-write, and danger-full-access — Sandboxing
Baseline config combinations — Config basics
Cloud task lifecycle, setup, and internet timing — Cloud environments

Sandboxing is a safety setting and a UX setting

If the boundary is too tight, you drown in approvals. If it is too wide, small mistakes become expensive.

The real goal is simple: let Codex do normal work without stopping constantly, while keeping risky actions inside a human-controlled boundary.

Keep local and cloud mentally separate

Local Codex

Runs on your machine, under a sandbox and approval policy that you control.

Cloud Codex

Runs in an OpenAI-managed container, where setup scripts, environment variables, and internet policy matter most.

Mixing those two models is one of the fastest ways to get confused.

The three common local sandbox modes

The Sandboxing docs describe them like this:

Mode	Meaning	Best fit
`read-only`	inspect files, but edits and commands need approval	audits, exploration, safe review
`workspace-write`	edit inside the workspace and run routine commands there	normal day-to-day development
`danger-full-access`	remove sandbox restrictions	rare, high-trust automation only

OpenAI explicitly describes workspace-write as the default low-friction local mode.

Approval policy controls when Codex pauses

The config docs highlight a very common combination:

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

This works well because:

normal in-repo work keeps moving
boundary-crossing actions still ask first

For most developers and most teams, this is the practical default.

Writable roots matter more than many people realize

Many users focus on sandbox mode and forget about writable roots. In practice, that is where a lot of accidental risk lives.

Good defaults:

the repository itself
maybe one temp directory

Risky defaults:

your whole home directory
multiple unrelated project roots

The question is not just “can Codex write?” but where exactly can it write?

In cloud runs, setup is the contract

The Cloud Environments docs describe a flow like this:

create a container and check out the repo
run the setup script
apply internet access settings
let the agent edit and verify

Two details matter a lot:

setup scripts run with internet access
agent-phase internet is off by default

So dependency installation, codegen, and test bootstrapping belong in setup whenever possible.

What belongs in setup?

Good candidates:

dependency installation
runtime/tool version pinning
test data setup
code generation
native build prep

Bad candidates:

implementing the whole feature
steps that require repeated human judgment

Setup should make the environment reproducible, not silently do the task for you.

Review and sandboxing should be thought about together

The Review docs say the review pane focuses on uncommitted changes by default, and can switch to base-branch diff or last-turn changes. That matters because broader permissions imply a stronger need for review.

In practice:

tighter sandbox = more interruptions, lower blast radius
looser sandbox = fewer interruptions, higher review burden

Those two are always linked.

A sensible starting configuration

Local

model = "gpt-5.4"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

Then keep writable roots narrow.

Cloud

deterministic setup script
internet only when needed
minimum secrets exposure
real verification commands documented in AGENTS.md

Codex Sandboxing — Permissions, Approvals, and Cloud Environments