OpenAI - Codex Docs Changes 2026-02-23 18:27 UTC → 2026-05-18 22:01 UTC

1# Agent approvals & security

2 

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

4 

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

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.

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 

15## Sandbox and approvals

16 

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

18 

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

21 

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

23 

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.

26 

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.

28 

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.

30 

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

32 

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

34 

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.

36 

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:

38 

39```toml

40[sandbox_workspace_write]

41network_access = true

42```

43 

44### Network isolation

45 

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.

50 

51```toml

52[features.network_proxy]

53enabled = true

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

55```

56 

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:

59 

60```bash

61codex \

62 -c 'features.network_proxy=true' \

63 -c 'sandbox_workspace_write.network_access=true'

64 

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```

70 

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:

74 

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.

80 

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.

86 

87#### Network policy

88 

89Domain rules are allowlist-first:

90 

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.

98 

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.

4 4 

5ChatGPT Plus, Pro, Business, Edu, and Enterprise plans include Codex. Learn more about [what's included](https://developers.openai.com/codex/pricing).5ChatGPT Plus, Pro, Business, Edu, and Enterprise plans include Codex. Learn more about [what's included](https://developers.openai.com/codex/pricing).

6 6 

7![Codex app window with a project sidebar, active thread, and review pane](/images/codex/app/app-screenshot-light.webp)7<PlatformSpecificContent>

8 <CodexScreenshot

9 slot="windows"

10 alt="Codex app for Windows showing a project sidebar, active thread, and review pane"

11 lightSrc="/images/codex/windows/codex-windows-light.webp"

12 darkSrc="/images/codex/windows/codex-windows-dark.webp"

13 variant="no-wallpaper"

14 maxHeight="300px"

15 />

16 <CodexScreenshot

17 alt="Codex app window with a project sidebar, active thread, and review pane"

18 lightSrc="/images/codex/app/app-screenshot-light.webp"

19 darkSrc="/images/codex/app/app-screenshot-dark.webp"

20 variant="no-wallpaper"

21 maxHeight="300px"

22 />

23</PlatformSpecificContent>

8 24 

9## Getting started25## Getting started

10 26 

11The Codex app is available on macOS (Apple Silicon).27The Codex app is available on macOS and Windows.

12 28 

29Most Codex app features are available on both platforms. Platform-specific

30exceptions are noted in the relevant docs.

31 

32<WorkflowSteps variant="headings">

131. Download and install the Codex app331. Download and install the Codex app

14 34 

15 The Codex app is currently only available for macOS.35 Download the Codex app for macOS or Windows. Choose the Intel build if you're using an Intel-based Mac.

36 

37 <CodexAppDownloadCta client:load className="mb-4" />

16 38 

17 [Download for macOS](https://persistent.oaistatic.com/codex-app-prod/Codex.dmg)39 <div class="text-sm">

40 [Get notified for Linux](https://openai.com/form/codex-app/)

41 </div>

18 42 

19 [Get notified for Windows and Linux](https://openai.com/form/codex-app/)

202. Open Codex and sign in432. Open Codex and sign in

21 44 

22 Once you downloaded and installed the Codex app, open it and sign in with your ChatGPT account or an OpenAI API key.45 Once you downloaded and installed the Codex app, open it and sign in with your ChatGPT account or an OpenAI API key.

34 58 

35 You can ask Codex anything about the project or your computer in general. Here are some examples:59 You can ask Codex anything about the project or your computer in general. Here are some examples:

36 60 

37- Tell me about this project61 <ExampleGallery>

38- Build a classic Snake game in this repo.62 <ExampleTask

39- Find and fix bugs in my codebase with minimal, high-confidence changes.63 client:load

40 64 id="intro"

41 If you need more inspiration, check out the [explore section](https://developers.openai.com/codex/explore).65 prompt="Tell me about this project"

66 iconName="brain"

67 />

68 <ExampleTask

69 client:load

70 id="snake-game"

71 shortDescription="Build a classic Snake game in this repo."

72 prompt={[

73 "Build a classic Snake game in this repo.",

74 "",

75 "Scope & constraints:",

76 "- Implement ONLY the classic Snake loop: grid movement, growing snake, food spawn, score, game-over, restart.",

77 "- Reuse existing project tooling/frameworks; do NOT add new dependencies unless truly required.",

78 "- Keep UI minimal and consistent with the repo’s existing styles (no new design systems, no extra animations).",

79 "",

80 "Implementation plan:",

81 "1) Inspect the repo to find the right place to add a small interactive game (existing pages/routes/components).",

82 "2) Implement game state (snake positions, direction, food, score, tick timer) with deterministic, testable logic.",

83 "3) Render: simple grid + snake + food; support keyboard controls (arrow keys/WASD) and on-screen controls if mobile is present in the repo.",

84 "4) Add basic tests for the core game logic (movement, collisions, growth, food placement) if the repo has a test runner.",

85 "",

86 "Deliverables:",

87 "- A small set of files/changes with clear names.",

88 "- Short run instructions (how to start dev server + where to navigate).",

89 "- A brief checklist of what to manually verify (controls, pause/restart, boundaries).",

90 ].join("\n")}

91 iconName="gamepad"

92 />

93 <ExampleTask

94 client:load

95 id="fix-bugs"

96 shortDescription="Find and fix bugs in my codebase with minimal, high-confidence changes."

97 prompt={[

98 "Find and fix bugs in my codebase with minimal, high-confidence changes.",

99 "",

100 "Method (grounded + disciplined):",

101 "1) Reproduce: run tests/lint/build (or follow the existing repo scripts). If I provided an error, reproduce that exact failure.",

102 "2) Localize: identify the smallest set of files/lines involved (stack traces, failing tests, logs).",

103 "3) Fix: implement the minimal change that resolves the issue without refactors or unrelated cleanup.",

104 "4) Prove: add/update a focused test (or a tight repro) that fails before and passes after.",

105 "",

106 "Constraints:",

107 "- Do NOT invent errors or pretend to run commands you cannot run.",

108 "- No scope drift: no new features, no UI embellishments, no style overhauls.",

109 "- If information is missing, state what you can confirm from the repo and what remains unknown.",

110 "",

111 "Output:",

112 "- Summary (3–6 sentences max): what was broken, why, and the fix.",

113 "- Then ≤5 bullets: What changed, Where (paths), Evidence (tests/logs), Risks, Next steps.",

114 ].join("\n")}

115 iconName="search"

116 />

117 </ExampleGallery>

118 

119 If you need more inspiration, explore [Codex use cases](https://developers.openai.com/codex/use-cases).

120 If you're new to Codex, read the [best practices guide](https://developers.openai.com/codex/learn/best-practices).

121 

122</WorkflowSteps>

42 123 

43---124---

44 125 

45## Work with the Codex app126## Work with the Codex app

46 127 

47[### Multitask across projects128<BentoContainer class="mt-6">

129 <BentoContent href="/codex/app/features#multitask-across-projects">

130 

131### Multitask across projects

132 

133Run project threads side by side and switch between them quickly.

134 

135 </BentoContent>

136 <BentoContent href="/codex/app/worktrees">

137 

138### Worktrees

139 

140Keep parallel code changes isolated with built-in Git worktree support.

141 

142 </BentoContent>

143 <BentoContent href="/codex/remote-connections">

144 

145### Remote connections

146 

147Use the ChatGPT mobile app to start, steer, approve, and review Codex work on a

148connected host.

149 

150 </BentoContent>

151 <BentoContent href="/codex/app/computer-use">

152 

153### Computer use

154 

155Let Codex use macOS apps for GUI tasks, browser flows, and native app testing.

156 

157 </BentoContent>

158 <BentoContent href="/codex/app/review">

159 

160### Review and ship changes

161 

162Inspect diffs, address PR feedback, stage files, commit, and push.

163 

164 </BentoContent>

165 <BentoContent href="/codex/app/features#integrated-terminal">

166 

167### Terminal and actions

168 

169Run commands in each thread and launch repeatable project actions.

170 

171 </BentoContent>

172 <BentoContent href="/codex/app/browser">

173 

174### In-app browser

175 

176Open rendered pages, leave comments, or let Codex operate local browser flows.

177 

178 </BentoContent>

179 <BentoContent href="/codex/app/chrome-extension">

180 

181### Chrome extension

182 

183Add the Chrome plugin so Codex can use Chrome for signed-in browser tasks while you manage website approvals.

184 

185 </BentoContent>

186 <BentoContent href="/codex/app/features#image-generation">

187 

188### Image generation

189 

190Generate or edit images in a thread while you work on the surrounding code and assets.

191 

192 </BentoContent>

193 <BentoContent href="/codex/app/automations">

194 

195### Automations

196 

197Schedule recurring tasks, or wake up the same thread for ongoing checks.

198 

199 </BentoContent>

200 <BentoContent href="/codex/app/features#skills-support">

201 

202### Skills

203 

204Reuse instructions and workflows across the app, CLI, and IDE Extension.

205 

206 </BentoContent>

207 <BentoContent href="/codex/app/features#richer-outputs-and-artifacts">

48 208 

49Run multiple tasks in parallel and switch quickly between them.](https://developers.openai.com/codex/app/features#multitask-across-projects)[### Built-in Git tools209### Sidebar and artifacts

50 210 

51Review diffs, comment inline, stage or revert chunks, and commit without leaving the app.](https://developers.openai.com/codex/app/features#built-in-git-tools)[### Worktrees for parallel tasks211Follow plans, sources, task summaries, and generated file previews.

52 212 

53Isolate changes of multiple Codex threads using built-in Git worktree support.](https://developers.openai.com/codex/app/worktrees)[### Skills support213 </BentoContent>

214 <BentoContent href="/codex/plugins">

54 215 

55Give your Codex agent additional capabilities and reuse skills across App, CLI, and IDE Extension.](https://developers.openai.com/codex/app/features#skills-support)[### Automations216### Plugins

56 217 

57Pair skills with automations to automate recurring tasks in the background. Codex adds findings to the inbox, or automatically archives runs if there’s nothing to report.](https://developers.openai.com/codex/app/automations)[### Built-in terminal218Connect apps, skills, and MCP servers to extend what Codex can do.

58 219 

59Open a terminal per thread to test your changes, run dev servers, scripts, and custom commands.](https://developers.openai.com/codex/app/features#integrated-terminal)[### Local environments220 </BentoContent>

221 <BentoContent href="/codex/app/features#sync-with-the-ide-extension">

60 222 

61Define worktree setup scripts and common project actions for easy access.](https://developers.openai.com/codex/app/local-environments)[### Sync with the IDE extension223### IDE Extension sync

62 224 

63Share Auto Context and active threads across app and IDE sessions.](https://developers.openai.com/codex/app/features#sync-with-the-ide-extension)[### MCP support225Share Auto Context and active threads across app and IDE sessions.

64 226 

65Connect your Codex agent to additional services using MCP.](https://developers.openai.com/codex/app/features#mcp-support)227 </BentoContent>

228</BentoContainer>

66 229 

67---230---

68 231 

3Codex app-server is the interface Codex uses to power rich clients (for example, the Codex VS Code extension). Use it when you want a deep integration inside your own product: authentication, conversation history, approvals, and streamed agent events. The app-server implementation is open source in the Codex GitHub repository ([openai/codex/codex-rs/app-server](https://github.com/openai/codex/tree/main/codex-rs/app-server)). See the [Open Source](https://developers.openai.com/codex/open-source) page for the full list of open-source Codex components.3Codex app-server is the interface Codex uses to power rich clients (for example, the Codex VS Code extension). Use it when you want a deep integration inside your own product: authentication, conversation history, approvals, and streamed agent events. The app-server implementation is open source in the Codex GitHub repository ([openai/codex/codex-rs/app-server](https://github.com/openai/codex/tree/main/codex-rs/app-server)). See the [Open Source](https://developers.openai.com/codex/open-source) page for the full list of open-source Codex components.

4 4 

5If you are automating jobs or running Codex in CI, use the5If you are automating jobs or running Codex in CI, use the

6[Codex SDK](https://developers.openai.com/codex/sdk) instead.6 <a href="/codex/sdk">Codex SDK</a> instead.

7 7 

8## Protocol8## Protocol

9 9 

12Supported transports:12Supported transports:

13 13 

14- `stdio` (`--listen stdio://`, default): newline-delimited JSON (JSONL).14- `stdio` (`--listen stdio://`, default): newline-delimited JSON (JSONL).

15- `websocket` (`--listen ws://IP:PORT`, experimental): one JSON-RPC message per WebSocket text frame.15- `websocket` (`--listen ws://IP:PORT`, experimental and unsupported): one

16 16 JSON-RPC message per WebSocket text frame.

17In WebSocket mode, app-server uses bounded queues. When request ingress is full, the server rejects new requests with JSON-RPC error code `-32001` and message `"Server overloaded; retry later."` Clients should retry with an exponentially increasing delay and jitter.17- Unix socket (`--listen unix://` or `--listen unix://PATH`): WebSocket

18 connections over Codex's default app-server control socket or a custom Unix

19 socket path, using the standard HTTP Upgrade handshake.

20- `off` (`--listen off`): don't expose a local transport.

21 

22When you run with `--listen ws://IP:PORT`, the same listener also serves basic

23HTTP health probes:

24 

25- `GET /readyz` returns `200 OK` once the listener accepts new connections.

26- `GET /healthz` returns `200 OK` when the request doesn't include an `Origin`

27 header.

28- Requests with an `Origin` header are rejected with `403 Forbidden`.

29 

30WebSocket transport is experimental and unsupported. Local listeners such as

31`ws://127.0.0.1:PORT` are appropriate for localhost and SSH port-forwarding

32workflows. Non-loopback WebSocket listeners currently allow unauthenticated

33connections by default during rollout, so configure WebSocket auth before

34exposing one remotely.

35 

36Supported WebSocket auth flags:

37 

38- `--ws-auth capability-token --ws-token-file /absolute/path`

39- `--ws-auth capability-token --ws-token-sha256 HEX`

40- `--ws-auth signed-bearer-token --ws-shared-secret-file /absolute/path`

41 

42For signed bearer tokens, you can also set `--ws-issuer`, `--ws-audience`, and

43`--ws-max-clock-skew-seconds`. Clients present the credential as

44`Authorization: Bearer <token>` during the WebSocket handshake, and app-server

45enforces auth before JSON-RPC `initialize`.

46 

47Prefer `--ws-token-file` over passing raw bearer tokens on the command line. Use

48`--ws-token-sha256` only when the client keeps the raw high-entropy token in a

49separate local secret store; the hash is only a verifier, and clients still need

50the original token.

51 

52In WebSocket mode, app-server uses bounded queues. When request ingress is full,

53the server rejects new requests with JSON-RPC error code `-32001` and message

54`"Server overloaded; retry later."` Clients should retry with an exponentially

55increasing delay and jitter.

18 56 

19## Message schema57## Message schema

20 58 

21Requests include `method`, `params`, and `id`:59Requests include `method`, `params`, and `id`:

22 60 

23```json61```json

24{ "method": "thread/start", "id": 10, "params": { "model": "gpt-5.1-codex" } }62{ "method": "thread/start", "id": 10, "params": { "model": "gpt-5.4" } }

25```63```

26 64 

27Responses echo the `id` with either `result` or `error`:65Responses echo the `id` with either `result` or `error`:

49 87 

50## Getting started88## Getting started

51 89 

521. Start the server with `codex app-server` (default stdio transport) or `codex app-server --listen ws://127.0.0.1:4500` (experimental WebSocket transport).901. Start the server with `codex app-server` (default stdio transport),

91 `codex app-server --listen ws://127.0.0.1:4500` (TCP WebSocket), or

92 `codex app-server --listen unix://` (default Unix socket).

532. Connect a client over the selected transport, then send `initialize` followed by the `initialized` notification.932. Connect a client over the selected transport, then send `initialize` followed by the `initialized` notification.

543. Start a thread and a turn, then keep reading notifications from the active transport stream.943. Start a thread and a turn, then keep reading notifications from the active transport stream.

55 95 

56Example (Node.js / TypeScript):96Example (Node.js / TypeScript):

57 97 

58```ts98```ts

59import { spawn } from "node:child_process";99 

60import readline from "node:readline";100 

61 101 

62const proc = spawn("codex", ["app-server"], {102const proc = spawn("codex", ["app-server"], {

63 stdio: ["pipe", "pipe", "inherit"],103 stdio: ["pipe", "pipe", "inherit"],

99 },139 },

100});140});

101send({ method: "initialized", params: {} });141send({ method: "initialized", params: {} });

102send({ method: "thread/start", id: 1, params: { model: "gpt-5.1-codex" } });142send({ method: "thread/start", id: 1, params: { model: "gpt-5.4" } });

103```143```

104 144 

105## Core primitives145## Core primitives

116- **Start (or resume) a thread**: Call `thread/start` for a new conversation, `thread/resume` to continue an existing one, or `thread/fork` to branch history into a new thread id.156- **Start (or resume) a thread**: Call `thread/start` for a new conversation, `thread/resume` to continue an existing one, or `thread/fork` to branch history into a new thread id.

117- **Begin a turn**: Call `turn/start` with the target `threadId` and user input. Optional fields override model, personality, `cwd`, sandbox policy, and more.157- **Begin a turn**: Call `turn/start` with the target `threadId` and user input. Optional fields override model, personality, `cwd`, sandbox policy, and more.

118- **Steer an active turn**: Call `turn/steer` to append user input to the currently in-flight turn without creating a new turn.158- **Steer an active turn**: Call `turn/steer` to append user input to the currently in-flight turn without creating a new turn.

119- **Stream events**: After `turn/start`, keep reading notifications on stdout: `item/started`, `item/completed`, `item/agentMessage/delta`, tool progress, and other updates.159- **Stream events**: After `turn/start`, keep reading notifications on stdout: `thread/archived`, `thread/unarchived`, `item/started`, `item/completed`, `item/agentMessage/delta`, tool progress, and other updates.

120- **Finish the turn**: The server emits `turn/completed` with final status when the model finishes or after a `turn/interrupt` cancellation.160- **Finish the turn**: The server emits `turn/completed` with final status when the model finishes or after a `turn/interrupt` cancellation.

121 161 

122## Initialization162## Initialization

123 163 

124Clients must send a single `initialize` request per transport connection before invoking any other method on that connection, then acknowledge with an `initialized` notification. Requests sent before initialization receive a `Not initialized` error, and repeated `initialize` calls on the same connection return `Already initialized`.164Clients must send a single `initialize` request per transport connection before invoking any other method on that connection, then acknowledge with an `initialized` notification. Requests sent before initialization receive a `Not initialized` error, and repeated `initialize` calls on the same connection return `Already initialized`.

125 165 

126The server returns the user agent string it will present to upstream services. Set `clientInfo` to identify your integration.166The server returns the user agent string it will present to upstream services plus `platformFamily` and `platformOs` values that describe the runtime target. Set `clientInfo` to identify your integration.

127 167 

128`initialize.params.capabilities` also supports per-connection notification opt-out via `optOutNotificationMethods`, which is a list of exact method names to suppress for that connection. Matching is exact (no wildcards/prefixes). Unknown method names are accepted and ignored.168`initialize.params.capabilities` also supports per-connection notification opt-out via `optOutNotificationMethods`, which is a list of exact method names to suppress for that connection. Matching is exact (no wildcards/prefixes). Unknown method names are accepted and ignored.

129 169 

159 },199 },

160 "capabilities": {200 "capabilities": {

161 "experimentalApi": true,201 "experimentalApi": true,

162 "optOutNotificationMethods": [202 "optOutNotificationMethods": ["thread/started", "item/agentMessage/delta"]

163 "codex/event/session_configured",

164 "item/agentMessage/delta"

165 ]

166 }203 }

167 }204 }

168}205}

200 237 

201- `thread/start` - create a new thread; emits `thread/started` and automatically subscribes you to turn/item events for that thread.238- `thread/start` - create a new thread; emits `thread/started` and automatically subscribes you to turn/item events for that thread.

202- `thread/resume` - reopen an existing thread by id so later `turn/start` calls append to it.239- `thread/resume` - reopen an existing thread by id so later `turn/start` calls append to it.

203- `thread/fork` - fork a thread into a new thread id by copying stored history; emits `thread/started` for the new thread.240- `thread/fork` - fork a thread into a new thread id by copying stored history; emits `thread/started` for the new thread. Returned threads include `forkedFromId` when available.

204- `thread/read` - read a stored thread by id without resuming it; set `includeTurns` to return full turn history.241- `thread/read` - read a stored thread by id without resuming it; set `includeTurns` to return full turn history. Returned `thread` objects include runtime `status`.

205- `thread/list` - page through stored thread logs; supports cursor-based pagination plus `modelProviders`, `sourceKinds`, `archived`, and `cwd` filters.242- `thread/list` - page through stored thread logs; supports cursor-based pagination plus `modelProviders`, `sourceKinds`, `archived`, `cwd`, and `searchTerm` filters. Returned `thread` objects include runtime `status`.

243- `thread/turns/list` - page through a stored thread's turn history without resuming it. `itemsView` controls whether turn items are omitted, summarized, or fully loaded.

244- `thread/turns/items/list` - reserved for paged turn-item loading; currently returns unsupported.

206- `thread/loaded/list` - list the thread ids currently loaded in memory.245- `thread/loaded/list` - list the thread ids currently loaded in memory.

207- `thread/archive` - move a thread’s log file into the archived directory; returns `{}` on success.246- `thread/name/set` - set or update a thread's user-facing name for a loaded thread or a persisted rollout; emits `thread/name/updated`.

208- `thread/unarchive` - restore an archived thread rollout back into the active sessions directory; returns the restored `thread`.247- `thread/goal/set` - set the goal for a loaded thread (experimental; requires `capabilities.experimentalApi`); emits `thread/goal/updated`.

248- `thread/goal/get` - read the current goal for a loaded thread (experimental; requires `capabilities.experimentalApi`).

249- `thread/goal/clear` - clear the goal for a loaded thread (experimental; requires `capabilities.experimentalApi`); emits `thread/goal/cleared`.

250- `thread/metadata/update` - patch SQLite-backed stored thread metadata; currently supports persisted `gitInfo`.

251- `thread/archive` - move a thread's log file into the archived directory; returns `{}` on success and emits `thread/archived`.

252- `thread/unsubscribe` - unsubscribe this connection from thread turn/item events. If this was the last subscriber, the server unloads the thread after a no-subscriber inactivity grace period and emits `thread/closed`.

253- `thread/unarchive` - restore an archived thread rollout back into the active sessions directory; returns the restored `thread` and emits `thread/unarchived`.

254- `thread/status/changed` - notification emitted when a loaded thread's runtime `status` changes.

209- `thread/compact/start` - trigger conversation history compaction for a thread; returns `{}` immediately while progress streams via `turn/*` and `item/*` notifications.255- `thread/compact/start` - trigger conversation history compaction for a thread; returns `{}` immediately while progress streams via `turn/*` and `item/*` notifications.

256- `thread/shellCommand` - run a user-initiated shell command against a thread. This runs outside the sandbox with full access and doesn't inherit the thread sandbox policy.

257- `thread/backgroundTerminals/clean` - stop all running background terminals for a thread (experimental; requires `capabilities.experimentalApi`).

210- `thread/rollback` - drop the last N turns from the in-memory context and persist a rollback marker; returns the updated `thread`.258- `thread/rollback` - drop the last N turns from the in-memory context and persist a rollback marker; returns the updated `thread`.

211- `turn/start` - add user input to a thread and begin Codex generation; responds with the initial `turn` and streams events. For `collaborationMode`, `settings.developer_instructions: null` means "use built-in instructions for the selected mode."259- `turn/start` - add user input to a thread and begin Codex generation; responds with the initial `turn` and streams events. For `collaborationMode`, `settings.developer_instructions: null` means "use built-in instructions for the selected mode."

260- `thread/inject_items` - append raw Responses API items to a loaded thread's model-visible history without starting a user turn.

212- `turn/steer` - append user input to the active in-flight turn for a thread; returns the accepted `turnId`.261- `turn/steer` - append user input to the active in-flight turn for a thread; returns the accepted `turnId`.

213- `turn/interrupt` - request cancellation of an in-flight turn; success is `{}` and the turn ends with `status: "interrupted"`.262- `turn/interrupt` - request cancellation of an in-flight turn; success is `{}` and the turn ends with `status: "interrupted"`.

214- `review/start` - kick off the Codex reviewer for a thread; emits `enteredReviewMode` and `exitedReviewMode` items.263- `review/start` - kick off the Codex reviewer for a thread; emits `enteredReviewMode` and `exitedReviewMode` items.

215- `command/exec` - run a single command under the server sandbox without starting a thread/turn.264- `command/exec` - run a single command under the server sandbox without starting a thread/turn.

265- `command/exec/write` - write `stdin` bytes to a running `command/exec` session or close `stdin`.

266- `command/exec/resize` - resize a running PTY-backed `command/exec` session.

267- `command/exec/terminate` - stop a running `command/exec` session.

268- `command/exec/outputDelta` (notify) - emitted for base64-encoded stdout/stderr chunks from a streaming `command/exec` session.

269- `process/spawn` - start an explicit process session outside Codex's sandbox (experimental; requires `capabilities.experimentalApi`).

270- `process/writeStdin` - write stdin bytes to a running `process/spawn` session or close stdin (experimental).

271- `process/resizePty` - resize a running PTY-backed process session (experimental).

272- `process/kill` - terminate a running process session (experimental).

273- `process/outputDelta` and `process/exited` (notify) - emitted for streaming process output and process exit status (experimental).

216- `model/list` - list available models (set `includeHidden: true` to include entries with `hidden: true`) with effort options, optional `upgrade`, and `inputModalities`.274- `model/list` - list available models (set `includeHidden: true` to include entries with `hidden: true`) with effort options, optional `upgrade`, and `inputModalities`.

275- `modelProvider/capabilities/read` - read provider capability bounds for model/provider combinations (experimental; requires `capabilities.experimentalApi`).

217- `experimentalFeature/list` - list feature flags with lifecycle stage metadata and cursor pagination.276- `experimentalFeature/list` - list feature flags with lifecycle stage metadata and cursor pagination.

277- `experimentalFeature/enablement/set` - patch in-memory runtime settings for supported feature keys such as `apps` and `plugins`.

218- `collaborationMode/list` - list collaboration mode presets (experimental, no pagination).278- `collaborationMode/list` - list collaboration mode presets (experimental, no pagination).

219- `skills/list` - list skills for one or more `cwd` values (supports `forceReload` and optional `perCwdExtraUserRoots`).279- `skills/list` - list skills for one or more `cwd` values (supports `forceReload` and optional `perCwdExtraUserRoots`).

280- `skills/changed` (notify) - emitted when watched local skill files change.

281- `marketplace/add` - add a remote plugin marketplace and persist it into the user's marketplace config.

282- `marketplace/upgrade` - refresh a configured Git marketplace, or all configured Git marketplaces when you omit the marketplace name.

283- `plugin/list` - list discovered plugin marketplaces and plugin state, including install/auth policy metadata, marketplace load errors, featured plugin ids, and local, Git, or remote plugin source metadata.

284- `plugin/read` - read one plugin by marketplace path or remote marketplace name and plugin name, including bundled skills, apps, and MCP server names when those details are available.

285- `plugin/install` - install a plugin from a marketplace path or remote marketplace name.

286- `plugin/uninstall` - uninstall an installed plugin.

220- `app/list` - list available apps (connectors) with pagination plus accessibility/enabled metadata.287- `app/list` - list available apps (connectors) with pagination plus accessibility/enabled metadata.

221- `skills/config/write` - enable or disable skills by path.288- `skills/config/write` - enable or disable skills by path.

222- `mcpServer/oauth/login` - start an OAuth login for a configured MCP server; returns an authorization URL and emits `mcpServer/oauthLogin/completed` on completion.289- `mcpServer/oauth/login` - start an OAuth login for a configured MCP server; returns an authorization URL and emits `mcpServer/oauthLogin/completed` on completion.

223- `tool/requestUserInput` - prompt the user with 1-3 short questions for a tool call (experimental); questions can set `isOther` for a free-form option.290- `tool/requestUserInput` - prompt the user with 1-3 short questions for a tool call (experimental); questions can set `isOther` for a free-form option.

224- `config/mcpServer/reload` - reload MCP server configuration from disk and queue a refresh for loaded threads.291- `config/mcpServer/reload` - reload MCP server configuration from disk and queue a refresh for loaded threads.

225- `mcpServerStatus/list` - list MCP servers, tools, resources, and auth status (cursor + limit pagination).292- `mcpServerStatus/list` - list MCP servers, tools, resources, and auth status (cursor + limit pagination). Use `detail: "full"` for full data or `detail: "toolsAndAuthOnly"` to omit resources.

226- `feedback/upload` - submit a feedback report (classification + optional reason/logs + conversation id).293- `mcpServer/resource/read` - read a single MCP resource through an initialized MCP server.

294- `mcpServer/tool/call` - call a tool on a thread's configured MCP server.

295- `mcpServer/startupStatus/updated` (notify) - emitted when a configured MCP server's startup status changes for a loaded thread.

296- `windowsSandbox/setupStart` - start Windows sandbox setup for `elevated` or `unelevated` mode; returns quickly and later emits `windowsSandbox/setupCompleted`.

297- `feedback/upload` - submit a feedback report (classification + optional reason/logs + conversation id, plus optional `extraLogFiles` attachments).

227- `config/read` - fetch the effective configuration on disk after resolving configuration layering.298- `config/read` - fetch the effective configuration on disk after resolving configuration layering.

299- `externalAgentConfig/detect` - detect external-agent artifacts that can be migrated with `includeHome` and optional `cwds`; each detected item includes `cwd` (`null` for home).

300- `externalAgentConfig/import` - apply selected external-agent migration items by passing explicit `migrationItems` with `cwd` (`null` for home). Supported item types include config, skills, `AGENTS.md`, plugins, MCP server config, subagents, hooks, commands, and sessions; plugin imports emit `externalAgentConfig/import/completed`.

228- `config/value/write` - write a single configuration key/value to the user's `config.toml` on disk.301- `config/value/write` - write a single configuration key/value to the user's `config.toml` on disk.

229- `config/batchWrite` - apply configuration edits atomically to the user's `config.toml` on disk.302- `config/batchWrite` - apply configuration edits atomically to the user's `config.toml` on disk.

230- `configRequirements/read` - fetch requirements from `requirements.toml` and/or MDM, including allow-lists and residency requirements (or `null` if you haven’t set any up).303- `configRequirements/read` - fetch requirements from `requirements.toml` and/or MDM, including allow-lists, pinned `featureRequirements`, and residency/network requirements (or `null` if you haven't set any up).

304- `fs/readFile`, `fs/writeFile`, `fs/createDirectory`, `fs/getMetadata`, `fs/readDirectory`, `fs/remove`, `fs/copy`, `fs/watch`, `fs/unwatch`, and `fs/changed` (notify) - operate on absolute filesystem paths through the app-server v2 filesystem API.

305 

306Plugin summaries include a `source` union. Local plugins return

307`{ "type": "local", "path": ... }`, Git-backed marketplace entries return

308`{ "type": "git", "url": ..., "path": ..., "refName": ..., "sha": ... }`,

309and remote catalog entries return `{ "type": "remote" }`. For remote-only

310catalog entries, `PluginMarketplaceEntry.path` can be `null`; pass

311`remoteMarketplaceName` instead of `marketplacePath` when reading or installing

312those plugins.

231 313 

232## Models314## Models

233 315 

239{ "method": "model/list", "id": 6, "params": { "limit": 20, "includeHidden": false } }321{ "method": "model/list", "id": 6, "params": { "limit": 20, "includeHidden": false } }

240{ "id": 6, "result": {322{ "id": 6, "result": {

241 "data": [{323 "data": [{

242 "id": "gpt-5.2-codex",324 "id": "gpt-5.4",

243 "model": "gpt-5.2-codex",325 "model": "gpt-5.4",

244 "upgrade": "gpt-5.3-codex",326 "displayName": "GPT-5.4",

245 "displayName": "GPT-5.2 Codex",

246 "hidden": false,327 "hidden": false,

247 "defaultReasoningEffort": "medium",328 "defaultReasoningEffort": "medium",

248 "reasoningEffort": [{329 "supportedReasoningEfforts": [{

249 "effort": "low",330 "reasoningEffort": "low",

250 "description": "Lower latency"331 "description": "Lower latency"

251 }],332 }],

252 "inputModalities": ["text", "image"],333 "inputModalities": ["text", "image"],

259 340 

260Each model entry can include:341Each model entry can include:

261 342 

262- `reasoningEffort` - supported effort options for the model.343- `supportedReasoningEfforts` - supported effort options for the model.

263- `defaultReasoningEffort` - suggested default effort for clients.344- `defaultReasoningEffort` - suggested default effort for clients.

264- `upgrade` - optional recommended upgrade model id for migration prompts in clients.345- `upgrade` - optional recommended upgrade model id for migration prompts in clients.

346- `upgradeInfo` - optional upgrade metadata for migration prompts in clients.

265- `hidden` - whether the model is hidden from the default picker list.347- `hidden` - whether the model is hidden from the default picker list.

266- `inputModalities` - supported input types for the model (for example `text`, `image`).348- `inputModalities` - supported input types for the model (for example `text`, `image`).

267- `supportsPersonality` - whether the model supports personality-specific instructions such as `/personality`.349- `supportsPersonality` - whether the model supports personality-specific instructions such as `/personality`.

296## Threads378## Threads

297 379 

298- `thread/read` reads a stored thread without subscribing to it; set `includeTurns` to include turns.380- `thread/read` reads a stored thread without subscribing to it; set `includeTurns` to include turns.

299- `thread/list` supports cursor pagination plus `modelProviders`, `sourceKinds`, `archived`, and `cwd` filtering.381- `thread/turns/list` pages through a stored thread's turn history without

382 resuming it. Use `itemsView` to choose whether turn items are omitted,

383 summarized, or fully loaded.

384- `thread/list` supports cursor pagination plus `modelProviders`, `sourceKinds`, `archived`, `cwd`, and `searchTerm` filtering.

300- `thread/loaded/list` returns the thread IDs currently in memory.385- `thread/loaded/list` returns the thread IDs currently in memory.

301- `thread/archive` moves the thread's persisted JSONL log into the archived directory.386- `thread/archive` moves the thread's persisted JSONL log into the archived directory.

387- `thread/metadata/update` patches stored thread metadata, currently including persisted `gitInfo`.

388- `thread/unsubscribe` unsubscribes the current connection from a loaded thread and can trigger `thread/closed` after an inactivity grace period.

302- `thread/unarchive` restores an archived thread rollout back into the active sessions directory.389- `thread/unarchive` restores an archived thread rollout back into the active sessions directory.

303- `thread/compact/start` triggers compaction and returns `{}` immediately.390- `thread/compact/start` triggers compaction and returns `{}` immediately.

304- `thread/rollback` drops the last N turns from the in-memory context and records a rollback marker in the thread's persisted JSONL log.391- `thread/rollback` drops the last N turns from the in-memory context and records a rollback marker in the thread's persisted JSONL log.

392- `thread/inject_items` appends raw Responses API items to a loaded thread's model-visible history without starting a user turn.

305 393 

306### Start or resume a thread394### Start or resume a thread

307 395 

309 397 

310```json398```json

311{ "method": "thread/start", "id": 10, "params": {399{ "method": "thread/start", "id": 10, "params": {

312 "model": "gpt-5.1-codex",400 "model": "gpt-5.4",

313 "cwd": "/Users/me/project",401 "cwd": "/Users/me/project",

314 "approvalPolicy": "never",402 "approvalPolicy": "never",

315 "sandbox": "workspaceWrite",403 "sandbox": "workspaceWrite",

316 "personality": "friendly"404 "personality": "friendly",

405 "serviceName": "my_app_server_client"

317} }406} }

318{ "id": 10, "result": {407{ "id": 10, "result": {

319 "thread": {408 "thread": {

320 "id": "thr_123",409 "id": "thr_123",

410 "sessionId": "thr_123",

321 "preview": "",411 "preview": "",

412 "ephemeral": false,

322 "modelProvider": "openai",413 "modelProvider": "openai",

323 "createdAt": 1730910000414 "createdAt": 1730910000

324 }415 }

326{ "method": "thread/started", "params": { "thread": { "id": "thr_123" } } }417{ "method": "thread/started", "params": { "thread": { "id": "thr_123" } } }

327```418```

328 419 

420`serviceName` is optional. Set it when you want app-server to tag thread-level metrics with your integration's service name.

421 

422`thread.sessionId` identifies the current live session tree root. Root threads

423use their own thread id as the session id; forked threads keep the session id

424of the root they came from. Clients should read the session id from

425`thread.sessionId` instead of deriving it from the thread id.

426 

329To continue a stored session, call `thread/resume` with the `thread.id` you recorded earlier. The response shape matches `thread/start`. You can also pass the same configuration overrides supported by `thread/start`, such as `personality`:427To continue a stored session, call `thread/resume` with the `thread.id` you recorded earlier. The response shape matches `thread/start`. You can also pass the same configuration overrides supported by `thread/start`, such as `personality`:

330 428 

331```json429```json

333 "threadId": "thr_123",431 "threadId": "thr_123",

334 "personality": "friendly"432 "personality": "friendly"

335} }433} }

336{ "id": 11, "result": { "thread": { "id": "thr_123" } } }434{ "id": 11, "result": { "thread": { "id": "thr_123", "name": "Bug bash notes", "ephemeral": false } } }

337```435```

338 436 

339Resuming a thread doesn't update `thread.updatedAt` (or the rollout file's modified time) by itself. The timestamp updates when you start a turn.437Resuming a thread doesn't update `thread.updatedAt` (or the rollout file's modified time) by itself. The timestamp updates when you start a turn.

344 442 

345If you resume with a different model than the one recorded in the rollout, Codex emits a warning and applies a one-time model-switch instruction on the next turn.443If you resume with a different model than the one recorded in the rollout, Codex emits a warning and applies a one-time model-switch instruction on the next turn.

346 444 

445### Manage a thread goal

446 

447`thread/goal/set`, `thread/goal/get`, and `thread/goal/clear` are experimental

448and require `capabilities.experimentalApi = true` plus the `goals` feature. Use

449them for the same persisted goal state surfaced by `/goal` in the TUI.

450 

451```json

452{ "method": "thread/goal/set", "id": 13, "params": {

453 "threadId": "thr_123",

454 "objective": "Finish the migration and keep tests green",

455 "status": "active",

456 "tokenBudget": 40000

457} }

458{ "id": 13, "result": { "goal": {

459 "threadId": "thr_123",

460 "objective": "Finish the migration and keep tests green",

461 "status": "active",

462 "tokenBudget": 40000,

463 "tokensUsed": 0,

464 "timeUsedSeconds": 0

465} } }

466{ "method": "thread/goal/updated", "params": {

467 "threadId": "thr_123",

468 "goal": {

469 "threadId": "thr_123",

470 "objective": "Finish the migration and keep tests green",

471 "status": "active",

472 "tokenBudget": 40000,

473 "tokensUsed": 0,

474 "timeUsedSeconds": 0

475 }

476} }

477```

478 

479Goal objectives must be non-empty and at most 4,000 characters. Supplying a new

480objective replaces the goal and resets usage accounting. Supplying the current

481non-terminal objective, or omitting `objective`, updates status or token budget

482while preserving usage history.

483 

347To branch from a stored session, call `thread/fork` with the `thread.id`. This creates a new thread id and emits a `thread/started` notification for it:484To branch from a stored session, call `thread/fork` with the `thread.id`. This creates a new thread id and emits a `thread/started` notification for it:

348 485 

349```json486```json

350{ "method": "thread/fork", "id": 12, "params": { "threadId": "thr_123" } }487{ "method": "thread/fork", "id": 12, "params": { "threadId": "thr_123" } }

351{ "id": 12, "result": { "thread": { "id": "thr_456" } } }488{ "id": 12, "result": { "thread": { "id": "thr_456", "sessionId": "thr_123", "forkedFromId": "thr_123" } } }

352{ "method": "thread/started", "params": { "thread": { "id": "thr_456" } } }489{ "method": "thread/started", "params": { "thread": { "id": "thr_456" } } }

353```490```

354 491 

492When a user-facing thread title has been set, app-server hydrates `thread.name` on `thread/list`, `thread/read`, `thread/resume`, `thread/unarchive`, and `thread/rollback` responses. `thread/start` and `thread/fork` may omit `name` (or return `null`) until a title is set later.

493 

355### Read a stored thread (without resuming)494### Read a stored thread (without resuming)

356 495 

357Use `thread/read` when you want stored thread data but don't want to resume the thread or subscribe to its events.496Use `thread/read` when you want stored thread data but don't want to resume the thread or subscribe to its events.

358 497 

359- `includeTurns` - when `true`, the response includes the thread's turns; when `false` or omitted, you get the thread summary only.498- `includeTurns` - when `true`, the response includes the thread's turns; when `false` or omitted, you get the thread summary only.

499- Returned `thread` objects include runtime `status` (`notLoaded`, `idle`, `systemError`, or `active` with `activeFlags`).

360 500 

361```json501```json

362{ "method": "thread/read", "id": 19, "params": { "threadId": "thr_123", "includeTurns": true } }502{ "method": "thread/read", "id": 19, "params": { "threadId": "thr_123", "includeTurns": true } }

363{ "id": 19, "result": { "thread": { "id": "thr_123", "turns": [] } } }503{ "id": 19, "result": { "thread": { "id": "thr_123", "name": "Bug bash notes", "ephemeral": false, "status": { "type": "notLoaded" }, "turns": [] } } }

364```504```

365 505 

366Unlike `thread/resume`, `thread/read` doesn't load the thread into memory or emit `thread/started`.506Unlike `thread/resume`, `thread/read` doesn't load the thread into memory or emit `thread/started`.

367 507 

508### List thread turns

509 

510Use `thread/turns/list` to page a stored thread's turn history without resuming it. Results default to newest-first so clients can fetch older turns with `nextCursor`. The response also includes `backwardsCursor`; pass it as `cursor` with `sortDirection: "asc"` to fetch turns newer than the first item from the earlier page.

511 

512`itemsView` controls how much turn-item data the response includes:

513 

514- `notLoaded` omits items.

515- `summary` returns summarized item data and is the default when omitted.

516- `full` returns full item data.

517 

518```json

519{ "method": "thread/turns/list", "id": 20, "params": {

520 "threadId": "thr_123",

521 "limit": 50,

522 "sortDirection": "desc",

523 "itemsView": "summary"

524} }

525{ "id": 20, "result": {

526 "data": [],

527 "nextCursor": "older-turns-cursor-or-null",

528 "backwardsCursor": "newer-turns-cursor-or-null"

529} }

530```

531 

532`thread/turns/items/list` is reserved for paged turn-item loading, but the

533current server returns an unsupported-method error.

534 

368### List threads (with pagination & filters)535### List threads (with pagination & filters)

369 536 

370`thread/list` lets you render a history UI. Results default to newest-first by `createdAt`. Filters apply before pagination. Pass any combination of:537`thread/list` lets you render a history UI. Results default to newest-first by `createdAt`. Filters apply before pagination. Pass any combination of:

376- `sourceKinds` - restrict results to specific thread sources. When omitted or `[]`, the server defaults to interactive sources only: `cli` and `vscode`.543- `sourceKinds` - restrict results to specific thread sources. When omitted or `[]`, the server defaults to interactive sources only: `cli` and `vscode`.

377- `archived` - when `true`, list archived threads only. When `false` or omitted, list non-archived threads (default).544- `archived` - when `true`, list archived threads only. When `false` or omitted, list non-archived threads (default).

378- `cwd` - restrict results to threads whose session current working directory exactly matches this path.545- `cwd` - restrict results to threads whose session current working directory exactly matches this path.

546- `searchTerm` - search stored thread summaries and metadata before pagination.

379 547 

380`sourceKinds` accepts the following values:548`sourceKinds` accepts the following values:

381 549 

400} }568} }

401{ "id": 20, "result": {569{ "id": 20, "result": {

402 "data": [570 "data": [

403 { "id": "thr_a", "preview": "Create a TUI", "modelProvider": "openai", "createdAt": 1730831111, "updatedAt": 1730831111 },571 { "id": "thr_a", "preview": "Create a TUI", "ephemeral": false, "modelProvider": "openai", "createdAt": 1730831111, "updatedAt": 1730831111, "name": "TUI prototype", "status": { "type": "notLoaded" } },

404 { "id": "thr_b", "preview": "Fix tests", "modelProvider": "openai", "createdAt": 1730750000, "updatedAt": 1730750000 }572 { "id": "thr_b", "preview": "Fix tests", "ephemeral": true, "modelProvider": "openai", "createdAt": 1730750000, "updatedAt": 1730750000, "status": { "type": "notLoaded" } }

405 ],573 ],

406 "nextCursor": "opaque-token-or-null"574 "nextCursor": "opaque-token-or-null"

407} }575} }

409 577 

410When `nextCursor` is `null`, you have reached the final page.578When `nextCursor` is `null`, you have reached the final page.

411 579 

580### Update stored thread metadata

581 

582Use `thread/metadata/update` to patch stored thread metadata without resuming the thread. Today this supports persisted `gitInfo`; omitted fields are left unchanged, and explicit `null` clears a stored value.

583 

584```json

585{ "method": "thread/metadata/update", "id": 21, "params": {

586 "threadId": "thr_123",

587 "gitInfo": { "branch": "feature/sidebar-pr" }

588} }

589{ "id": 21, "result": {

590 "thread": {

591 "id": "thr_123",

592 "gitInfo": { "sha": null, "branch": "feature/sidebar-pr", "originUrl": null }

593 }

594} }

595```

596 

597### Track thread status changes

598 

599`thread/status/changed` is emitted whenever a loaded thread's runtime status changes. The payload includes `threadId` and the new `status`.

600 

601```json

602{

603 "method": "thread/status/changed",

604 "params": {

605 "threadId": "thr_123",

606 "status": { "type": "active", "activeFlags": ["waitingOnApproval"] }

607 }

608}

609```

610 

412### List loaded threads611### List loaded threads

413 612 

414`thread/loaded/list` returns thread IDs currently loaded in memory.613`thread/loaded/list` returns thread IDs currently loaded in memory.

418{ "id": 21, "result": { "data": ["thr_123", "thr_456"] } }617{ "id": 21, "result": { "data": ["thr_123", "thr_456"] } }

419```618```

420 619 

620### Unsubscribe from a loaded thread

621 

622`thread/unsubscribe` removes the current connection's subscription to a thread. The response status is one of:

623 

624- `unsubscribed` when the connection was subscribed and is now removed.

625- `notSubscribed` when the connection wasn't subscribed to that thread.

626- `notLoaded` when the thread isn't loaded.

627 

628If this was the last subscriber, the server keeps the thread loaded until it has no subscribers and no thread activity for 30 minutes. When the grace period expires, app-server unloads the thread and emits a `thread/status/changed` transition to `notLoaded` plus `thread/closed`.

629 

630```json

631{ "method": "thread/unsubscribe", "id": 22, "params": { "threadId": "thr_123" } }

632{ "id": 22, "result": { "status": "unsubscribed" } }

633```

634 

635If the thread later expires:

636 

637```json

638{ "method": "thread/status/changed", "params": {

639 "threadId": "thr_123",

640 "status": { "type": "notLoaded" }

641} }

642{ "method": "thread/closed", "params": { "threadId": "thr_123" } }

643```

644 

421### Archive a thread645### Archive a thread

422 646 

423Use `thread/archive` to move the persisted thread log (stored as a JSONL file on disk) into the archived sessions directory.647Use `thread/archive` to move the persisted thread log (stored as a JSONL file on disk) into the archived sessions directory.

425```json649```json

426{ "method": "thread/archive", "id": 22, "params": { "threadId": "thr_b" } }650{ "method": "thread/archive", "id": 22, "params": { "threadId": "thr_b" } }

427{ "id": 22, "result": {} }651{ "id": 22, "result": {} }

652{ "method": "thread/archived", "params": { "threadId": "thr_b" } }

428```653```

429 654 

430Archived threads won't appear in future calls to `thread/list` unless you pass `archived: true`.655Archived threads won't appear in future calls to `thread/list` unless you pass `archived: true`.

435 660 

436```json661```json

437{ "method": "thread/unarchive", "id": 24, "params": { "threadId": "thr_b" } }662{ "method": "thread/unarchive", "id": 24, "params": { "threadId": "thr_b" } }

438{ "id": 24, "result": { "thread": { "id": "thr_b" } } }663{ "id": 24, "result": { "thread": { "id": "thr_b", "name": "Bug bash notes" } } }

664{ "method": "thread/unarchived", "params": { "threadId": "thr_b" } }

439```665```

440 666 

441### Trigger thread compaction667### Trigger thread compaction

449{ "id": 25, "result": {} }675{ "id": 25, "result": {} }

450```676```

451 677 

678### Run a thread shell command

679 

680Use `thread/shellCommand` for user-initiated shell commands that belong to a thread. The request returns immediately with `{}` while progress streams through standard `turn/*` and `item/*` notifications.

681 

682This API runs outside the sandbox with full access and doesn't inherit the thread sandbox policy. Clients should expose it only for explicit user-initiated commands.

683 

684If the thread already has an active turn, the command runs as an auxiliary action on that turn and its formatted output is injected into the turn's message stream. If the thread is idle, app-server starts a standalone turn for the shell command.

685 

686```json

687{ "method": "thread/shellCommand", "id": 26, "params": { "threadId": "thr_b", "command": "git status --short" } }

688{ "id": 26, "result": {} }

689```

690 

691### Clean background terminals

692 

693Use `thread/backgroundTerminals/clean` to stop all running background terminals associated with a thread. This method is experimental and requires `capabilities.experimentalApi = true`.

694 

695```json

696{ "method": "thread/backgroundTerminals/clean", "id": 27, "params": { "threadId": "thr_b" } }

697{ "id": 27, "result": {} }

698```

699 

700### Roll back recent turns

701 

702Use `thread/rollback` to remove the last `numTurns` entries from the in-memory context and persist a rollback marker in the rollout log. The returned `thread` includes `turns` populated after the rollback.

703 

704```json

705{ "method": "thread/rollback", "id": 28, "params": { "threadId": "thr_b", "numTurns": 1 } }

706{ "id": 28, "result": { "thread": { "id": "thr_b", "name": "Bug bash notes", "ephemeral": false } } }

707```

708 

452## Turns709## Turns

453 710 

454The `input` field accepts a list of items:711The `input` field accepts a list of items:

478}735}

479```736```

480 737 

738On macOS, `includePlatformDefaults: true` appends a curated platform-default Seatbelt policy for restricted-read sessions. This improves tool compatibility without broadly allowing all of `/System`.

739 

481Examples:740Examples:

482 741 

483```json742```json

510 "writableRoots": ["/Users/me/project"],769 "writableRoots": ["/Users/me/project"],

511 "networkAccess": true770 "networkAccess": true

512 },771 },

513 "model": "gpt-5.1-codex",772 "model": "gpt-5.4",

514 "effort": "medium",773 "effort": "medium",

515 "summary": "concise",774 "summary": "concise",

516 "personality": "friendly",775 "personality": "friendly",

524{ "id": 30, "result": { "turn": { "id": "turn_456", "status": "inProgress", "items": [], "error": null } } }783{ "id": 30, "result": { "turn": { "id": "turn_456", "status": "inProgress", "items": [], "error": null } } }

525```784```

526 785 

786### Inject items into a thread

787 

788Use `thread/inject_items` to append prebuilt Responses API items to a loaded thread's prompt history without starting a user turn. These items are persisted to the rollout and included in subsequent model requests.

789 

790```json

791{ "method": "thread/inject_items", "id": 31, "params": {

792 "threadId": "thr_123",

793 "items": [

794 {

795 "type": "message",

796 "role": "assistant",

797 "content": [{ "type": "output_text", "text": "Previously computed context." }]

798 }

799 ]

800} }

801{ "id": 31, "result": {} }

802```

803 

527### Steer an active turn804### Steer an active turn

528 805 

529Use `turn/steer` to append more user input to the active in-flight turn.806Use `turn/steer` to append more user input to the active in-flight turn.

632 909 

633Use this notification to render the reviewer output in your client.910Use this notification to render the reviewer output in your client.

634 911 

912## Process execution

913 

914`process/*` is an experimental, explicit process-control API. It requires

915`capabilities.experimentalApi = true` and runs outside Codex's sandbox. Use it

916only when your client intentionally exposes local process control without a

917sandbox.

918 

919Start a process with `process/spawn` and provide a `processHandle`, then use

920that handle for stdin, resize, and kill requests. Output streams through

921`process/outputDelta` notifications and completion streams through

922`process/exited`.

923 

924```json

925{ "method": "process/spawn", "id": 48, "params": {

926 "command": ["python3", "-m", "pytest", "-q"],

927 "processHandle": "pytest-1",

928 "cwd": "/Users/me/project",

929 "tty": true

930} }

931{ "id": 48, "result": {} }

932{ "method": "process/outputDelta", "params": {

933 "processHandle": "pytest-1",

934 "stream": "stdout",

935 "deltaBase64": "Li4u"

936} }

937{ "method": "process/exited", "params": {

938 "processHandle": "pytest-1",

939 "exitCode": 0

940} }

941```

942 

943Use `process/writeStdin` with `deltaBase64`, `closeStdin`, or both to send

944input. Use `process/resizePty` for PTY resize events and `process/kill` to

945terminate a running process.

946 

635## Command execution947## Command execution

636 948 

637`command/exec` runs a single command (`argv` array) under the server sandbox without creating a thread.949`command/exec` runs a single command (`argv` array) under the server sandbox without creating a thread.

653- The server rejects empty `command` arrays.965- The server rejects empty `command` arrays.

654- `sandboxPolicy` accepts the same shape used by `turn/start` (for example, `dangerFullAccess`, `readOnly`, `workspaceWrite`, `externalSandbox`).966- `sandboxPolicy` accepts the same shape used by `turn/start` (for example, `dangerFullAccess`, `readOnly`, `workspaceWrite`, `externalSandbox`).

655- When omitted, `timeoutMs` falls back to the server default.967- When omitted, `timeoutMs` falls back to the server default.

968- Set `tty: true` for PTY-backed sessions, and use `processId` when you plan to follow up with `command/exec/write`, `command/exec/resize`, or `command/exec/terminate`.

969- Set `streamStdoutStderr: true` to receive `command/exec/outputDelta` notifications while the command is running.

970 

971### Read admin requirements (`configRequirements/read`)

972 

973Use `configRequirements/read` to inspect the effective admin requirements loaded from `requirements.toml` and/or MDM.

974 

975```json

976{ "method": "configRequirements/read", "id": 52, "params": {} }

977{ "id": 52, "result": {

978 "requirements": {

979 "allowedApprovalPolicies": ["onRequest", "unlessTrusted"],

980 "allowedSandboxModes": ["readOnly", "workspaceWrite"],

981 "featureRequirements": {

982 "personality": true,

983 "unified_exec": false

984 },

985 "network": {

986 "enabled": true,

987 "allowedDomains": ["api.openai.com"],

988 "allowUnixSockets": ["/tmp/example.sock"],

989 "dangerouslyAllowAllUnixSockets": false

990 }

991 }

992} }

993```

994 

995`result.requirements` is `null` when no requirements are configured. See the docs on [`requirements.toml`](https://developers.openai.com/codex/config-reference#requirementstoml) for details on supported keys and values.

996 

997### Windows sandbox setup (`windowsSandbox/setupStart`)

998 

999Custom Windows clients can trigger sandbox setup asynchronously instead of blocking on startup checks.

1000 

1001```json

1002{ "method": "windowsSandbox/setupStart", "id": 53, "params": { "mode": "elevated" } }

1003{ "id": 53, "result": { "started": true } }

1004```

1005 

1006App-server starts setup in the background and later emits a completion notification:

1007 

1008```json

1009{

1010 "method": "windowsSandbox/setupCompleted",

1011 "params": { "mode": "elevated", "success": true, "error": null }

1012}

1013```

1014 

1015Modes:

1016 

1017- `elevated` - run the elevated Windows sandbox setup path.

1018- `unelevated` - run the legacy setup/preflight path.

1019 

1020## Filesystem

1021 

1022The v2 filesystem APIs operate on absolute paths. Use `fs/watch` when a client needs to invalidate UI state after a file or directory changes.

1023 

1024```json

1025{ "method": "fs/watch", "id": 54, "params": {

1026 "watchId": "0195ec6b-1d6f-7c2e-8c7a-56f2c4a8b9d1",

1027 "path": "/Users/me/project/.git/HEAD"

1028} }

1029{ "id": 54, "result": { "path": "/Users/me/project/.git/HEAD" } }

1030{ "method": "fs/changed", "params": {

1031 "watchId": "0195ec6b-1d6f-7c2e-8c7a-56f2c4a8b9d1",

1032 "changedPaths": ["/Users/me/project/.git/HEAD"]

1033} }

1034{ "method": "fs/unwatch", "id": 55, "params": {

1035 "watchId": "0195ec6b-1d6f-7c2e-8c7a-56f2c4a8b9d1"

1036} }

1037{ "id": 55, "result": {} }

1038```

1039 

1040Watching a file emits `fs/changed` for that file path, including updates delivered by replace or rename operations.

656 1041 

657## Events1042## Events

658 1043 

659Event notifications are the server-initiated stream for thread lifecycles, turn lifecycles, and the items within them. After you start or resume a thread, keep reading the active transport stream for `thread/started`, `turn/*`, and `item/*` notifications.1044Event notifications are the server-initiated stream for thread lifecycles, turn lifecycles, and the items within them. After you start or resume a thread, keep reading the active transport stream for `thread/started`, `thread/archived`, `thread/unarchived`, `thread/closed`, `thread/status/changed`, `turn/*`, `item/*`, and `serverRequest/resolved` notifications.

660 1045 

661### Notification opt-out1046### Notification opt-out

662 1047 

664 1049 

665- Exact-match only: `item/agentMessage/delta` suppresses only that method.1050- Exact-match only: `item/agentMessage/delta` suppresses only that method.

666- Unknown method names are ignored.1051- Unknown method names are ignored.

667- Applies to both legacy (`codex/event/*`) and v2 (`thread/*`, `turn/*`, `item/*`, etc.) notifications.1052- Applies to the current `thread/*`, `turn/*`, `item/*`, and related v2 notifications.

668- Doesn't apply to requests, responses, or errors.1053- Doesn't apply to requests, responses, or errors.

669 1054 

670### Fuzzy file search events (experimental)1055### Fuzzy file search events (experimental)

674- `fuzzyFileSearch/sessionUpdated` - `{ sessionId, query, files }` with the current matches for the active query.1059- `fuzzyFileSearch/sessionUpdated` - `{ sessionId, query, files }` with the current matches for the active query.

675- `fuzzyFileSearch/sessionCompleted` - `{ sessionId }` once indexing and matching for that query completes.1060- `fuzzyFileSearch/sessionCompleted` - `{ sessionId }` once indexing and matching for that query completes.

676 1061 

1062### Windows sandbox setup events

1063 

1064- `windowsSandbox/setupCompleted` - `{ mode, success, error }` emitted after a `windowsSandbox/setupStart` request finishes.

1065 

677### Turn events1066### Turn events

678 1067 

679- `turn/started` - `{ turn }` with the turn id, empty `items`, and `status: "inProgress"`.1068- `turn/started` - `{ turn }` with the turn id, empty `items`, and `status: "inProgress"`.

689`ThreadItem` is the tagged union carried in turn responses and `item/*` notifications. Common item types include:1078`ThreadItem` is the tagged union carried in turn responses and `item/*` notifications. Common item types include:

690 1079 

691- `userMessage` - `{id, content}` where `content` is a list of user inputs (`text`, `image`, or `localImage`).1080- `userMessage` - `{id, content}` where `content` is a list of user inputs (`text`, `image`, or `localImage`).

692- `agentMessage` - `{id, text}` containing the accumulated agent reply.1081- `agentMessage` - `{id, text, phase?}` containing the accumulated agent reply. When present, `phase` uses Responses API wire values (`commentary`, `final_answer`).

693- `plan` - `{id, text}` containing proposed plan text in plan mode. Treat the final `plan` item from `item/completed` as authoritative.1082- `plan` - `{id, text}` containing proposed plan text in plan mode. Treat the final `plan` item from `item/completed` as authoritative.

694- `reasoning` - `{id, summary, content}` where `summary` holds streamed reasoning summaries and `content` holds raw reasoning blocks.1083- `reasoning` - `{id, summary, content}` where `summary` holds streamed reasoning summaries and `content` holds raw reasoning blocks.

695- `commandExecution` - `{id, command, cwd, status, commandActions, aggregatedOutput?, exitCode?, durationMs?}`.1084- `commandExecution` - `{id, command, cwd, status, commandActions, aggregatedOutput?, exitCode?, durationMs?}`.

696- `fileChange` - `{id, changes, status}` describing proposed edits; `changes` list `{path, kind, diff}`.1085- `fileChange` - `{id, changes, status}` describing proposed edits; `changes` list `{path, kind, diff}`.

697- `mcpToolCall` - `{id, server, tool, status, arguments, result?, error?}`.1086- `mcpToolCall` - `{id, server, tool, status, arguments, result?, error?}`.

1087- `dynamicToolCall` - `{id, tool, arguments, status, contentItems?, success?, durationMs?}` for client-executed dynamic tool invocations.

698- `collabToolCall` - `{id, tool, status, senderThreadId, receiverThreadId?, newThreadId?, prompt?, agentStatus?}`.1088- `collabToolCall` - `{id, tool, status, senderThreadId, receiverThreadId?, newThreadId?, prompt?, agentStatus?}`.

699- `webSearch` - `{id, query, action?}` for web search requests issued by the agent.1089- `webSearch` - `{id, query, action?}` for web search requests issued by the agent.

700- `imageView` - `{id, path}` emitted when the agent invokes the image viewer tool.1090- `imageView` - `{id, path}` emitted when the agent invokes the image viewer tool.

719- `item/reasoning/summaryPartAdded` - marks a boundary between reasoning summary sections.1109- `item/reasoning/summaryPartAdded` - marks a boundary between reasoning summary sections.

720- `item/reasoning/textDelta` - streams raw reasoning text (when supported by the model).1110- `item/reasoning/textDelta` - streams raw reasoning text (when supported by the model).

721- `item/commandExecution/outputDelta` - streams stdout/stderr for a command; append deltas in order.1111- `item/commandExecution/outputDelta` - streams stdout/stderr for a command; append deltas in order.

722- `item/fileChange/outputDelta` - contains the tool call response of the underlying `apply_patch` tool call.1112- `item/fileChange/outputDelta` - deprecated compatibility notification for legacy `apply_patch` text output. Current app-server versions no longer emit it; use `fileChange` items and `turn/diff/updated` instead.

723 1113 

724## Errors1114## Errors

725 1115 

751Order of messages:1142Order of messages:

752 1143 

7531. `item/started` shows the pending `commandExecution` item with `command`, `cwd`, and other fields.11441. `item/started` shows the pending `commandExecution` item with `command`, `cwd`, and other fields.

7542. `item/commandExecution/requestApproval` includes `itemId`, `threadId`, `turnId`, optional `reason`, optional `command`, optional `cwd`, optional `commandActions`, and optional `proposedExecpolicyAmendment`.11452. `item/commandExecution/requestApproval` includes `itemId`, `threadId`, `turnId`, optional `reason`, optional `command`, optional `cwd`, optional `commandActions`, optional `proposedExecpolicyAmendment`, optional `networkApprovalContext`, and optional `availableDecisions`. When `initialize.params.capabilities.experimentalApi = true`, the payload can also include experimental `additionalPermissions` describing requested per-command sandbox access. Any filesystem paths inside `additionalPermissions` are absolute on the wire.

7553. Client responds with one of the command execution approval decisions above.11463. Client responds with one of the command execution approval decisions above.

7564. `item/completed` returns the final `commandExecution` item with `status: completed | failed | declined`.11474. `serverRequest/resolved` confirms that the pending request has been answered or cleared.

11485. `item/completed` returns the final `commandExecution` item with `status: completed | failed | declined`.

1149 

1150When `networkApprovalContext` is present, the prompt is for managed network access (not a general shell-command approval). The current v2 schema exposes the target `host` and `protocol`; clients should render a network-specific prompt and not rely on `command` being a user-meaningful shell command preview.

1151 

1152Codex groups concurrent network approval prompts by destination (`host`, protocol, and port). The app-server may therefore send one prompt that unblocks multiple queued requests to the same destination, while different ports on the same host are treated separately.

757 1153 

758### File change approvals1154### File change approvals

759 1155 

7621. `item/started` emits a `fileChange` item with proposed `changes` and `status: "inProgress"`.11581. `item/started` emits a `fileChange` item with proposed `changes` and `status: "inProgress"`.

7632. `item/fileChange/requestApproval` includes `itemId`, `threadId`, `turnId`, optional `reason`, and optional `grantRoot`.11592. `item/fileChange/requestApproval` includes `itemId`, `threadId`, `turnId`, optional `reason`, and optional `grantRoot`.

7643. Client responds with one of the file change approval decisions above.11603. Client responds with one of the file change approval decisions above.

7654. `item/completed` returns the final `fileChange` item with `status: completed | failed | declined`.11614. `serverRequest/resolved` confirms that the pending request has been answered or cleared.

11625. `item/completed` returns the final `fileChange` item with `status: completed | failed | declined`.

1163 

1164### `tool/requestUserInput`

1165 

1166When the client responds to `item/tool/requestUserInput`, app-server emits `serverRequest/resolved` with `{ threadId, requestId }`. If the pending request is cleared by turn start, turn completion, or turn interruption before the client answers, the server emits the same notification for that cleanup.

1167 

1168### Dynamic tool calls (experimental)

1169 

1170`dynamicTools` on `thread/start` and the corresponding `item/tool/call` request or response flow are experimental APIs.

1171 

1172Dynamic tool names and namespace names must follow Responses API naming

1173constraints. Avoid reserved namespace names used by built-in Codex tools.

1174 

1175When a dynamic tool is invoked during a turn, app-server emits:

1176 

11771. `item/started` with `item.type = "dynamicToolCall"`, `status = "inProgress"`, plus `tool` and `arguments`.

11782. `item/tool/call` as a server request to the client.

11793. The client response payload with returned content items.

11804. `item/completed` with `item.type = "dynamicToolCall"`, the final `status`, and any returned `contentItems` or `success` value.

766 1181 

767### MCP tool-call approvals (apps)1182### MCP tool-call approvals (apps)

768 1183 

769App (connector) tool calls can also require approval. When an app tool call has side effects, the server may elicit approval with `tool/requestUserInput` and options such as **Accept**, **Decline**, and **Cancel**. If the user declines or cancels, the related `mcpToolCall` item completes with an error instead of running the tool.1184App (connector) tool calls can also require approval. When an app tool call has side effects, the server may elicit approval with `tool/requestUserInput` and options such as **Accept**, **Decline**, and **Cancel**. Destructive tool annotations always trigger approval even when the tool also advertises less-privileged hints. If the user declines or cancels, the related `mcpToolCall` item completes with an error instead of running the tool.

770 1185 

771## Skills1186## Skills

772 1187 

848} }1263} }

