1# Sandboxing – Codex
2
3Sandboxing is the boundary that lets Codex act autonomously without giving it
4unrestricted access to your machine. When Codex runs local commands in the
5**Codex app**, **IDE extension**, or **CLI**, those commands run inside a
6constrained environment instead of running with full access by default.
7
8That environment defines what Codex can do on its own, such as which files it
9can modify and whether commands can use the network. When a task stays inside
10those boundaries, Codex can keep moving without stopping for confirmation. When
11it needs to go beyond them, Codex falls back to the approval flow.
12
13Sandboxing and approvals are different controls that work together. The
14 sandbox defines technical boundaries. The approval policy decides when Codex
15 must stop and ask before crossing them.
16
17## What the sandbox does
18
19The sandbox applies to spawned commands, not just to Codex's built-in file
20operations. If Codex runs tools like `git`, package managers, or test runners,
21those commands inherit the same sandbox boundaries.
22
23Codex uses platform-native enforcement on each OS. The implementation differs
24between macOS, Linux, WSL, and native Windows, but the idea is the same across
25surfaces: give the agent a bounded place to work so routine tasks can run
26autonomously inside clear limits.
27
28## Why it matters
29
30Sandboxing reduces approval fatigue. Instead of asking you to confirm every
31low-risk command, Codex can read files, make edits, and run routine project
32commands within the boundary you already approved.
33
34It also gives you a clearer trust model for agentic work. You are not just
35trusting the agent's intentions; you are trusting that the agent is operating
36inside enforced limits. That makes it easier to let Codex work independently
37while still knowing when it will stop and ask for help.
38
39## How you control it
40
41Most people start with the permissions controls in the product.
42
43In the Codex app and IDE, you choose a mode from the permissions selector under
44the composer or chat input. That selector lets you rely on Codex's default
45permissions, switch to full access, or use your custom configuration.
46
47
48
49In the CLI, use [`/permissions`](https://developers.openai.com/codex/cli/slash-commands#update-permissions-with-permissions)
50to switch modes during a session.
51
52## Configure defaults
53
54If you want Codex to start with the same behavior every time, use a custom
55configuration. Codex stores those defaults in `config.toml`, its local settings
56file. [Config basics](https://developers.openai.com/codex/config-basic) explains how it works, and the
57[Configuration reference](https://developers.openai.com/codex/config-reference) documents the exact keys for
58`sandbox_mode`, `approval_policy`, and
59`sandbox_workspace_write.writable_roots`. Use those settings to decide how much
60autonomy Codex gets by default, which directories it can write to, and when it
61should pause for approval.
62
63At a high level, the common sandbox modes are:
64
65- `read-only`: Codex can inspect files, but it cannot edit files or run
66 commands without approval.
67- `workspace-write`: Codex can read files, edit within the workspace, and run
68 routine local commands inside that boundary. This is the default low-friction
69 mode for local work.
70- `danger-full-access`: Codex runs without sandbox restrictions. This removes
71 the filesystem and network boundaries and should be used only when you want
72 Codex to act with full access.
73
74The common approval policies are:
75
76- `untrusted`: Codex asks before running commands that are not in its trusted
77 set.
78- `on-request`: Codex works inside the sandbox by default and asks when it
79 needs to go beyond that boundary.
80- `never`: Codex does not stop for approval prompts.
81
82Full access means using `sandbox_mode = "danger-full-access"` together with
83`approval_policy = "never"`. By contrast, `--full-auto` is the lower-risk local
84automation preset: `sandbox_mode = "workspace-write"` and
85`approval_policy = "on-request"`.
86
87If you need Codex to work across more than one directory, writable roots let
88you extend the places it can modify without removing the sandbox entirely. If
89you need a broader or narrower trust boundary, adjust the default sandbox mode
90and approval policy instead of relying on ad hoc exceptions.
91
92When a workflow needs a specific exception, use [rules](https://developers.openai.com/codex/rules). Rules
93let you allow, prompt, or forbid command prefixes outside the sandbox, which is
94often a better fit than broadly expanding access. For a higher-level overview
95of approvals and sandbox behavior in the app, see
96[Codex app features](https://developers.openai.com/codex/app/features#approvals-and-sandboxing), and for the
97IDE-specific settings entry points, see [Codex IDE extension settings](https://developers.openai.com/codex/ide/settings).
98
99Platform details live in the platform-specific docs. For native Windows setup,
100behavior, and troubleshooting, see [Windows](https://developers.openai.com/codex/windows). For admin
101requirements and organization-level constraints on sandboxing and approvals, see
102[Agent approvals & security](https://developers.openai.com/codex/agent-approvals-security).
