512 Commits

• Stabilize app list update ordering test (#14052)

  ## Summary
  - make
  `list_apps_waits_for_accessible_data_before_emitting_directory_updates`
  accept the two valid notification paths the server can emit
  - keep rejecting the real bug this test is meant to catch: a
  directory-only `app/list/updated` notification before accessible app
  data is available
  
  ## Why this fixes the flake
  The old test used a fixed `150ms` silence window and assumed the first
  notification after that window had to be the fully merged final update.
  In CI, scheduling occasionally lets accessible app data arrive before
  directory data, so the first valid notification can be an
  accessible-only interim update. That made the test fail even though the
  server behavior was correct.
  
  This change makes the test deterministic by reading notifications until
  the final merged payload arrives. Any interim update is only accepted if
  it contains accessible apps only; if the server ever emits inaccessible
  directory data before accessible data is ready, the test still fails
  immediately.
  
  ## Change type
  - test-only; no production app-list logic changes

  Ahmed Ibrahim · 2026-03-09 00:16:13 -07:00
  2bc3e52a91
• Add request permissions tool (#13092)

  Adds a built-in `request_permissions` tool and wires it through the
  Codex core, protocol, and app-server layers so a running turn can ask
  the client for additional permissions instead of relying on a static
  session policy.
  
  The new flow emits a `RequestPermissions` event from core, tracks the
  pending request by call ID, forwards it through app-server v2 as an
  `item/permissions/requestApproval` request, and resumes the tool call
  once the client returns an approved subset of the requested permission
  profile.

  Jack Mousseau · 2026-03-08 20:23:06 -07:00
  e6b93841c5
• app-server: include experimental skill metadata in exec approval requests (#13929)

  ## Summary
  
  This change surfaces skill metadata on command approval requests so
  app-server clients can tell when an approval came from a skill script
  and identify the originating `SKILL.md`.
  
  - add `skill_metadata` to exec approval events in the shared protocol
  - thread skill metadata through core shell escalation and delegated
  approval handling for skill-triggered approvals
  - expose the field in app-server v2 as experimental `skillMetadata`
  - regenerate the JSON/TypeScript schemas and cover the new field in
  protocol, transport, core, and TUI tests
  
  ## Why
  
  Skill-triggered approvals already carry skill context inside core, but
  app-server clients could not see which skill caused the prompt. Sending
  the skill metadata with the approval request makes it possible for
  clients to present better approval UX and connect the prompt back to the
  relevant skill definition.
  
  
  ## example event in app-server-v2
  verified that we see this event when experimental api is on:
  ```
  < {
  <   "id": 11,
  <   "method": "item/commandExecution/requestApproval",
  <   "params": {
  <     "additionalPermissions": {
  <       "fileSystem": null,
  <       "macos": {
  <         "accessibility": false,
  <         "automations": {
  <           "bundle_ids": [
  <             "com.apple.Notes"
  <           ]
  <         },
  <         "calendar": false,
  <         "preferences": "read_only"
  <       },
  <       "network": null
  <     },
  <     "approvalId": "25d600ee-5a3c-4746-8d17-e2e61fb4c563",
  <     "availableDecisions": [
  <       "accept",
  <       "acceptForSession",
  <       "cancel"
  <     ],
  <     "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <     "commandActions": [
  <       {
  <         "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <         "type": "unknown"
  <       }
  <     ],
  <     "cwd": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes",
  <     "itemId": "call_jZp3xFpNg4D8iKAD49cvEvZy",
  <     "skillMetadata": {
  <       "pathToSkillsMd": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/SKILL.md"
  <     },
  <     "threadId": "019ccc10-b7d3-7ff2-84fe-3a75e7681e69",
  <     "turnId": "019ccc10-b848-76f1-81b3-4a1fa225493f"
  <   }
  < }`
  ```
  
  & verified that this is the event when experimental api is off:
  ```
  < {
  <   "id": 13,
  <   "method": "item/commandExecution/requestApproval",
  <   "params": {
  <     "approvalId": "5fbbf776-261b-4cf8-899b-c125b547f2c0",
  <     "availableDecisions": [
  <       "accept",
  <       "acceptForSession",
  <       "cancel"
  <     ],
  <     "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <     "commandActions": [
  <       {
  <         "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <         "type": "unknown"
  <       }
  <     ],
  <     "cwd": "/Users/celia/code/codex/codex-rs",
  <     "itemId": "call_OV2DHzTgYcbYtWaTTBWlocOt",
  <     "threadId": "019ccc16-2a2b-7be1-8500-e00d45b892d4",
  <     "turnId": "019ccc16-2a8e-7961-98ec-649600e7d06a"
  <   }
  < }
  ```

  Celia Chen · 2026-03-08 18:07:46 -07:00
  340f9c9ecb
• Add in-process app server and wire up exec to use it (#14005)

  This is a subset of PR #13636. See that PR for a full overview of the
  architectural change.
  
  This PR implements the in-process app server and modifies the
  non-interactive "exec" entry point to use the app server.
  
  ---------
  
  Co-authored-by: Felipe Coury <felipe.coury@gmail.com>

  Eric Traut · 2026-03-08 18:43:55 -06:00
  da3689f0ef
• [app-server] Support hot-reload user config when batch writing config. (#13839)

  - [x] Support hot-reload user config when batch writing config.

  Matthew Zeng · 2026-03-08 17:38:01 -07:00
  a684a36091
• fix(ci): restore guardian coverage and bazel unit tests (#13912)

  ## Summary
  - restore the guardian review request snapshot test and its tracked
  snapshot after it was dropped from `main`
  - make Bazel Rust unit-test wrappers resolve runfiles correctly on
  manifest-only platforms like macOS and point Insta at the real workspace
  root
  - harden the shell-escalation socket-closure assertion so the musl Bazel
  test no longer depends on fd reuse behavior
  
  ## Verification
  - cargo test -p codex-core
  guardian_review_request_layout_matches_model_visible_request_snapshot
  - cargo test -p codex-shell-escalation
  - bazel test //codex-rs/exec:exec-unit-tests
  //codex-rs/shell-escalation:shell-escalation-unit-tests
  
  Supersedes #13894.
  
  ---------
  
  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>
  Co-authored-by: viyatb-oai <viyatb@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-08 12:05:19 -07:00
  7ba1fccfc1
• Stabilize abort task follow-up handling (#13874)

  - production logic plus tests; cancel running tasks before clearing
  pending turn state
  - suppress follow-up model requests after cancellation and assert on
  stabilized request counts instead of fixed sleeps

  Ahmed Ibrahim · 2026-03-07 22:56:00 -08:00
  dc19e78962
• feat: simplify DB further (#13771)
  jif-oai · 2026-03-07 03:48:36 -08:00
  cf143bf71e
• app-server: require absolute cwd for windowsSandbox/setupStart (#13833)

  ## Summary
  - require windowsSandbox/setupStart.cwd to be an AbsolutePathBuf
  - reject relative cwd values at request parsing instead of normalizing
  them later in the setup flow
  - add RPC-layer coverage for relative cwd rejection and update the
  checked-in protocol schemas/docs
  
  ## Why
  windowsSandbox/setupStart was carrying the client-provided cwd as a raw
  PathBuf for command_cwd while config derivation normalized the same
  value into an absolute policy_cwd.
  
  That left room for relative-path ambiguity in the setup path, especially
  for inputs like cwd: "repo". Making the RPC accept only absolute paths
  removes that split entirely: the handler now receives one
  already-validated absolute path and uses it for both config derivation
  and setup.
  
  This keeps the trust model unchanged. Trusted clients could already
  choose the session cwd; this change is only about making the setup RPC
  reject relative paths so command_cwd and policy_cwd cannot diverge.
  
  ## Testing
  - cargo test -p codex-app-server windows_sandbox_setup (run locally by
  user)
  - cargo test -p codex-app-server-protocol windows_sandbox (run locally
  by user)

  iceweasel-oai · 2026-03-06 22:47:08 -08:00
  4b4f61d379
• sandboxing: plumb split sandbox policies through runtime (#13439)

  ## Why
  
  `#13434` introduces split `FileSystemSandboxPolicy` and
  `NetworkSandboxPolicy`, but the runtime still made most execution-time
  sandbox decisions from the legacy `SandboxPolicy` projection.
  
  That projection loses information about combinations like unrestricted
  filesystem access with restricted network access. In practice, that
  means the runtime can choose the wrong platform sandbox behavior or set
  the wrong network-restriction environment for a command even when config
  has already separated those concerns.
  
  This PR carries the split policies through the runtime so sandbox
  selection, process spawning, and exec handling can consult the policy
  that actually matters.
  
  ## What changed
  
  - threaded `FileSystemSandboxPolicy` and `NetworkSandboxPolicy` through
  `TurnContext`, `ExecRequest`, sandbox attempts, shell escalation state,
  unified exec, and app-server exec overrides
  - updated sandbox selection in `core/src/sandboxing/mod.rs` and
  `core/src/exec.rs` to key off `FileSystemSandboxPolicy.kind` plus
  `NetworkSandboxPolicy`, rather than inferring behavior only from the
  legacy `SandboxPolicy`
  - updated process spawning in `core/src/spawn.rs` and the platform
  wrappers to use `NetworkSandboxPolicy` when deciding whether to set
  `CODEX_SANDBOX_NETWORK_DISABLED`
  - kept additional-permissions handling and legacy `ExternalSandbox`
  compatibility projections aligned with the split policies, including
  explicit user-shell execution and Windows restricted-token routing
  - updated callers across `core`, `app-server`, and `linux-sandbox` to
  pass the split policies explicitly
  
  ## Verification
  
  - added regression coverage in `core/tests/suite/user_shell_cmd.rs` to
  verify `RunUserShellCommand` does not inherit
  `CODEX_SANDBOX_NETWORK_DISABLED` from the active turn
  - added coverage in `core/src/exec.rs` for Windows restricted-token
  sandbox selection when the legacy projection is `ExternalSandbox`
  - updated Linux sandbox coverage in
  `linux-sandbox/tests/suite/landlock.rs` to exercise the split-policy
  exec path
  - verified the current PR state with `just clippy`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/13439).
  * #13453
  * #13452
  * #13451
  * #13449
  * #13448
  * #13445
  * #13440
  * __->__ #13439
  
  ---------
  
  Co-authored-by: viyatb-oai <viyatb@openai.com>

  Michael Bolin · 2026-03-07 02:30:21 +00:00
  22ac6b9aaa
• fix: support managed network allowlist controls (#12752)

  ## Summary
  - treat `requirements.toml` `allowed_domains` and `denied_domains` as
  managed network baselines for the proxy
  - in restricted modes by default, build the effective runtime policy
  from the managed baseline plus user-configured allowlist and denylist
  entries, so common hosts can be pre-approved without blocking later user
  expansion
  - add `experimental_network.managed_allowed_domains_only = true` to pin
  the effective allowlist to managed entries, ignore user allowlist
  additions, and hard-deny non-managed domains without prompting
  - apply `managed_allowed_domains_only` anywhere managed network
  enforcement is active, including full access, while continuing to
  respect denied domains from all sources
  - add regression coverage for merged-baseline behavior, managed-only
  behavior, and full-access managed-only enforcement
  
  ## Behavior
  Assuming `requirements.toml` defines both
  `experimental_network.allowed_domains` and
  `experimental_network.denied_domains`.
  
  ### Default mode
  - By default, the effective allowlist is
  `experimental_network.allowed_domains` plus user or persisted allowlist
  additions.
  - By default, the effective denylist is
  `experimental_network.denied_domains` plus user or persisted denylist
  additions.
  - Allowlist misses can go through the network approval flow.
  - Explicit denylist hits and local or private-network blocks are still
  hard-denied.
  - When `experimental_network.managed_allowed_domains_only = true`, only
  managed `allowed_domains` are respected, user allowlist additions are
  ignored, and non-managed domains are hard-denied without prompting.
  - Denied domains continue to be respected from all sources.
  
  ### Full access
  - With managed requirements present, the effective allowlist is pinned
  to `experimental_network.allowed_domains`.
  - With managed requirements present, the effective denylist is pinned to
  `experimental_network.denied_domains`.
  - There is no allowlist-miss approval path in full access.
  - Explicit denylist hits are hard-denied.
  - `experimental_network.managed_allowed_domains_only = true` now also
  applies in full access, so managed-only behavior remains in effect
  anywhere managed network enforcement is active.

  viyatb-oai · 2026-03-06 17:52:54 -08:00
  25fa974166
• app-server: Add streaming and tty/pty capabilities to command/exec (#13640)

  * Add an ability to stream stdin, stdout, and stderr
  * Streaming of stdout and stderr has a configurable cap for total amount
  of transmitted bytes (with an ability to disable it)
  * Add support for overriding environment variables
  * Add an ability to terminate running applications (using
  `command/exec/terminate`)
  * Add TTY/PTY support, with an ability to resize the terminal (using
  `command/exec/resize`)

  Ruslan Nigmatullin · 2026-03-06 17:30:17 -08:00
  e9bd8b20a1
• Allow full web search tool config (#13675)

  Previously, we could only configure whether web search was on/off.
  
  This PR enables sending along a web search config, which includes all
  the stuff responsesapi supports: filters, location, etc.

  Rohan Mehta · 2026-03-07 00:50:50 +00:00
  61098c7f51
• feat: Add curated plugin marketplace + Metadata Cleanup. (#13712)

  1. Add a synced curated plugin marketplace and include it in marketplace
  discovery.
  2. Expose optional plugin.json interface metadata in plugin/list
  3. Tighten plugin and marketplace path handling using validated absolute
  paths.
  4. Let manifests override skill, MCP, and app config paths.
  5. Restrict plugin enablement/config loading to the user config layer so
  plugin enablement is at global level

  xl-openai · 2026-03-06 19:39:35 -05:00
  0243734300
• feat: structured plugin parsing (#13711)

  #### What
  
  Add structured `@plugin` parsing and TUI support for plugin mentions.
  
  - Core: switch from plain-text `@display_name` parsing to structured
  `plugin://...` mentions via `UserInput::Mention` and
  `[$...](plugin://...)` links in text, same pattern as apps/skills.
  - TUI: add plugin mention popup, autocomplete, and chips when typing
  `$`. Load plugin capability summaries and feed them into the composer;
  plugin mentions appear alongside skills and apps.
  - Generalize mention parsing to a sigil parameter, still defaults to `$`
  
  <img width="797" height="119" alt="image"
  src="https://github.com/user-attachments/assets/f0fe2658-d908-4927-9139-73f850805ceb"
  />
  
  Builds on #13510. Currently clients have to build their own `id` via
  `plugin@marketplace` and filter plugins to show by `enabled`, but we
  will add `id` and `available` as fields returned from `plugin/list`
  soon.
  
  ####Tests
  
  Added tests, verified locally.

  sayan-oai · 2026-03-06 11:08:36 -08:00
  8a54d3caaa
• app-server: Emit thread/name/updated event globally (#13674)
  Ruslan Nigmatullin · 2026-03-06 10:25:18 -08:00
  51fcdc760d
• fix(app-server): fix turn_start_shell_zsh_fork_executes_command_v2 flake (#13770)

  This fixes a flaky `turn_start_shell_zsh_fork_executes_command_v2` test.
  
  The interrupt path can race with the follow-up `/responses` request that
  reports the aborted tool call, so the test now allows that extra no-op
  response instead of assuming there will only ever be one request. The
  assertions still stay focused on the behavior the test actually cares
  about: starting the zsh-forked command correctly.
  
  Testing:
  - `just fmt`
  - `cargo test -p codex-app-server --test all
  suite::v2::turn_start_zsh_fork::turn_start_shell_zsh_fork_executes_command_v2
  -- --exact --nocapture`

  Owen Lin · 2026-03-06 10:10:16 -08:00
  6c98a59dbd
• feat: drop sqlite db feature flag (#13750)
  jif-oai · 2026-03-06 17:57:52 +01:00
  fa16c26908
• [elicitations] Switch to use MCP style elicitation payload for mcp tool approvals. (#13621)

  - [x] Switch to use MCP style elicitation payload for mcp tool
  approvals.
  - [ ] TODO: Update the UI to support the full spec.

  Matthew Zeng · 2026-03-06 01:50:26 -08:00
  98dca99db7
• check app auth in plugin/install (#13685)

  #### What
  on `plugin/install`, check if installed apps are already authed on
  chatgpt, and return list of all apps that are not. clients can use this
  list to trigger auth workflows as needed.
  
  checks are best effort based on `codex_apps` loading, much like
  `app/list`.
  
  #### Tests
  Added integration tests, tested locally.

  sayan-oai · 2026-03-06 06:45:00 +00:00
  014a59fb0b
• refactor: remove proxy admin endpoint (#13687)

  ## Summary
  - delete the network proxy admin server and its runtime listener/task
  plumbing
  - remove the admin endpoint config, runtime, requirement, protocol,
  schema, and debug-surface fields
  - update proxy docs to reflect the remaining HTTP and SOCKS listeners
  only

  viyatb-oai · 2026-03-05 22:03:16 -08:00
  6a79ed5920
• support plugin/list. (#13540)

  Introduce a plugin/list which reads from local marketplace.json.
  Also update the signature for plugin/install.

  xl-openai · 2026-03-05 21:58:50 -05:00
  520ed724d2
• Refine realtime startup context formatting (#13560)

  ## Summary
  - group recent work by git repo when available, otherwise by directory
  - render recent work as bounded user asks with per-thread cwd context
  - exclude hidden files and directories from workspace trees

  Ahmed Ibrahim · 2026-03-05 16:31:20 -08:00
  6cf0ed4e79
• add @plugin mentions (#13510)

  ## Note-- added plugin mentions via @, but that conflicts with file
  mentions
  
  depends and builds upon #13433.
  
  - introduces explicit `@plugin` mentions. this injects the plugin's mcp
  servers, app names, and skill name format into turn context as a dev
  message.
  - we do not yet have UI for these mentions, so we currently parse raw
  text (as opposed to skills and apps which have UI chips, autocomplete,
  etc.) this depends on a `plugins/list` app-server endpoint we can feed
  the UI with, which is upcoming
  - also annotate mcp and app tool descriptions with the plugin(s) they
  come from. this gives the model a first class way of understanding what
  tools come from which plugins, which will help implicit invocation.
  
  ### Tests
  Added and updated tests, unit and integration. Also confirmed locally a
  raw `@plugin` injects the dev message, and the model knows about its
  apps, mcps, and skills.

  sayan-oai · 2026-03-06 00:03:39 +00:00
  4e77ea0ec7
• treat SIGTERM like ctrl-c for graceful shutdown (#13594)

  treat SIGTERM the same as SIGINT for graceful app-server websocket
  shutdown

  Max Johnson · 2026-03-05 18:16:58 +00:00
  1980b6ce00
• feat(app-server): support mcp elicitations in v2 api (#13425)

  This adds a first-class server request for MCP server elicitations:
  `mcpServer/elicitation/request`.
  
  Until now, MCP elicitation requests only showed up as a raw
  `codex/event/elicitation_request` event from core. That made it hard for
  v2 clients to handle elicitations using the same request/response flow
  as other server-driven interactions (like shell and `apply_patch`
  tools).
  
  This also updates the underlying MCP elicitation request handling in
  core to pass through the full MCP request (including URL and form data)
  so we can expose it properly in app-server.
  
  ### Why not `item/mcpToolCall/elicitationRequest`?
  This is because MCP elicitations are related to MCP servers first, and
  only optionally to a specific MCP tool call.
  
  In the MCP protocol, elicitation is a server-to-client capability: the
  server sends `elicitation/create`, and the client replies with an
  elicitation result. RMCP models it that way as well.
  
  In practice an elicitation is often triggered by an MCP tool call, but
  not always.
  
  ### What changed
  - add `mcpServer/elicitation/request` to the v2 app-server API
  - translate core `codex/event/elicitation_request` events into the new
  v2 server request
  - map client responses back into `Op::ResolveElicitation` so the MCP
  server can continue
  - update app-server docs and generated protocol schema
  - add an end-to-end app-server test that covers the full round trip
  through a real RMCP elicitation flow
  - The new test exercises a realistic case where an MCP tool call
  triggers an elicitation, the app-server emits
  mcpServer/elicitation/request, the client accepts it, and the tool call
  resumes and completes successfully.
  
  ### app-server API flow
  - Client starts a thread with `thread/start`.
  - Client starts a turn with `turn/start`.
  - App-server sends `item/started` for the `mcpToolCall`.
  - While that tool call is in progress, app-server sends
  `mcpServer/elicitation/request`.
  - Client responds to that request with `{ action: "accept" | "decline" |
  "cancel" }`.
  - App-server sends `serverRequest/resolved`.
  - App-server sends `item/completed` for the mcpToolCall.
  - App-server sends `turn/completed`.
  - If the turn is interrupted while the elicitation is pending,
  app-server still sends `serverRequest/resolved` before the turn
  finishes.

  Owen Lin · 2026-03-05 07:20:20 -08:00
  926b2f19e8
• [tui] Show speed in session header (#13446)

  - add a speed row to the startup/session header under the model row
  - render the speed row with the same styling pattern as the model row,
  using /fast to change
  - show only Fast or Standard to users and update the affected snapshots
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  pash-openai · 2026-03-05 00:00:16 -08:00
  1ce1712aeb
• chore: add web_search_tool_type for image support (#13538)

  add `web_search_tool_type` on model_info that can be populated from
  backend. will be used to filter which models can use `web_search` with
  images and which cant.
  
  added small unit test.

  sayan-oai · 2026-03-05 07:02:27 +00:00
  03d55f0e6f
• Preserve persisted thread git info in resume (#13504)

  ## Summary
  - ensure `thread.resume` reuses the stored `gitInfo` instead of
  rebuilding it from the live working tree
  - persist and apply thread git metadata through the resume flow and add
  a regression test covering branch mismatch cases
  
  ## Testing
  - Not run (not requested)

  joeytrasatti-openai · 2026-03-04 17:16:43 -08:00
  22f4113ac1
• plugin: support local-based marketplace.json + install endpoint. (#13422)

  Support marketplace.json that points to a local file, with
  ```
      "source":
      {
          "source": "local",
          "path": "./plugin-1"
      },
   ```
   
   Add a new plugin/install endpoint which add the plugin to the cache folder and enable it in config.toml.

  xl-openai · 2026-03-04 19:08:18 -05:00
  1e877ccdd2
• remove serviceTier from app-server examples (#13489)

  Documentation-only

  Val Kharitonov · 2026-03-04 19:12:40 +00:00
  26f4b8e2f1
• allow apps to specify cwd for sandbox setup. (#13484)

  The electron app doesn't start up the app-server in a particular
  workspace directory.
  So sandbox setup happens in the app-installed directory instead of the
  project workspace.
  
  This allows the app do specify the workspace cwd so that the sandbox
  setup actually sets up the ACLs instead of exiting fast and then having
  the first shell command be slow.

  iceweasel-oai · 2026-03-04 10:54:30 -08:00
  54a1c81d73
• support 'flex' tier in app-server in addition to 'fast' (#13391)
  Val Kharitonov · 2026-03-03 22:46:05 -08:00
  4f6c4bb143
• chore: Nest skill and protocol network permissions under network.enabled (#13427)

  ## Summary
  
  Changes the permission profile shape from a bare network boolean to a
  nested object.
  
  Before:
  
  ```yaml
  permissions:
    network: true
  ```
  
  After:
  
  ```yaml
  permissions:
    network:
      enabled: true
  ```
  
  This also updates the shared Rust and app-server protocol types so
  `PermissionProfile.network` is no longer `Option<bool>`, but
  `Option<NetworkPermissions>` with `enabled: Option<bool>`.
  
  ## What Changed
  
  - Updated `PermissionProfile` in `codex-rs/protocol/src/models.rs`:
  - `pub network: Option<bool>` -> `pub network:
  Option<NetworkPermissions>`
  - Added `NetworkPermissions` with:
    - `pub enabled: Option<bool>`
  - Changed emptiness semantics so `network` is only considered empty when
  `enabled` is `None`
  - Updated skill metadata parsing to accept `permissions.network.enabled`
  - Updated core permission consumers to read
  `network.enabled.unwrap_or(false)` where a concrete boolean is needed
  - Updated app-server v2 protocol types and regenerated schema/TypeScript
  outputs
  - Updated docs to mention `additionalPermissions.network.enabled`

  Celia Chen · 2026-03-03 20:57:29 -08:00
  d622bff384
• config: enforce enterprise feature requirements (#13388)

  ## Why
  
  Enterprises can already constrain approvals, sandboxing, and web search
  through `requirements.toml` and MDM, but feature flags were still only
  configurable as managed defaults. That meant an enterprise could suggest
  feature values, but it could not actually pin them.
  
  This change closes that gap and makes enterprise feature requirements
  behave like the other constrained settings. The effective feature set
  now stays consistent with enterprise requirements during config load,
  when config writes are validated, and when runtime code mutates feature
  flags later in the session.
  
  It also tightens the runtime API for managed features. `ManagedFeatures`
  now follows the same constraint-oriented shape as `Constrained<T>`
  instead of exposing panic-prone mutation helpers, and production code
  can no longer construct it through an unconstrained `From<Features>`
  path.
  
  The PR also hardens the `compact_resume_fork` integration coverage on
  Windows. After the feature-management changes,
  `compact_resume_after_second_compaction_preserves_history` was
  overflowing the libtest/Tokio thread stacks on Windows, so the test now
  uses an explicit larger-stack harness as a pragmatic mitigation. That
  may not be the ideal root-cause fix, and it merits a parallel
  investigation into whether part of the async future chain should be
  boxed to reduce stack pressure instead.
  
  ## What Changed
  
  Enterprises can now pin feature values in `requirements.toml` with the
  requirements-side `features` table:
  
  ```toml
  [features]
  personality = true
  unified_exec = false
  ```
  
  Only canonical feature keys are allowed in the requirements `features`
  table; omitted keys remain unconstrained.
  
  - Added a requirements-side pinned feature map to
  `ConfigRequirementsToml`, threaded it through source-preserving
  requirements merge and normalization in `codex-config`, and made the
  TOML surface use `[features]` (while still accepting legacy
  `[feature_requirements]` for compatibility).
  - Exposed `featureRequirements` from `configRequirements/read`,
  regenerated the JSON/TypeScript schema artifacts, and updated the
  app-server README.
  - Wrapped the effective feature set in `ManagedFeatures`, backed by
  `ConstrainedWithSource<Features>`, and changed its API to mirror
  `Constrained<T>`: `can_set(...)`, `set(...) -> ConstraintResult<()>`,
  and result-returning `enable` / `disable` / `set_enabled` helpers.
  - Removed the legacy-usage and bulk-map passthroughs from
  `ManagedFeatures`; callers that need those behaviors now mutate a plain
  `Features` value and reapply it through `set(...)`, so the constrained
  wrapper remains the enforcement boundary.
  - Removed the production loophole for constructing unconstrained
  `ManagedFeatures`. Non-test code now creates it through the configured
  feature-loading path, and `impl From<Features> for ManagedFeatures` is
  restricted to `#[cfg(test)]`.
  - Rejected legacy feature aliases in enterprise feature requirements,
  and return a load error when a pinned combination cannot survive
  dependency normalization.
  - Validated config writes against enterprise feature requirements before
  persisting changes, including explicit conflicting writes and
  profile-specific feature states that normalize into invalid
  combinations.
  - Updated runtime and TUI feature-toggle paths to use the constrained
  setter API and to persist or apply the effective post-constraint value
  rather than the requested value.
  - Updated the `core_test_support` Bazel target to include the bundled
  core model-catalog fixtures in its runtime data, so helper code that
  resolves `core/models.json` through runfiles works in remote Bazel test
  environments.
  - Renamed the core config test coverage to emphasize that effective
  feature values are normalized at runtime, while conflicting persisted
  config writes are rejected.
  - Ran `compact_resume_after_second_compaction_preserves_history` inside
  an explicit 8 MiB test thread and Tokio runtime worker stack, following
  the existing larger-stack integration-test pattern, to keep the Windows
  `compact_resume_fork` test slice from aborting while a parallel
  investigation continues into whether some of the underlying async
  futures should be boxed.
  
  ## Verification
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core feature_requirements_ -- --nocapture`
  - `cargo test -p codex-core
  load_requirements_toml_produces_expected_constraints -- --nocapture`
  - `cargo test -p codex-core
  compact_resume_after_second_compaction_preserves_history -- --nocapture`
  - `cargo test -p codex-core compact_resume_fork -- --nocapture`
  - Re-ran the built `codex-core` `tests/all` binary with
  `RUST_MIN_STACK=262144` for
  `compact_resume_after_second_compaction_preserves_history` to confirm
  the explicit-stack harness fixes the deterministic low-stack repro.
  - `cargo test -p codex-core`
  - This still fails locally in unrelated integration areas that expect
  the `codex` / `test_stdio_server` binaries or hit existing `search_tool`
  wiremock mismatches.
  
  ## Docs
  
  `developers.openai.com/codex` should document the requirements-side
  `[features]` table for enterprise and MDM-managed configuration,
  including that it only accepts canonical feature keys and that
  conflicting config writes are rejected.

  Michael Bolin · 2026-03-04 04:40:22 +00:00
  bfff0c729f
• [bazel] Bump rules_rs and llvm (#13366)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  zbarsky-openai · 2026-03-04 01:59:32 +00:00
  2d8c1575b8
• feat(app-server): add a skills/changed v2 notification (#13414)

  This adds a first-class app-server v2 `skills/changed` notification for
  the existing skills live-reload signal.
  
  Before this change, clients only had the legacy raw
  `codex/event/skills_update_available` event. With this PR, v2 clients
  can listen for a typed JSON-RPC notification instead of depending on the
  legacy `codex/event/*` stream, which we want to remove soon.

  Owen Lin · 2026-03-03 17:01:00 -08:00
  0fbd84081b
• Add under-development original-resolution view_image support (#13050)

  ## Summary
  
  Add original-resolution support for `view_image` behind the
  under-development `view_image_original_resolution` feature flag.
  
  When the flag is enabled and the target model is `gpt-5.3-codex` or
  newer, `view_image` now preserves original PNG/JPEG/WebP bytes and sends
  `detail: "original"` to the Responses API instead of using the legacy
  resize/compress path.
  
  ## What changed
  
  - Added `view_image_original_resolution` as an under-development feature
  flag.
  - Added `ImageDetail` to the protocol models and support for serializing
  `detail: "original"` on tool-returned images.
  - Added `PromptImageMode::Original` to `codex-utils-image`.
    - Preserves original PNG/JPEG/WebP bytes.
    - Keeps legacy behavior for the resize path.
  - Updated `view_image` to:
  - use the shared `local_image_content_items_with_label_number(...)`
  helper in both code paths
    - select original-resolution mode only when:
      - the feature flag is enabled, and
      - the model slug parses as `gpt-5.3-codex` or newer
  - Kept local user image attachments on the existing resize path; this
  change is specific to `view_image`.
  - Updated history/image accounting so only `detail: "original"` images
  use the docs-based GPT-5 image cost calculation; legacy images still use
  the old fixed estimate.
  - Added JS REPL guidance, gated on the same feature flag, to prefer JPEG
  at 85% quality unless lossless is required, while still allowing other
  formats when explicitly requested.
  - Updated tests and helper code that construct
  `FunctionCallOutputContentItem::InputImage` to carry the new `detail`
  field.
  
  ## Behavior
  
  ### Feature off
  - `view_image` keeps the existing resize/re-encode behavior.
  - History estimation keeps the existing fixed-cost heuristic.
  
  ### Feature on + `gpt-5.3-codex+`
  - `view_image` sends original-resolution images with `detail:
  "original"`.
  - PNG/JPEG/WebP source bytes are preserved when possible.
  - History estimation uses the GPT-5 docs-based image-cost calculation
  for those `detail: "original"` images.
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - 👉 `1` https://github.com/openai/codex/pull/13050
  - ⏳ `2` https://github.com/openai/codex/pull/13331
  - ⏳ `3` https://github.com/openai/codex/pull/13049

  Curtis 'Fjord' Hawthorne · 2026-03-03 15:56:54 -08:00
  b92146d48b
• Add thread metadata update endpoint to app server (#13280)

  ## Summary
  - add the v2 `thread/metadata/update` API, including
  protocol/schema/TypeScript exports and app-server docs
  - patch stored thread `gitInfo` in sqlite without resuming the thread,
  with validation plus support for explicit `null` clears
  - repair missing sqlite thread rows from rollout data before patching,
  and make those repairs safe by inserting only when absent and updating
  only git columns so newer metadata is not clobbered
  - keep sqlite authoritative for mutable thread git metadata by
  preserving existing sqlite git fields during reconcile/backfill and only
  using rollout `SessionMeta` git fields to fill gaps
  - add regression coverage for the endpoint, repair paths, concurrent
  sqlite writes, clearing git fields, and rollout/backfill reconciliation
  - fix the login server shutdown race so cancelling before the waiter
  starts still terminates `block_until_done()` correctly
  
  ## Testing
  - `cargo test -p codex-state
  apply_rollout_items_preserves_existing_git_branch_and_fills_missing_git_fields`
  - `cargo test -p codex-state
  update_thread_git_info_preserves_newer_non_git_metadata`
  - `cargo test -p codex-core
  backfill_sessions_preserves_existing_git_branch_and_fills_missing_git_fields`
  - `cargo test -p codex-app-server thread_metadata_update`
  - `cargo test`
  - currently fails in existing `codex-core` grep-files tests with
  `unsupported call: grep_files`:
      - `suite::grep_files::grep_files_tool_collects_matches`
      - `suite::grep_files::grep_files_tool_reports_empty_results`

  joeytrasatti-openai · 2026-03-03 15:56:11 -08:00
  935754baa3
• chore(app-server): delete v1 RPC methods and notifications (#13375)

  ## Summary
  This removes the old app-server v1 methods and notifications we no
  longer need, while keeping the small set the main codex app client still
  depends on for now.
  
  The remaining legacy surface is:
  - `initialize`
  - `getConversationSummary`
  - `getAuthStatus`
  - `gitDiffToRemote`
  - `fuzzyFileSearch`
  - `fuzzyFileSearch/sessionStart`
  - `fuzzyFileSearch/sessionUpdate`
  - `fuzzyFileSearch/sessionStop`
  
  And the raw `codex/event/*` notifications emitted from core. These
  notifications will be removed in a followup PR.
  
  ## What changed
  - removed deprecated v1 request variants from the protocol and
  app-server dispatcher
  - removed deprecated typed notifications: `authStatusChange`,
  `loginChatGptComplete`, and `sessionConfigured`
  - updated the app-server test client to use v2 flows instead of deleted
  v1 flows
  - deleted legacy-only app-server test suites and added focused coverage
  for `getConversationSummary`
  - regenerated app-server schema fixtures and updated the MCP interface
  docs to match the remaining compatibility surface
  
  ## Testing
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server`

  Owen Lin · 2026-03-03 13:18:25 -08:00
  167158f93c
• app-server: source /feedback logs from sqlite at trace level (#12969)

  ## Summary
  - write app-server SQLite logs at TRACE level when SQLite is enabled
  - source app-server `/feedback` log attachments from SQLite for the
  requested thread when available
  - flush buffered SQLite log writes before `/feedback` queries them so
  newly emitted events are not lost behind the async inserter
  - include same-process threadless SQLite rows in those `/feedback` logs
  so the attachment matches the process-wide feedback buffer more closely
  - keep the existing in-memory ring buffer fallback unchanged, including
  when the SQLite query returns no rows
  
  ## Details
  - add a byte-bounded `query_feedback_logs` helper in `codex-state` so
  `/feedback` does not fetch all rows before truncating
  - scope SQLite feedback logs to the requested thread plus threadless
  rows from the same `process_uuid`
  - format exported SQLite feedback lines with the log level prefix to
  better match the in-memory feedback formatter
  - add an explicit `LogDbLayer::flush()` control path and await it in
  app-server before querying SQLite for feedback logs
  - pass optional SQLite log bytes through `codex-feedback` as the
  `codex-logs.log` attachment override
  - leave TUI behavior unchanged apart from the updated `upload_feedback`
  call signature
  - add regression coverage for:
    - newest-within-budget ordering
    - excluding oversized newest rows
    - including same-process threadless rows
    - keeping the newest suffix across mixed thread and threadless rows
    - matching the feedback formatter shape aside from span prefixes
    - falling back to the in-memory snapshot when SQLite returns no logs
    - flushing buffered SQLite rows before querying
  
  ## Follow-up
  - SQLite feedback exports still do not reproduce span prefixes like
  `feedback-thread{thread_id=...}:`; there is a `TODO(ccunningham)` in
  `codex-rs/state/src/log_db.rs` for that follow-up.
  
  ## Testing
  - `cd codex-rs && cargo test -p codex-state`
  - `cd codex-rs && cargo test -p codex-app-server`
  - `cd codex-rs && just fmt`

  Charley Cunningham · 2026-03-03 11:17:06 -08:00
  c4bd0aa3b9
• app-server service tier plumbing (plus some cleanup) (#13334)

  followup to https://github.com/openai/codex/pull/13212 to expose fast
  tier controls to app server
  (majority of this PR is generated schema jsons - actual code is +69 /
  -35 and +24 tests )
  
  - add service tier fields to the app-server protocol surfaces used by
  thread lifecycle, turn start, config, and session configured events
  - thread service tier through the app-server message processor and core
  thread config snapshots
  - allow runtime config overrides to carry service tier for app-server
  callers
  
  cleanup:
  - Removing useless "legacy" code supporting "standard" - we moved to
  None | "fast", so "standard" is not needed.

  pash-openai · 2026-03-03 02:35:09 -08:00
  07e532dcb9
• add fast mode toggle (#13212)

  - add a local Fast mode setting in codex-core (similar to how model id
  is currently stored on disk locally)
  - send `service_tier=priority` on requests when Fast is enabled
  - add `/fast` in the TUI and persist it locally
  - feature flag

  pash-openai · 2026-03-02 20:29:33 -08:00
  2f5b01abd6
• app-server: Silence thread status changes caused by thread being created (#13079)

  Currently we emit `thread/status/changed` with `Idle` status right
  before sending `thread/started` event (which also has `Idle` status in
  it).
  It feels that there is no point in that as client has no way to know
  prior state of the thread as it didn't exist yet, so silence these kinds
  of notifications.

  Ruslan Nigmatullin · 2026-03-03 00:52:28 +00:00
  9022cdc563
• fix(app-server): emit turn/started only when turn actually starts (#13261)

  This is a follow-up for https://github.com/openai/codex/pull/13047
  
  ## Why
  We had a race where `turn/started` could be observed before the thread
  had actually transitioned to `Active`. This was because we eagerly
  emitted `turn/started` in the request handler for `turn/start` (and
  `review/start`).
  
  That was showing up as flaky `thread/resume` tests, but the real issue
  was broader: a client could see `turn/started` and still get back an
  idle thread immediately afterward.
  
  The first idea was to eagerly call
  `thread_watch_manager.note_turn_started(...)` from the `turn/start`
  request path. That turns out to be unsafe, because
  `submit(Op::UserInput)` only queues work. If a turn starts and completes
  quickly, request-path bookkeeping can race with the real lifecycle
  events and leave stale running state behind.
  
  **The real fix** is to move `turn/started` to emit only after the turn
  _actually_ starts, so we do that by waiting for the
  `EventMsg::TurnStarted` notification emitted by codex core. We do this
  for both `turn/start` and `review/start`.
  
  I also verified this change is safe for our first-party codex apps -
  they don't have any assumptions that `turn/started` is emitted before
  the RPC response to `turn/start` (which is correct anyway).
  
  I also removed `single_client_mode` since it isn't really necessary now.
  
  ## Testing
  - `cargo test -p codex-app-server thread_resume -- --nocapture`
  - `cargo test -p codex-app-server
  'suite::v2::turn_start::turn_start_emits_notifications_and_accepts_model_override'
  -- --exact --nocapture`
  - `cargo test -p codex-app-server`

  Owen Lin · 2026-03-02 16:43:31 -08:00
  146b798129
• Update realtime websocket API (#13265)

  - migrate the realtime websocket transport to the new session and
  handoff flow
  - make the realtime model configurable in config.toml and use API-key
  auth for the websocket
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-02 16:05:40 -08:00
  b20b6aa46f
• feat(app-server): add tracing to all app-server APIs (#13285)

  ### Overview
  This PR adds the first piece of tracing for app-server JSON-RPC
  requests.
  
  There are two main changes:
  - JSON-RPC requests can now take an optional W3C trace context at the
  top level via a `trace` field (`traceparent` / `tracestate`).
  - app-server now creates a dedicated request span for every inbound
  JSON-RPC request in `MessageProcessor`, and uses the request-level trace
  context as the parent when present.
  
  For compatibility with existing flows, app-server still falls back to
  the TRACEPARENT env var when there is no request-level traceparent.
  
  This PR is intentionally scoped to the app-server boundary. In a
  followup, we'll actually propagate trace context through the async
  handoff into core execution spans like run_turn, which will make
  app-server traces much more useful.
  
  ### Spans
  A few details on the app-server span shape:
  - each inbound request gets its own server span
  - span/resource names are based on the JSON-RPC method (`initialize`,
  `thread/start`, `turn/start`, etc.)
  - spans record transport (stdio vs websocket), request id, connection
  id, and client name/version when available
  - `initialize` stores client metadata in session state so later requests
  on the same connection can reuse it

  Owen Lin · 2026-03-02 16:01:41 -08:00
  d473e8d56d
• app-server: Update thread/name/set to support not-loaded threads (#13282)

  Currently `thread/name/set` does only work for loaded threads.
  Expand the scope to also support persisted but not-yet-loaded ones for a
  more predictable API surface.
  This will make it possible to rename threads discovered via
  `thread/list` and similar operations.

  Ruslan Nigmatullin · 2026-03-02 15:13:18 -08:00
  14fcb6645c
• test(app-server): increase flow test timeout to reduce flake (#11814)

  ## Summary
  - increase `DEFAULT_READ_TIMEOUT` in `codex_message_processor_flow` from
  20s to 45s
  - keep test behavior the same while avoiding platform timing flakes
  
  ## Why
  Windows ARM64 CI showed these tests taking about 24s before
  `task_complete`, which could fail early and produce wiremock
  request-count mismatches.
  
  ## Testing
  - just fmt
  - cargo test -p codex-app-server codex_message_processor_flow --
  --nocapture

  Josh McKinney · 2026-03-02 12:29:28 -08:00
  75e7c804ea
• feat: polluted memories (#13008)

  Add a feature flag to disable memory creation for "polluted"

  jif-oai · 2026-03-02 11:57:32 +00:00
  b649953845