849```1264```

850 1265 

1266The server also emits `skills/changed` notifications when watched local skill files change. Treat this as an invalidation signal and rerun `skills/list` with your current params when needed.

1267 

851To enable or disable a skill by path:1268To enable or disable a skill by path:

852 1269 

853```json1270```json

863 1280 

864## Apps (connectors)1281## Apps (connectors)

865 1282 

866Use `app/list` to fetch available apps. In the CLI/TUI, `/apps` is the user-facing picker; in custom clients, call `app/list` directly. Each entry includes both `isAccessible` (available to the user) and `isEnabled` (enabled in `config.toml`) so clients can distinguish install/access from local enabled state.1283Use `app/list` to fetch available apps. In the CLI/TUI, `/apps` is the user-facing picker; in custom clients, call `app/list` directly. Each entry includes both `isAccessible` (available to the user) and `isEnabled` (enabled in `config.toml`) so clients can distinguish install/access from local enabled state. App entries can also include optional `branding`, `appMetadata`, and `labels` fields.

867 1284 

868```json1285```json

869{ "method": "app/list", "id": 50, "params": {1286{ "method": "app/list", "id": 50, "params": {

879 "name": "Demo App",1296 "name": "Demo App",

880 "description": "Example connector for documentation.",1297 "description": "Example connector for documentation.",

881 "logoUrl": "https://example.com/demo-app.png",1298 "logoUrl": "https://example.com/demo-app.png",

1299 "logoUrlDark": null,

1300 "distributionChannel": null,

1301 "branding": null,

1302 "appMetadata": null,

1303 "labels": null,

882 "installUrl": "https://chatgpt.com/apps/demo-app/demo-app",1304 "installUrl": "https://chatgpt.com/apps/demo-app/demo-app",

883 "isAccessible": true,1305 "isAccessible": true,

884 "isEnabled": true1306 "isEnabled": true

904 "name": "Demo App",1326 "name": "Demo App",

905 "description": "Example connector for documentation.",1327 "description": "Example connector for documentation.",

906 "logoUrl": "https://example.com/demo-app.png",1328 "logoUrl": "https://example.com/demo-app.png",

1329 "logoUrlDark": null,

1330 "distributionChannel": null,

1331 "branding": null,

1332 "appMetadata": null,

1333 "labels": null,

907 "installUrl": "https://chatgpt.com/apps/demo-app/demo-app",1334 "installUrl": "https://chatgpt.com/apps/demo-app/demo-app",

908 "isAccessible": true,1335 "isAccessible": true,

909 "isEnabled": true1336 "isEnabled": true

936}1363}

937```1364```

938 1365 

1366### Config RPC examples for app settings

1367 

1368Use `config/read`, `config/value/write`, and `config/batchWrite` to inspect or update app controls in `config.toml`.

1369 

1370Read the effective app config shape (including `_default` and per-tool overrides):

1371 

1372```json

1373{ "method": "config/read", "id": 60, "params": { "includeLayers": false } }

1374{ "id": 60, "result": {

1375 "config": {

1376 "apps": {

1377 "_default": {

1378 "enabled": true,

1379 "destructive_enabled": true,

1380 "open_world_enabled": true

1381 },

1382 "google_drive": {

1383 "enabled": true,

1384 "destructive_enabled": false,

1385 "default_tools_approval_mode": "prompt",

1386 "tools": {

1387 "files/delete": { "enabled": false, "approval_mode": "approve" }

1388 }

1389 }

1390 }

1391 }

1392} }

1393```

1394 

1395Update a single app setting:

1396 

1397```json

1398{

1399 "method": "config/value/write",

1400 "id": 61,

1401 "params": {