agent-approvals-security diff

agent-approvals-security.md +487 −0 added

Details

1# Agent approvals & security

3Codex helps protect your code and data and reduces the risk of misuse.

5This page covers how to operate Codex safely, including sandboxing, approvals,

6 and network access. If you are looking for Codex Security, the product for

7 scanning connected GitHub repositories, see [Codex Security](https://developers.openai.com/codex/security).

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.

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).

15## Sandbox and approvals

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

19- **Sandbox mode**: What Codex can do technically (for example, where it can write and whether it can reach the network) when it executes model-generated commands.

20- **Approval policy**: When Codex must ask you before it executes an action (for example, leaving the sandbox, using the network, or running commands outside a trusted set).

22Codex uses different sandbox modes depending on where you run it:

24- **Codex cloud**: Runs in isolated OpenAI-managed containers, preventing access to your host system or unrelated data. Uses a two-phase runtime model: setup runs before the agent phase and can access the network to install specified dependencies, then the agent phase runs offline by default unless you enable internet access for that environment. Secrets configured for cloud environments are available only during setup and are removed before the agent phase starts.

25- **Codex CLI / IDE extension**: OS-level mechanisms enforce sandbox policies. Defaults include no network access and write permissions limited to the active workspace. You can configure the sandbox, approval policy, and network settings based on your risk tolerance.

27In the `Auto` preset (for example, `--sandbox workspace-write --ask-for-approval on-request`), Codex can read files, make edits, and run commands in the working directory automatically.

29Codex asks for approval to edit files outside the workspace or to run commands that require network access. If you want to chat or plan without making changes, switch to `read-only` mode with the `/permissions` command.

31Codex can also elicit approval for app (connector) tool calls that advertise side effects, even when the action isn't a shell command or file change. Destructive app/MCP tool calls always require approval when the tool advertises a destructive annotation, even if it also advertises other hints (for example, read-only hints).

33## Network access <ElevatedRiskBadge class="ml-2" />

