Guide · Codex CLI sandbox modes and approval policy

How do I run Codex CLI safely?

Updated 2026-10-31

Run Codex in its workspace-write sandbox with the on-request approval policy: it can edit files and run routine commands inside your project, with network access off, and it asks before going further. Keep danger-full-access and --dangerously-bypass-approvals-and-sandbox (--yolo) for when Codex is already inside a separate machine, such as a VM; OpenAI's reference says to use the bypass flag only inside an externally hardened environment.

01Steps

Set both axes explicitly. The sandbox mode decides what commands can touch; the approval policy decides when Codex stops to ask. Naming both on the command line removes any doubt about which defaults are in force.
On Linux, install bubblewrap first. Codex's Linux and WSL2 sandbox uses the first bwrap executable it finds on PATH. On macOS it uses the built-in Seatbelt framework and needs nothing extra.
Leave the network off unless a task needs it. workspace-write keeps network access off by default. If a task genuinely needs it, turn it on in Codex's configuration file, knowing it is one switch for the whole sandbox rather than a list of hosts.
config.toml
```
[sandbox_workspace_write]
network_access = true
```
For unattended runs, give Codex a machine of its own. Install kosa8 on an Apple silicon Mac or an x86-64 Linux machine with KVM, start the daemon, and check it.
Keep your OpenAI key on the host and preview the plan. The codex kit is brokered: the sandbox gets a placeholder and a base URL pointing at a broker on your computer, which adds the real key only for api.openai.com. The dry run prints the plan and starts nothing.
Run Codex inside the microVM. Options for kosa8 go before the kit name; everything after it is passed to Codex. OpenAI's docs say that when a container is the security boundary you can run Codex with danger-full-access inside it, and here the boundary is a whole VM.
Check where it went. Every request through the broker, allowed or refused, is in the audit log. kosa8 sandbox egress shows a running sandbox's network rule and how many requests it refused.

02What are Codex's sandbox modes and approval policies?

Codex sets two things separately. The sandbox mode decides what commands can touch: read-only lets it inspect files, workspace-write lets it edit inside the workspace and run routine local commands there, and danger-full-access removes the filesystem and network boundaries. The approval policy decides when it stops to ask: on-request asks when it needs to go beyond the sandbox, and never does not stop for approval prompts.

OpenAI's recommended default pairs workspace-write with on-request. For CI, it suggests read-only with never. In workspace-write, .git is kept read-only, as are .agents, .codex and .aws when they exist as directories. The untrusted approval policy is no longer selectable.

03Codex full-auto vs yolo: what is the difference?

--full-auto, which many older tutorials use, was a low-prompt preset that kept the workspace-write sandbox on. --yolo is short for --dangerously-bypass-approvals-and-sandbox, which runs every command without approvals or sandboxing. The current Codex reference documents --sandbox and --ask-for-approval for the first case, and says to use the bypass flag only inside an externally hardened environment.

The difference matters most for prompt injection. Under workspace-write, an instruction hidden in a README or an issue can still only reach the workspace, without the network. Under the bypass flag it reaches whatever your user account can.

04Does Codex workspace-write have network access?

Not by default. OpenAI's documentation says workspace-write keeps network access turned off unless you set network_access = true under [sandbox_workspace_write] in your configuration. Turning it on lets sandboxed commands reach the network, so anything Codex reads in the workspace could be sent out.

If you need some hosts and not others, that has to be enforced outside Codex. In a kosa8 sandbox the codex kit allows registry.npmjs.org by name, reaches api.openai.com only through its credential's route, and refuses every other host on your side of the boundary.

05Is danger-full-access safe inside a VM?

It is as safe as the VM's limits. With kosa8, danger-full-access reaches one microVM with its own kernel: the project folder you named, mounted at /work, the hosts the codex kit allows, and a placeholder where your OpenAI key would be. Nothing else on your computer is visible from inside.

The folder is real. Codex can change or delete anything in the shared folder, including .git. Commit before you start.
Requests leave a trail. Each brokered request is logged with host, method, path and status, never the key.
Stop everything at once. kosa8 sandbox pause --all freezes every running sandbox with its memory and files intact.

kosa8's tool-call checks are documented for the claude kit only; for Codex, the VM, the network list and the broker are what hold it.

06Other options

Codex's own sandbox in workspace-write fits most interactive work, on macOS (Seatbelt), Linux and WSL2 (bubblewrap) and native Windows.
A dev container or Docker fits a team that already uses one. OpenAI notes that its Linux sandbox may not work if the container configuration blocks what it needs, and that dev containers do not prevent every attack.
Docker Sandboxes runs agents in microVMs from Docker's tooling.
gVisor or Kata Containers fit Linux hosts that already run containers and want a stronger runtime underneath.
A full VM in UTM or Lima fits when you want a general-purpose guest you manage yourself.
Hosted sandboxes such as E2B, Daytona or Modal fit agents that should run in the cloud.