agent-approvals-security diff

agent-approvals-security.md +253 −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).

14## Sandbox and approvals

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

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

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

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

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

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

26In the `Auto` preset (for example, `--full-auto`), Codex can read files, make edits, and run commands in the working directory automatically.

28Codex 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.

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

32## Network access [Elevated Risk](https://help.openai.com/articles/20001061)

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

36For 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:

38```toml

39[sandbox_workspace_write]

40network_access = true

41```

43You 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:

45```toml

46web_search = "cached" # default

47# web_search = "disabled"

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

49```

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

53## Defaults and recommendations

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

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

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

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

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

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

61- You can set these explicitly:

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

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

65### Protected paths in writable roots

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

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

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

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

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

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

75### Run without approval prompts

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

79This 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.

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

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

85### Common sandbox and approval combinations

87| Intent | Flags | Effect |

88| ----------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |

89| Auto (preset) | *no flags needed* or `--full-auto` | Codex can read files, make edits, and run commands in the workspace. Codex requires approval to edit outside the workspace or to access network. |

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

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

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

93| Dangerous full access | `--dangerously-bypass-approvals-and-sandbox` (alias: `--yolo`) | [Elevated Risk](https://help.openai.com/articles/20001061) No sandbox; no approvals *(not recommended)* |

95`--full-auto` is a convenience alias for `--sandbox workspace-write --ask-for-approval on-request`.

97With `--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.

99#### Configuration in `config.toml`

100

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

102

103```toml

104# Always ask for approval mode

105approval_policy = "untrusted"

106sandbox_mode = "read-only"

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

108

109# Optional: Allow network in workspace-write mode

110[sandbox_workspace_write]

111network_access = true

112

113# Optional: granular approval prompt auto-rejection

114# approval_policy = { reject = { sandbox_approval = true, rules = false, mcp_elicitations = false } }

115```

116

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

118

119```toml

120[profiles.full_auto]

121approval_policy = "on-request"

122sandbox_mode = "workspace-write"

123

124[profiles.readonly_quiet]

125approval_policy = "never"

126sandbox_mode = "read-only"

127```

128

129### Test the sandbox locally

130

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

132

133```bash

134# macOS

135codex sandbox macos [--full-auto] [--log-denials] [COMMAND]...

136# Linux

137codex sandbox linux [--full-auto] [COMMAND]...

138```

139

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

141

142## OS-level sandbox

143

144Codex enforces the sandbox differently depending on your OS:

145

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

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

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

149

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

151

152```json

153{

154 "chatgpt.runCodexInWindowsSubsystemForLinux": true

155}

156```

157

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

159

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

161

162```toml

163[windows]

164sandbox = "unelevated" # or "elevated"

165```

166

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

168

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

170

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

172

173## Version control

174

175Codex works best with a version control workflow:

176

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

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

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

180

181## Monitoring and telemetry

182

183Codex 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.

184

185### Overview

186

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

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

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

190

191### Enable OTel (opt-in)

192

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

194

195```toml

196[otel]

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

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

199log_user_prompt = false # redact prompt text unless policy allows

200```

201

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

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

204

205```toml

206[otel]

207exporter = { otlp-http = {

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

209 protocol = "binary",

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

211}}

212```

213

214```toml

215[otel]

216exporter = { otlp-grpc = {

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

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

219}}

220```

221

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

223

224### Event categories

225

226Representative event types include:

227

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

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

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

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

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

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

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

235

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

237

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

239

240### Security and privacy guidance

241

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

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

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

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

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

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

248

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

250

251## Managed configuration

252

253Enterprise 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-23 18:27 UTC → 2026-03-07 18:10 UTC