35For Codex cloud, see [agent internet access](https://developers.openai.com/codex/cloud/internet-access) to enable full internet access or a domain allow list.

37For the Codex app, CLI, or IDE Extension, the default `workspace-write` sandbox mode keeps network access turned off unless you enable it in your configuration:

39```toml

40[sandbox_workspace_write]

41network_access = true

42```

44### Network isolation

46Network access is controlled through destination rules that apply to scripts,

47programs, and subprocesses spawned by commands. When command network access is

48already enabled, turn on the `network_proxy` feature to constrain that traffic

49to the network policy you configure.

51```toml

52[features.network_proxy]

53enabled = true

54domains = { "api.openai.com" = "allow", "example.com" = "deny" }

55```

57For a one-off CLI session, use the boolean shorthand when you only need the

58toggle, and the table form when you also set policy options:

60```bash

61codex \

62 -c 'features.network_proxy=true' \

63 -c 'sandbox_workspace_write.network_access=true'

65codex \

66 -c 'features.network_proxy.enabled=true' \

67 -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \

68 -c 'sandbox_workspace_write.network_access=true'

69```

71The feature changes how enabled network access is enforced; it does not grant

72network access by itself. Use `sandbox_workspace_write.network_access` with

73`workspace-write` config to decide whether commands have network access at all:

75- Network off + `network_proxy` on: network stays off, and the feature does nothing.

76- Network on + `network_proxy` off: network stays on with unrestricted direct

77 outbound access.

78- Network on + `network_proxy` on: network stays on, and outbound traffic is

79 constrained by the configured network policy.

81Admin-managed `experimental_network` requirements are separate from the user

82feature toggle. They can configure and start sandboxed networking without

83`features.network_proxy`, but they do not turn on network access when the active

84sandbox keeps it off. See [Managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration#configure-network-access-requirements)

85for the administrator-side `requirements.toml` shape.

87#### Network policy

89Domain rules are allowlist-first:

91- Exact hosts match only themselves.

92- `*.example.com` matches subdomains such as `api.example.com`, but not

93 `example.com`.

94- `**.example.com` matches both the apex and subdomains.

95- A global `*` allow rule matches any public host that is not denied. Treat `*`

96 as broad network access and prefer scoped rules when you can.

97- `deny` always wins over `allow`, and global `*` is only valid for allow rules.

99#### Local and private destinations

100

101By default, `allow_local_binding = false` blocks loopback, link-local, and

102private destinations:

103

104- Specific exceptions: add an exact local IP literal or `localhost` allow rule

105 when a command needs one local target.

106- Broader access: set `allow_local_binding = true` only when you intentionally

107 want wider local/private reach.

108- Wildcards: wildcard rules do not count as explicit local exceptions.

109- Resolved addresses: hostnames that resolve to local/private IPs stay blocked

110 even if they match the allowlist.

111

112#### DNS rebinding protections

113

114Before allowing a hostname, Codex performs a best-effort DNS and IP

115classification check:

116

117- Lookups that fail or time out are blocked.

118- Hostnames that resolve to non-public addresses are blocked.

119- The check reduces DNS rebinding risk, but it does not eliminate it. Preventing

120 rebinding completely would require pinning resolved IPs through the transport

121 layer.

122

123If hostile DNS is in scope, enforce egress controls at a lower layer too.

124

125#### Dangerous settings

126

127Two settings deliberately widen the trust boundary:

128

129- `dangerously_allow_non_loopback_proxy = true` can expose proxy listeners beyond

130 loopback.

131- `dangerously_allow_all_unix_sockets = true` bypasses the Unix socket allowlist.

132

133Use them only in tightly controlled environments. When Unix socket proxying is

134enabled, listeners stay loopback-only even if non-loopback binding was requested,

135so sandboxed networking does not become a remote bridge into local daemons.

136

137`network_proxy` is off by default. When you enable it:

138

139| Setting | Default | Behavior |

140| -------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

141| `enabled` | `false` | Starts sandboxed networking only when command network access is already on. |

142| `domains` | unset | Uses allowlist behavior, so no external destinations are allowed until you add `allow` rules. Supports exact hosts, scoped wildcards, and global `*` allow rules; `deny` always wins. |

143| `unix_sockets` | unset | No Unix socket destinations are allowed until you add explicit `allow` rules. |

144| `allow_local_binding` | `false` | Blocks local and private-network destinations unless you add an exact local IP literal or `localhost` allow rule, or explicitly opt into broader local/private access. |

145| `enable_socks5` | `true` | Exposes SOCKS5 support when policy allows it. |

146| `enable_socks5_udp` | `true` | Allows UDP over SOCKS5 when SOCKS5 is available. |

147| `allow_upstream_proxy` | `true` | Lets sandboxed networking honor an upstream proxy from the environment. |

148| `dangerously_allow_non_loopback_proxy` | `false` | Keeps listener endpoints on loopback unless you deliberately expose them beyond localhost. |

149| `dangerously_allow_all_unix_sockets` | `false` | Keeps Unix socket access allowlist-based unless you deliberately bypass that protection. |

150

151You can also control the [web search tool](https://platform.openai.com/docs/guides/tools-web-search) without granting full network access to spawned commands. Codex defaults to using a web search cache to access results. The cache is an OpenAI-maintained index of web results, so cached mode returns pre-indexed results instead of fetching live pages. This reduces exposure to prompt injection from arbitrary live content, but you should still treat web results as untrusted. If you are using `--yolo` or another [full access sandbox setting](#common-sandbox-and-approval-combinations), web search defaults to live results. Use `--search` or set `web_search = "live"` to allow live browsing, or set it to `"disabled"` to turn the tool off:

152

153```toml

154web_search = "cached" # default

155# web_search = "disabled"

156# web_search = "live" # same as --search

157```

158

159Use caution when enabling network access or web search in Codex. Prompt injection can cause the agent to fetch and follow untrusted instructions.

160

161## Defaults and recommendations

162

163- On launch, Codex detects whether the folder is version-controlled and recommends:

164 - Version-controlled folders: `Auto` (workspace write + on-request approvals)

165 - Non-version-controlled folders: `read-only`

166- Depending on your setup, Codex may also start in `read-only` until you explicitly trust the working directory (for example, via an onboarding prompt or `/permissions`).

167- The workspace includes the current directory and temporary directories like `/tmp`. Use the `/status` command to see which directories are in the workspace.

168- To accept the defaults, run `codex`.

169- You can set these explicitly:

170 - `codex --sandbox workspace-write --ask-for-approval on-request`

171 - `codex --sandbox read-only --ask-for-approval on-request`

172

173### Protected paths in writable roots

174

175In the default `workspace-write` sandbox policy, writable roots still include protected paths:

176

177- `<writable_root>/.git` is protected as read-only whether it appears as a directory or file.

178- If `<writable_root>/.git` is a pointer file (`gitdir: ...`), the resolved Git directory path is also protected as read-only.

179- `<writable_root>/.agents` is protected as read-only when it exists as a directory.

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

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

182

183### Deny reads with filesystem profiles

184

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

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

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

188

189```toml

190default_permissions = "workspace"

191

192[permissions.workspace.filesystem]

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

194glob_scan_max_depth = 3

195```

196

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

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

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

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

201`*/*/*.env`.

202

203### Run without approval prompts

204

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

206

207This option works with all `--sandbox` modes, so you still control Codex's level of autonomy. Codex makes a best effort within the constraints you set.

208

209If 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.

210

211For 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.

212

213### Automatic approval reviews

214

215By default, approval requests route to you:

216

217```toml

218approvals_reviewer = "user"

219```

220

221Automatic approval reviews apply when approvals are interactive, such as

222`approval_policy = "on-request"` or a granular approval policy. Set

223`approvals_reviewer = "auto_review"` to route eligible approval requests

224through a reviewer agent before Codex runs the request:

225

226```toml

227approval_policy = "on-request"

228approvals_reviewer = "auto_review"

229```

230

231For the full reviewer lifecycle, trigger conditions, configuration precedence,

232and failure behavior, see

233[Auto-review](https://developers.openai.com/codex/concepts/sandboxing/auto-review).

234

235The reviewer evaluates only actions that already need approval, such as sandbox

236escalations, blocked network requests, `request_permissions` prompts, or

237side-effecting app and MCP tool calls. Actions that stay inside the sandbox

238continue without an extra review step.

239

240The reviewer policy checks for data exfiltration, credential probing, persistent

241security weakening, and destructive actions. Low-risk and medium-risk actions

242can proceed when policy allows them. The policy denies critical-risk actions.

243High-risk actions require enough user authorization and no matching deny rule.

244Prompt-build, review-session, and parse failures fail closed. Timeouts are

245surfaced separately, but the action still does not run.

246

247The [default reviewer policy](https://github.com/openai/codex/blob/main/codex-rs/core/src/guardian/policy.md)

248is in the open-source Codex repository. Enterprises can replace its

249tenant-specific section with `guardian_policy_config` in managed requirements.

250Local `[auto_review].policy` text is also supported, but managed requirements

251take precedence. For setup details, see

252[Managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration#configure-automatic-review-policy).

253

254In the Codex app, these reviews appear as automatic review items with a status

255such as Reviewing, Approved, Denied, Aborted, or Timed out. They can also

256include a risk level and user-authorization assessment for the reviewed

257request.

258

259Automatic review uses extra model calls, so it can add to Codex usage. Admins

260can constrain it with `allowed_approvals_reviewers`.

261

262### Common sandbox and approval combinations

263

264| Intent | Flags / config | Effect |

265| ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |

266| Auto (preset) | _no flags needed_ or `--sandbox workspace-write --ask-for-approval on-request` | Codex can read files, make edits, and run commands in the workspace. Codex requires approval to edit outside the workspace or to access network. |

267| Safe read-only browsing | `--sandbox read-only --ask-for-approval on-request` | Codex can read files and answer questions. Codex requires approval to make edits, run commands, or access network. |

268| Read-only non-interactive (CI) | `--sandbox read-only --ask-for-approval never` | Codex can only read files; never asks for approval. |

269| Automatically edit but ask for approval to run untrusted commands | `--sandbox workspace-write --ask-for-approval untrusted` | Codex can read and edit files but asks for approval before running untrusted commands. |

270| Auto-review mode | `--sandbox workspace-write --ask-for-approval on-request -c approvals_reviewer=auto_review` or `approvals_reviewer = "auto_review"` | Same sandbox boundary as standard on-request mode, but eligible approval requests are reviewed by Auto-review instead of surfacing to the user. |

271| Dangerous full access | `--dangerously-bypass-approvals-and-sandbox` (alias: `--yolo`) | <ElevatedRiskBadge /> No sandbox; no approvals _(not recommended)_ |

272

273For non-interactive runs, use `codex exec --sandbox workspace-write`; Codex keeps older `codex exec --full-auto` invocations as a deprecated compatibility path and prints a warning.

274

275With `--ask-for-approval untrusted`, Codex runs only known-safe read operations automatically. Commands that can mutate state or trigger external execution paths (for example, destructive Git operations or Git output/config-override flags) require approval.

276

277#### Configuration in `config.toml`

278

279For the broader configuration workflow, see [Config basics](https://developers.openai.com/codex/config-basic), [Advanced Config](https://developers.openai.com/codex/config-advanced#approval-policies-and-sandbox-modes), and the [Configuration Reference](https://developers.openai.com/codex/config-reference).

280

281```toml

282# Always ask for approval mode

283approval_policy = "untrusted"

284sandbox_mode = "read-only"

285allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

286

287# Optional: Allow network in workspace-write mode

288[sandbox_workspace_write]

289network_access = true

290

291# Optional: granular approval policy

292# approval_policy = { granular = {

293# sandbox_approval = true,

294# rules = true,

295# mcp_elicitations = true,

296# request_permissions = false,

297# skill_approval = false

298# } }

299```

300

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

302

303```toml

304[profiles.full_auto]

305approval_policy = "on-request"

306sandbox_mode = "workspace-write"

307

308[profiles.readonly_quiet]

309approval_policy = "never"

310sandbox_mode = "read-only"

311```

312

313### Test the sandbox locally

314

315To see what happens when a command runs under the Codex sandbox, use these Codex CLI commands:

316

317```bash

318# macOS

319codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...

320# Linux

321codex sandbox linux [--permissions-profile <name>] [COMMAND]...

322# Windows

323codex sandbox windows [--permissions-profile <name>] [COMMAND]...

324```

325

326The `sandbox` command is also available as `codex debug`, and the platform helpers have aliases (for example `codex sandbox seatbelt` and `codex sandbox landlock`).

327

328## OS-level sandbox

329

330Codex enforces the sandbox differently depending on your OS:

331

332- **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.

333- **Linux** uses `bwrap` plus `seccomp` by default.

334- **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.

335

336If 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:

337

338```json

339{

340 "chatgpt.runCodexInWindowsSubsystemForLinux": true

341}

342```

343

344This ensures the IDE extension inherits Linux sandbox semantics for commands, approvals, and filesystem access even when the host OS is Windows. Learn more in the [Windows setup guide](https://developers.openai.com/codex/windows).

345

346When running natively on Windows, configure the native sandbox mode in `config.toml`:

347

348```toml

349[windows]

350sandbox = "unelevated" # or "elevated"

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

352```

353

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

355

356When 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.

357

358In 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.

359

360### Run Codex in Dev Containers

361

362If 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.

363

364Use 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.

365

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

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

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

369 project can exfiltrate anything available inside the devcontainer, including

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

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

372

373The reference implementation includes:

374

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

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

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

378- persistent mounts for command history and Codex configuration;

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

380

381To try it:

382

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

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

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

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

387

388You can also start the container from the CLI:

389

390```bash

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

392```

393

394The example has three main pieces:

395

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

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

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

399

400The 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.

401

402Inside the container, choose one of these modes:

403

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

405- 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.

406

407## Version control

408

409Codex works best with a version control workflow:

410

411- Work on a feature branch and keep `git status` clean before delegating. This keeps Codex patches easier to isolate and revert.

412- Prefer patch-based workflows (for example, `git diff`/`git apply`) over editing tracked files directly. Commit frequently so you can roll back in small increments.

413- Treat Codex suggestions like any other PR: run targeted verification, review diffs, and document decisions in commit messages for auditing.

414

415## Monitoring and telemetry

416

417Codex supports opt-in monitoring via OpenTelemetry (OTel) to help teams audit usage, investigate issues, and meet compliance requirements without weakening local security defaults. Telemetry is off by default; enable it explicitly in your configuration.

418

419### Overview

420

421- Codex turns off OTel export by default to keep local runs self-contained.

422- When enabled, Codex emits structured log events covering conversations, API requests, SSE/WebSocket stream activity, user prompts (redacted by default), tool approval decisions, and tool results.

423- Codex tags exported events with `service.name` (originator), CLI version, and an environment label to separate dev/staging/prod traffic.

424

425### Enable OTel (opt-in)

426

427Add an `[otel]` block to your Codex configuration (typically `~/.codex/config.toml`), choosing an exporter and whether to log prompt text.

428

429```toml

430[otel]

431environment = "staging" # dev | staging | prod

432exporter = "none" # none | otlp-http | otlp-grpc

433log_user_prompt = false # redact prompt text unless policy allows

434```

435

436- `exporter = "none"` leaves instrumentation active but doesn't send data anywhere.

437- To send events to your own collector, pick one of:

438

439```toml

440[otel]

441exporter = { otlp-http = {

442 endpoint = "https://otel.example.com/v1/logs",

443 protocol = "binary",

444 headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

445}}

446```

447

448```toml

449[otel]

450exporter = { otlp-grpc = {

451 endpoint = "https://otel.example.com:4317",

452 headers = { "x-otlp-meta" = "abc123" }

453}}

454```

455

456Codex batches events and flushes them on shutdown. Codex exports only telemetry produced by its OTel module.

457

458### Event categories

459

460Representative event types include:

461

462- `codex.conversation_starts` (model, reasoning settings, sandbox/approval policy)

463- `codex.api_request` (attempt, status/success, duration, and error details)

464- `codex.sse_event` (stream event kind, success/failure, duration, plus token counts on `response.completed`)

465- `codex.websocket_request` and `codex.websocket_event` (request duration plus per-message kind/success/error)

466- `codex.user_prompt` (length; content redacted unless explicitly enabled)

467- `codex.tool_decision` (approved/denied, source: configuration vs. user)

468- `codex.tool_result` (duration, success, output snippet)

469

470Associated OTel metrics (counter plus duration histogram pairs) include `codex.api_request`, `codex.sse_event`, `codex.websocket.request`, `codex.websocket.event`, and `codex.tool.call` (with corresponding `.duration_ms` instruments).

471

472For the full event catalog and configuration reference, see the [Codex configuration documentation on GitHub](https://github.com/openai/codex/blob/main/docs/config.md#otel).

473

474### Security and privacy guidance

475

476- Keep `log_user_prompt = false` unless policy explicitly permits storing prompt contents. Prompts can include source code and sensitive data.

477- Route telemetry only to collectors you control; apply retention limits and access controls aligned with your compliance requirements.

478- Treat tool arguments and outputs as sensitive. Favor redaction at the collector or SIEM when possible.

479- Review local data retention settings (for example, `history.persistence` / `history.max_bytes`) if you don't want Codex to save session transcripts under `CODEX_HOME`. See [Advanced Config](https://developers.openai.com/codex/config-advanced#history-persistence) and [Configuration Reference](https://developers.openai.com/codex/config-reference).

480- If you run the CLI with network access turned off, OTel export can't reach your collector. To export, allow network access in `workspace-write` mode for the OTel endpoint, or export from Codex cloud with the collector domain on your approved list.

481- Review events periodically for approval/sandbox changes and unexpected tool executions.

482

483OTel is optional and designed to complement, not replace, the sandbox and approval protections described above.

484

485## Managed configuration

486

487Enterprise admins can configure Codex security settings for their workspace in [Managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration). See that page for setup and policy details.

agent-approvals-security.md Codex Docs, 2026-02-19 20:53 UTC → 2026-05-18 22:01 UTC