agent-approvals-security.md Codex Docs, 2026-03-07 00:33 UTC → 2026-04-22 18:29 UTC

8 8 

9By default, the agent runs with network access turned off. Locally, Codex uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace), plus an approval policy that controls when it must stop and ask you before acting.9By default, the agent runs with network access turned off. Locally, Codex uses an OS-enforced sandbox that limits what it can touch (typically to the current workspace), plus an approval policy that controls when it must stop and ask you before acting.

10 10 

11For a high-level explanation of how sandboxing works across the Codex app, IDE

12extension, and CLI, see [sandboxing](https://developers.openai.com/codex/concepts/sandboxing).

13For a broader enterprise security overview, see the [Codex security white paper](https://trust.openai.com/?itemUid=382f924d-54f3-43a8-a9df-c39e6c959958&source=click).

14 

11## Sandbox and approvals15## Sandbox and approvals

12 16 

13Codex security controls come from two layers that work together:17Codex security controls come from two layers that work together:

69- `<writable_root>/.codex` is protected as read-only when it exists as a directory.73- `<writable_root>/.codex` is protected as read-only when it exists as a directory.

70- Protection is recursive, so everything under those paths is read-only.74- Protection is recursive, so everything under those paths is read-only.

71 75 

76### Deny reads with filesystem profiles

77 

78Named permission profiles can also deny reads for exact paths or glob patterns.

79This is useful when a workspace should stay writable but specific sensitive

80files, such as local environment files, must stay unreadable:

81 

82```toml

83default_permissions = "workspace"

84 

85[permissions.workspace.filesystem]

86":project_roots" = { "." = "write", "**/*.env" = "none" }

87glob_scan_max_depth = 3

88```

89 

90Use `"none"` for paths or globs that Codex shouldn't read. The sandbox policy

91evaluates globs for local macOS and Linux command execution. On platforms that

92pre-expand glob matches before the sandbox starts, set `glob_scan_max_depth` for

93unbounded `**` patterns, or list explicit depths such as `*.env`, `*/*.env`, and

94`*/*/*.env`.

95 

72### Run without approval prompts96### Run without approval prompts

73 97 

74You can disable approval prompts with `--ask-for-approval never` or `-a never` (shorthand).98You can disable approval prompts with `--ask-for-approval never` or `-a never` (shorthand).

77 101 

78If you need Codex to read files, make edits, and run commands with network access without approval prompts, use `--sandbox danger-full-access` (or the `--dangerously-bypass-approvals-and-sandbox` flag). Use caution before doing so.102If you need Codex to read files, make edits, and run commands with network access without approval prompts, use `--sandbox danger-full-access` (or the `--dangerously-bypass-approvals-and-sandbox` flag). Use caution before doing so.

79 103 

80For a middle ground, `approval_policy = { reject = { ... } }` lets you auto-reject specific approval prompt categories (sandbox escalation, execpolicy-rule prompts, or MCP elicitations) while keeping other prompts interactive.104For a middle ground, `approval_policy = { granular = { ... } }` lets you keep specific approval prompt categories interactive while automatically rejecting others. The granular policy covers sandbox approvals, execpolicy-rule prompts, MCP prompts, `request_permissions` prompts, and skill-script approvals.

105 

106Set `approvals_reviewer = "guardian_subagent"` to route eligible approval reviews through the Guardian reviewer subagent instead of prompting the user directly. Admin requirements can constrain this with `allowed_approvals_reviewers`.

81 107 

82### Common sandbox and approval combinations108### Common sandbox and approval combinations

83 109 

107[sandbox_workspace_write]133[sandbox_workspace_write]

108network_access = true134network_access = true

109 135 

110# Optional: granular approval prompt auto-rejection136# Optional: granular approval policy

111# approval_policy = { reject = { sandbox_approval = true, rules = false, mcp_elicitations = false } }137# approval_policy = { granular = {

138# sandbox_approval = true,

139# rules = true,

140# mcp_elicitations = true,

141# request_permissions = false,

142# skill_approval = false

143# } }

112```144```

113 145 

114You can also save presets as profiles, then select them with `codex --profile <name>`:146You can also save presets as profiles, then select them with `codex --profile <name>`:

141Codex enforces the sandbox differently depending on your OS:173Codex enforces the sandbox differently depending on your OS:

142 174 

143- **macOS** uses Seatbelt policies and runs commands using `sandbox-exec` with a profile (`-p`) that corresponds to the `--sandbox` mode you selected. When restricted read access enables platform defaults, Codex appends a curated macOS platform policy (instead of broadly allowing `/System`) to preserve common tool compatibility.175- **macOS** uses Seatbelt policies and runs commands using `sandbox-exec` with a profile (`-p`) that corresponds to the `--sandbox` mode you selected. When restricted read access enables platform defaults, Codex appends a curated macOS platform policy (instead of broadly allowing `/System`) to preserve common tool compatibility.

144- **Linux** uses `Landlock` plus `seccomp` by default. You can opt into the alternative Linux sandbox pipeline with `features.use_linux_sandbox_bwrap = true` (or `-c use_linux_sandbox_bwrap=true`). In managed proxy mode, the bwrap pipeline routes egress through a proxy-only bridge and fails closed if it cannot build valid loopback proxy routes; landlock-only flows do not use that bridge behavior.176- **Linux** uses `bwrap` plus `seccomp` by default.

145- **Windows** uses the Linux sandbox implementation when running in [Windows Subsystem for Linux (WSL)](https://developers.openai.com/codex/windows#windows-subsystem-for-linux). When running natively on Windows, Codex uses a [Windows sandbox](https://developers.openai.com/codex/windows#windows-sandbox) implementation.177- **Windows** uses the Linux sandbox implementation when running in [Windows Subsystem for Linux 2 (WSL2)](https://developers.openai.com/codex/windows#windows-subsystem-for-linux). WSL1 was supported through Codex `0.114`; starting in `0.115`, the Linux sandbox moved to `bwrap`, so WSL1 is no longer supported. When running natively on Windows, Codex uses a [Windows sandbox](https://developers.openai.com/codex/windows#windows-sandbox) implementation.

146 178 

147If you use the Codex IDE extension on Windows, it supports WSL directly. Set the following in your VS Code settings to keep the agent inside WSL whenever it’s available:179If you use the Codex IDE extension on Windows, it supports WSL2 directly. Set the following in your VS Code settings to keep the agent inside WSL2 whenever it's available:

148 180 

149```json181```json

150{182{

159```toml191```toml

160[windows]192[windows]

161sandbox = "unelevated" # or "elevated"193sandbox = "unelevated" # or "elevated"

194# sandbox_private_desktop = true # default; set false only for compatibility

162```195```

163 196 

164See the [Windows setup guide](https://developers.openai.com/codex/windows#windows-sandbox) for details.197See the [Windows setup guide](https://developers.openai.com/codex/windows#windows-sandbox) for details.

165 198 

166When you run Linux in a containerized environment such as Docker, the sandbox may not work if the host or container configuration doesn’t support the required `Landlock` and `seccomp` features.199When you run Linux in a containerized environment such as Docker, the sandbox may not work if the host or container configuration blocks the namespace, setuid `bwrap`, or `seccomp` operations that Codex needs.

167 200 

168In that case, configure your Docker container to provide the isolation you need, then run `codex` with `--sandbox danger-full-access` (or the `--dangerously-bypass-approvals-and-sandbox` flag) inside the container.201In that case, configure your Docker container to provide the isolation you need, then run `codex` with `--sandbox danger-full-access` (or the `--dangerously-bypass-approvals-and-sandbox` flag) inside the container.

169 202 

203### Run Codex in Dev Containers

204 

205If your host cannot run the Linux sandbox directly, or if your organization already standardizes on containerized development, run Codex with Dev Containers and let Docker provide the outer isolation boundary. This works with Visual Studio Code Dev Containers and compatible tools.

206 

207Use the [Codex secure devcontainer example](https://github.com/openai/codex/tree/main/.devcontainer) as a reference implementation. The example installs Codex, common development tools, `bubblewrap`, and firewall-based outbound controls.

208 

209Devcontainers provide substantial protection, but they do not prevent every

210 attack. If you run Codex with `--sandbox danger-full-access` or

211 `--dangerously-bypass-approvals-and-sandbox` inside the container, a malicious

212 project can exfiltrate anything available inside the devcontainer, including

213 Codex credentials. Use this pattern only with trusted repositories, and

214 monitor Codex activity as you would in any other elevated environment.

215 

216The reference implementation includes:

217 

218- an Ubuntu 24.04 base image with Codex and common development tools installed;

219- an allowlist-driven firewall profile for outbound access;

220- VS Code settings and extension recommendations for reopening the workspace in a container;

221- persistent mounts for command history and Codex configuration;

222- `bubblewrap`, so Codex can still use its Linux sandbox when the container grants the needed capabilities.

223 

224To try it:

225 

2261. Install Visual Studio Code and the [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers).

2272. Copy the Codex example `.devcontainer` setup into your repository, or start from the Codex repository directly.

2283. In VS Code, run **Dev Containers: Open Folder in Container…** and select `.devcontainer/devcontainer.secure.json`.

2294. After the container starts, open a terminal and run `codex`.

230 

231You can also start the container from the CLI:

232 

233```bash

234devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

235```

236 

237The example has three main pieces:

238 

239- `.devcontainer/devcontainer.secure.json` controls container settings, capabilities, mounts, environment variables, and VS Code extensions.

240- `.devcontainer/Dockerfile.secure` defines the Ubuntu-based image and installed tools.

241- `.devcontainer/init-firewall.sh` applies the outbound network policy.

242 

243The reference firewall is intentionally a starting point. If you depend on domain allowlisting for isolation, implement DNS rebinding and DNS refresh protections that fit your environment, such as TTL-aware refreshes or a DNS-aware firewall.

244 

245Inside the container, choose one of these modes:

246 

247- Keep Codex's Linux sandbox enabled if the Dev Container profile grants the capabilities needed for `bwrap` to create the inner sandbox.

248- If the container is your intended security boundary, run Codex with `--sandbox danger-full-access` inside the container so Codex does not try to create a second sandbox layer.

249 

170## Version control250## Version control

171 251 

172Codex works best with a version control workflow:252Codex works best with a version control workflow: