85 Commits

• Improve granular approval policy prompt (#14553)
  Jack Mousseau · 2026-03-13 10:42:17 -07:00
  59b588b8ec
• Rename reject approval policy to granular (#14516)
  Jack Mousseau · 2026-03-12 16:38:04 -07:00
  b7dba72dbd
• feat: search_tool migrate to bring you own tool of Responses API (#14274)

  ## Why
  
  to support a new bring your own search tool in Responses
  API(https://developers.openai.com/api/docs/guides/tools-tool-search#client-executed-tool-search)
  we migrating our bm25 search tool to use official way to execute search
  on client and communicate additional tools to the model.
  
  ## What
  - replace the legacy `search_tool_bm25` flow with client-executed
  `tool_search`
  - add protocol, SSE, history, and normalization support for
  `tool_search_call` and `tool_search_output`
  - return namespaced Codex Apps search results and wire namespaced
  follow-up tool calls back into MCP dispatch

  Anton Panasenko · 2026-03-11 17:51:51 -07:00
  77b0c75267
• Add realtime start instructions config override (#14270)

  - add `realtime_start_instructions` config support
  - thread it into realtime context updates, schema, docs, and tests

  Ahmed Ibrahim · 2026-03-11 12:33:09 -07:00
  39c1bc1c68
• chore: add a separate reject-policy flag for skill approvals (#14271)

  ## Summary
  - add `skill_approval` to `RejectConfig` and the app-server v2
  `AskForApproval::Reject` payload so skill-script prompts can be
  configured independently from sandbox and rule-based prompts
  - update Unix shell escalation to reject prompts based on the actual
  decision source, keeping prefix rules tied to `rules`, unmatched command
  fallbacks tied to `sandbox_approval`, and skill scripts tied to
  `skill_approval`
  - regenerate the affected protocol/config schemas and expand
  unit/integration coverage for the new flag and skill approval behavior

  Celia Chen · 2026-03-11 12:33:09 -07:00
  c1a424691f
• feat: Add additional macOS Sandbox Permissions for Launch Services, Contacts, Reminders (#14155)

  Add additional macOS Sandbox Permissions levers for the following:
  
  - Launch Services
  - Contacts
  - Reminders

  Leo Shimonaka · 2026-03-11 12:33:09 -07:00
  889b4796fc
• Add output schema to MCP tools and expose MCP tool results in code mode (#14236)

  Summary
  - drop `McpToolOutput` in favor of `CallToolResult`, moving its helpers
  to keep MCP tooling focused on the final result shape
  - wire the new schema definitions through code mode, context, handlers,
  and spec modules so MCP tools serialize the exact output shape expected
  by the model
  - extend code mode tests to cover multiple MCP call scenarios and ensure
  the serialized data matches the new schema
  - refresh JS runner helpers and protocol models alongside the schema
  changes
  
  Testing
  - Not run (not requested)

  pakrym-oai · 2026-03-11 12:33:08 -07:00
  ee8f84153e
• Reuse McpToolOutput in McpHandler (#14229)

  We already have a type to represent the MCP tool output, reuse it
  instead of the custom McpHandlerOutput

  pakrym-oai · 2026-03-11 12:33:07 -07:00
  c4d35084f5
• feat(approvals) RejectConfig for request_permissions (#14118)

  ## Summary
  We need to support allowing request_permissions calls when using
  `Reject` policy
  
  <img width="1133" height="588" alt="Screenshot 2026-03-09 at 12 06
  40 PM"
  src="https://github.com/user-attachments/assets/a8df987f-c225-4866-b8ab-5590960daec5"
  />
  
  Note that this is a backwards-incompatible change for Reject policy. I'm
  not sure if we need to add a default based on our current use/setup
  
  ## Testing
  - [x] Added tests
  - [x] Tested locally

  Dylan Hurd · 2026-03-09 18:16:54 -07:00
  6da84efed8
• guardian initial feedback / tweaks (#13897)

  ## Summary
  - remove the remaining model-visible guardian-specific `on-request`
  prompt additions so enabling the feature does not change the main
  approval-policy instructions
  - neutralize user-facing guardian wording to talk about automatic
  approval review / approval requests rather than a second reviewer or
  only sandbox escalations
  - tighten guardian retry-context handling so agent-authored
  `justification` stays in the structured action JSON and is not also
  injected as raw retry context
  - simplify guardian review plumbing in core by deleting dead
  prompt-append paths and trimming some request/transcript setup code
  
  ## Notable Changes
  - delete the dead `permissions/approval_policy/guardian.md` append path
  and stop threading `guardian_approval_enabled` through model-facing
  developer-instruction builders
  - rename the experimental feature copy to `Automatic approval review`
  and update the `/experimental` snapshot text accordingly
  - make approval-review status strings generic across shell, patch,
  network, and MCP review types
  - forward real sandbox/network retry reasons for shell and unified-exec
  guardian review, but do not pass agent-authored justification as raw
  retry context
  - simplify `guardian.rs` by removing the one-field request wrapper,
  deduping reasoning-effort selection, and cleaning up transcript entry
  collection
  
  ## Testing
  - `just fmt`
  - full validation left to CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-09 09:25:24 -07:00
  f23fcd6ced
• 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
• Add guardian approval MVP (#13692)

  ## Summary
  - add the guardian reviewer flow for `on-request` approvals in command,
  patch, sandbox-retry, and managed-network approval paths
  - keep guardian behind `features.guardian_approval` instead of exposing
  a public `approval_policy = guardian` mode
  - route ordinary `OnRequest` approvals to the guardian subagent when the
  feature is enabled, without changing the public approval-mode surface
  
  ## Public model
  - public approval modes stay unchanged
  - guardian is enabled via `features.guardian_approval`
  - when that feature is on, `approval_policy = on-request` keeps the same
  approval boundaries but sends those approval requests to the guardian
  reviewer instead of the user
  - `/experimental` only persists the feature flag; it does not rewrite
  `approval_policy`
  - CLI and app-server no longer expose a separate `guardian` approval
  mode in this PR
  
  ## Guardian reviewer
  - the reviewer runs as a normal subagent and reuses the existing
  subagent/thread machinery
  - it is locked to a read-only sandbox and `approval_policy = never`
  - it does not inherit user/project exec-policy rules
  - it prefers `gpt-5.4` when the current provider exposes it, otherwise
  falls back to the parent turn's active model
  - it fail-closes on timeout, startup failure, malformed output, or any
  other review error
  - it currently auto-approves only when `risk_score < 80`
  
  ## Review context and policy
  - guardian mirrors `OnRequest` approval semantics rather than
  introducing a separate approval policy
  - explicit `require_escalated` requests follow the same approval surface
  as `OnRequest`; the difference is only who reviews them
  - managed-network allowlist misses that enter the approval flow are also
  reviewed by guardian
  - the review prompt includes bounded recent transcript history plus
  recent tool call/result evidence
  - transcript entries and planned-action strings are truncated with
  explicit `<guardian_truncated ... />` markers so large payloads stay
  bounded
  - apply-patch reviews include the full patch content (without
  duplicating the structured `changes` payload)
  - the guardian request layout is snapshot-tested using the same
  model-visible Responses request formatter used elsewhere in core
  
  ## Guardian network behavior
  - the guardian subagent inherits the parent session's managed-network
  allowlist when one exists, so it can use the same approved network
  surface while reviewing
  - exact session-scoped network approvals are copied into the guardian
  session with protocol/port scope preserved
  - those copied approvals are now seeded before the guardian's first turn
  is submitted, so inherited approvals are available during any immediate
  review-time checks
  
  ## Out of scope / follow-ups
  - the sandbox-permission validation split was pulled into a separate PR
  and is not part of this diff
  - a future follow-up can enable `serde_json` preserve-order in
  `codex-core` and then simplify the guardian action rendering further
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-07 05:40:10 -08:00
  e84ee33cc0
• feat(app-server-protocol): address naming conflicts in json schema exporter (#13819)

  This fixes a schema export bug where two different `WebSearchAction`
  types were getting merged under the same name in the app-server v2 JSON
  schema bundle.
  
  The problem was that v2 thread items use the app-server API's
  `WebSearchAction` with camelCase variants like `openPage`, while
  `ThreadResumeParams.history` and
  `RawResponseItemCompletedNotification.item` pull in the upstream
  `ResponseItem` graph, which uses the Responses API snake_case shape like
  `open_page`. During bundle generation we were flattening nested
  definitions into the v2 namespace by plain name, so the later definition
  could silently overwrite the earlier one.
  
  That meant clients generating code from the bundled schema could end up
  with the wrong `WebSearchAction` definition for v2 thread history. In
  practice this shows up on web search items reconstructed from rollout
  files with persisted extended history.
  
  This change does two things:
  - Gives the upstream Responses API schema a distinct JSON schema name:
  `ResponsesApiWebSearchAction`
  - Makes namespace-level schema definition collisions fail loudly instead
  of silently overwriting

  Owen Lin · 2026-03-07 01:33:46 +00:00
  90469d0a23
• Clarify sandbox permission override helper semantics (#13703)

  ## Summary
  Today `SandboxPermissions::requires_additional_permissions()` does not
  actually mean "is `WithAdditionalPermissions`". It returns `true` for
  any non-default sandbox override, including `RequireEscalated`. That
  broad behavior is relied on in multiple `main` callsites.
  
  The naming is security-sensitive because `SandboxPermissions` is used on
  shell-like tool calls to tell the executor how a single command should
  relate to the turn sandbox:
  - `UseDefault`: run with the turn sandbox unchanged
  - `RequireEscalated`: request execution outside the sandbox
  - `WithAdditionalPermissions`: stay sandboxed but widen permissions for
  that command only
  
  ## Problem
  The old helper name reads as if it only applies to the
  `WithAdditionalPermissions` variant. In practice it means "this command
  requested any explicit sandbox override."
  
  That ambiguity made it easy to read production checks incorrectly and
  made the guardian change look like a standalone `main` fix when it is
  not.
  
  On `main` today:
  - `shell` and `unified_exec` intentionally reject any explicit
  `sandbox_permissions` request unless approval policy is `OnRequest`
  - `exec_policy` intentionally treats any explicit sandbox override as
  prompt-worthy in restricted sandboxes
  - tests intentionally serialize both `RequireEscalated` and
  `WithAdditionalPermissions` as explicit sandbox override requests
  
  So changing those callsites from the broad helper to a narrow
  `WithAdditionalPermissions` check would be a behavior change, not a pure
  cleanup.
  
  ## What This PR Does
  - documents `SandboxPermissions` as a per-command sandbox override, not
  a generic permissions bag
  - adds `requests_sandbox_override()` for the broad meaning: anything
  except `UseDefault`
  - adds `uses_additional_permissions()` for the narrow meaning: only
  `WithAdditionalPermissions`
  - keeps `requires_additional_permissions()` as a compatibility alias to
  the broad meaning for now
  - updates the current broad callsites to use the accurately named broad
  helper
  - adds unit coverage that locks in the semantics of all three helpers
  
  ## What This PR Does Not Do
  This PR does not change runtime behavior. That is intentional.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-06 09:57:48 -08:00
  cb1a182bbe
• fix: accept two macOS automation input shapes for approval payload compatibility (#13683)

  ## Summary
  This PR:
  1. fixes a deserialization mismatch for macOS automation permissions in
  approval payloads by making core parsing accept both supported wire
  shapes for bundle IDs.
  2. added `#[serde(default)]` to `MacOsSeatbeltProfileExtensions` so
  omitted fields deserialize to secure defaults.
  
  
  ## Why this change is needed
  `MacOsAutomationPermission` uses `#[serde(try_from =
  "MacOsAutomationPermissionDe")]`, so deserialization is controlled by
  `MacOsAutomationPermissionDe`. After we aligned v2
  `additionalPermissions.macos.automations` to the core shape, approval
  payloads started including `{ "bundle_ids": [...] }` in some paths.
  `MacOsAutomationPermissionDe` previously accepted only `"none" | "all"`
  or a plain array, so object-shaped bundle IDs failed with `data did not
  match any variant of untagged enum MacOsAutomationPermissionDe`. This
  change restores compatibility by accepting both forms while preserving
  existing normalization behavior (trim values and map empty bundle lists
  to `None`).
  
  ## Validation
  
  saw this error went away when running
  ```
  cargo run -p codex-app-server-test-client -- \
      --codex-bin ./target/debug/codex \
      -c 'approval_policy="on-request"' \
      -c 'features.shell_zsh_fork=true' \
      -c 'zsh_path="/tmp/codex-zsh-fork/package/vendor/aarch64-apple-darwin/zsh/macos-15/zsh"' \
      send-message-v2 --experimental-api \
      'Use $apple-notes and run scripts/notes_info now.'
  ```
  :
  ```
  Error: failed to deserialize ServerRequest from JSONRPCRequest
  
  Caused by:
      data did not match any variant of untagged enum MacOsAutomationPermissionDe
  ```

  Celia Chen · 2026-03-06 06:02:33 +00:00
  f9ce403b5a
• chore: remove unused legacy macOS permission types (#13677)

  ## Summary
  
  This PR removes legacy macOS permission model types from
  `codex-rs/protocol/src/models.rs`:
  
  - `MacOsPermissions`
  - `MacOsPreferencesValue`
  - `MacOsAutomationValue`
  
  The protocol now relies on the current `MacOsSeatbeltProfileExtensions`
  model for macOS permission data.

  Celia Chen · 2026-03-06 05:32:40 +00:00
  fb9fcf060f
• core/protocol: add structured macOS additional permissions and merge them into sandbox execution (#13499)

  ## Summary
  - Introduce strongly-typed macOS additional permissions across
  protocol/core/app-server boundaries.
  - Merge additional permissions into effective sandbox execution,
  including macOS seatbelt profile extensions.
  - Expand docs, schema/tool definitions, UI rendering, and tests for
  `network`, `file_system`, and `macos` additional permissions.

  Celia Chen · 2026-03-05 16:21:45 -08:00
  aaefee04cd
• image-gen-core (#13290)

  Core tool-calling for image-gen, handles requesting and receiving logic
  for images using response API

  Won Park · 2026-03-03 23:11:28 -08:00
  fa2306b303
• 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
• 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
• Record realtime close marker on replacement (#13058)

  ## Summary
  - record a realtime close developer message when a new realtime session
  replaces an active one
  - assert the replacement marker through the mocked responses request
  path
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: Charles Cunningham <ccunningham@openai.com>

  Ahmed Ibrahim · 2026-03-01 13:54:12 -08:00
  0aeb55bf08
• fix: use AbsolutePathBuf for permission profile file roots (#12970)

  ## Why
  `PermissionProfile` should describe filesystem roots as absolute paths
  at the type level. Using `PathBuf` in `FileSystemPermissions` made the
  shared type too permissive and blurred together three different
  deserialization cases:
  
  - skill metadata in `agents/openai.yaml`, where relative paths should
  resolve against the skill directory
  - app-server API payloads, where callers should have to send absolute
  paths
  - local tool-call payloads for commands like `shell_command` and
  `exec_command`, where `additional_permissions.file_system` may
  legitimately be relative to the command `workdir`
  
  This change tightens the shared model without regressing the existing
  local command flow.
  
  ## What Changed
  - changed `protocol::models::FileSystemPermissions` and the app-server
  `AdditionalFileSystemPermissions` mirror to use `AbsolutePathBuf`
  - wrapped skill metadata deserialization in `AbsolutePathBufGuard`, so
  relative permission roots in `agents/openai.yaml` resolve against the
  containing skill directory
  - kept app-server/API deserialization strict, so relative
  `additionalPermissions.fileSystem.*` paths are rejected at the boundary
  - restored cwd/workdir-relative deserialization for local tool-call
  payloads by parsing `shell`, `shell_command`, and `exec_command`
  arguments under an `AbsolutePathBufGuard` rooted at the resolved command
  working directory
  - simplified runtime additional-permission normalization so it only
  canonicalizes and deduplicates absolute roots instead of trying to
  recover relative ones later
  - updated the app-server schema fixtures, `app-server/README.md`, and
  the affected transport/TUI tests to match the final behavior

  Michael Bolin · 2026-02-27 17:42:52 +00:00
  d09a7535ed
• Support multimodal custom tool outputs (#12948)

  ## Summary
  
  This changes `custom_tool_call_output` to use the same output payload
  shape as `function_call_output`, so freeform tools can return either
  plain text or structured content items.
  
  The main goal is to let `js_repl` return image content from nested
  `view_image` calls in its own `custom_tool_call_output`, instead of
  relying on a separate injected message.
  
  ## What changed
  
  - Changed `custom_tool_call_output.output` from `string` to
  `FunctionCallOutputPayload`
  - Updated freeform tool plumbing to preserve structured output bodies
  - Updated `js_repl` to aggregate nested tool content items and attach
  them to the outer `js_repl` result
  - Removed the old `js_repl` special case that injected `view_image`
  results as a separate pending user image message
  - Updated normalization/history/truncation paths to handle multimodal
  `custom_tool_call_output`
  - Regenerated app-server protocol schema artifacts
  
  ## Behavior
  
  Direct `view_image` calls still return a `function_call_output` with
  image content.
  
  When `view_image` is called inside `js_repl`, the outer `js_repl`
  `custom_tool_call_output` now carries:
  - an `input_text` item if the JS produced text output
  - one or more `input_image` items from nested tool results
  
  So the nested image result now stays inside the `js_repl` tool output
  instead of being injected as a separate message.
  
  ## Compatibility
  
  This is intended to be backward-compatible for resumed conversations.
  
  Older histories that stored `custom_tool_call_output.output` as a plain
  string still deserialize correctly, and older histories that used the
  previous injected-image-message flow also continue to resume.
  
  Added regression coverage for resuming a pre-change rollout containing:
  - string-valued `custom_tool_call_output`
  - legacy injected image message history
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - 👉 `1` https://github.com/openai/codex/pull/12948

  Curtis 'Fjord' Hawthorne · 2026-02-26 18:17:46 -08:00
  7e980d7db6
• feat: include sandbox config with escalation request (#12839)

  ## Why
  
  Before this change, an escalation approval could say that a command
  should be rerun, but it could not carry the sandbox configuration that
  should still apply when the escalated command is actually spawned.
  
  That left an unsafe gap in the `zsh-fork` skill path: skill scripts
  under `scripts/` that did not declare permissions could be escalated
  without a sandbox, and scripts that did declare permissions could lose
  their bounded sandbox on rerun or cached session approval.
  
  This PR extends the escalation protocol so approvals can optionally
  carry sandbox configuration all the way through execution. That lets the
  shell runtime preserve the intended sandbox instead of silently widening
  access.
  
  We likely want a single permissions type for this codepath eventually,
  probably centered on `Permissions`. For now, the protocol needs to
  represent both the existing `PermissionProfile` form and the fuller
  `Permissions` form, so this introduces a temporary disjoint union,
  `EscalationPermissions`, to carry either one.
  
  Further, this means that today, a skill either:
  
  - does not declare any permissions, in which case it is run using the
  default sandbox for the turn
  - specifies permissions, in which case the skill is run using that exact
  sandbox, which might be more restrictive than the default sandbox for
  the turn
  
  We will likely change the skill's permissions to be additive to the
  existing permissions for the turn.
  
  ## What Changed
  
  - Added `EscalationPermissions` to `codex-protocol` so escalation
  requests can carry either a `PermissionProfile` or a full `Permissions`
  payload.
  - Added an explicit `EscalationExecution` mode to the shell escalation
  protocol so reruns distinguish between `Unsandboxed`, `TurnDefault`, and
  `Permissions(...)` instead of overloading `None`.
  - Updated `zsh-fork` shell reruns to resolve `TurnDefault` at execution
  time, which keeps ordinary `UseDefault` commands on the turn sandbox and
  preserves turn-level macOS seatbelt profile extensions.
  - Updated the `zsh-fork` skill path so a skill with no declared
  permissions inherits the conversation's effective sandbox instead of
  escalating unsandboxed.
  - Updated the `zsh-fork` skill path so a skill with declared permissions
  reruns with exactly those permissions, including when a cached session
  approval is reused.
  
  ## Testing
  
  - Added unit coverage in
  `core/src/tools/runtimes/shell/unix_escalation.rs` for the explicit
  `UseDefault` / `RequireEscalated` / `WithAdditionalPermissions`
  execution mapping.
  - Added unit coverage in
  `core/src/tools/runtimes/shell/unix_escalation.rs` for macOS seatbelt
  extension preservation in both the `TurnDefault` and
  explicit-permissions rerun paths.
  - Added integration coverage in `core/tests/suite/skill_approval.rs` for
  permissionless skills inheriting the turn sandbox and explicit skill
  permissions remaining bounded across cached approval reuse.

  Michael Bolin · 2026-02-26 12:00:18 -08:00
  7fa9d9ae35
• chore: migrate additional permissions to PermissionProfile (#12731)

  This PR replaces the old `additional_permissions.fs_read/fs_write` shape
  with a shared `PermissionProfile`
  model and wires it through the command approval, sandboxing, protocol,
  and TUI layers. The schema is adopted from the
  `SkillManifestPermissions`, which is also refactored to use this unified
  struct. This helps us easily expose permission profiles in app
  server/core as a follow-up.

  Celia Chen · 2026-02-25 03:35:28 +00:00
  16ca527c80
• feat(core) Introduce Feature::RequestPermissions (#11871)

  ## Summary
  Introduces the initial implementation of Feature::RequestPermissions.
  RequestPermissions allows the model to request that a command be run
  inside the sandbox, with additional permissions, like writing to a
  specific folder. Eventually this will include other rules as well, and
  the ability to persist these permissions, but this PR is already quite
  large - let's get the core flow working and go from there!
  
  <img width="1279" height="541" alt="Screenshot 2026-02-15 at 2 26 22 PM"
  src="https://github.com/user-attachments/assets/0ee3ec0f-02ec-4509-91a2-809ac80be368"
  />
  
  ## Testing
  - [x] Added tests
  - [x] Tested locally
  - [x] Feature

  Dylan Hurd · 2026-02-24 09:48:57 -08:00
  f6053fdfb3
• feat: add Reject approval policy with granular prompt rejection controls (#12087)

  ## Why
  
  We need a way to auto-reject specific approval prompt categories without
  switching all approvals off.
  
  The goal is to let users independently control:
  - sandbox escalation approvals,
  - execpolicy `prompt` rule approvals,
  - MCP elicitation prompts.
  
  ## What changed
  
  - Added a new primary approval mode in `protocol/src/protocol.rs`:
  
  ```rust
  pub enum AskForApproval {
      // ...
      Reject(RejectConfig),
      // ...
  }
  
  pub struct RejectConfig {
      pub sandbox_approval: bool,
      pub rules: bool,
      pub mcp_elicitations: bool,
  }
  ```
  
  - Wired `RejectConfig` semantics through approval paths in `core`:
    - `core/src/exec_policy.rs`
      - rejects rule-driven prompts when `rules = true`
      - rejects sandbox/escalation prompts when `sandbox_approval = true`
  - preserves rule priority when both rule and sandbox prompt conditions
  are present
    - `core/src/tools/sandboxing.rs`
  - applies `sandbox_approval` to default exec approval decisions and
  sandbox-failure retry gating
    - `core/src/safety.rs`
  - keeps `Reject { all false }` behavior aligned with `OnRequest` for
  patch safety
      - rejects out-of-root patch approvals when `sandbox_approval = true`
    - `core/src/mcp_connection_manager.rs`
      - auto-declines MCP elicitations when `mcp_elicitations = true`
  
  - Ensured approval policy used by MCP elicitation flow stays in sync
  with constrained session policy updates.
  
  - Updated app-server v2 conversions and generated schema/TypeScript
  artifacts for the new `Reject` shape.
  
  ## Verification
  
  Added focused unit coverage for the new behavior in:
  - `core/src/exec_policy.rs`
  - `core/src/tools/sandboxing.rs`
  - `core/src/mcp_connection_manager.rs`
  - `core/src/safety.rs`
  - `core/src/tools/runtimes/apply_patch.rs`
  
  Key cases covered include rule-vs-sandbox prompt precedence, MCP
  auto-decline behavior, and patch/sandbox retry behavior under
  `RejectConfig`.

  Michael Bolin · 2026-02-19 11:41:49 -08:00
  425fff7ad6
• chore(core) rm Feature::RequestRule (#11866)

  ## Summary
  This feature is now reasonably stable, let's remove it so we can
  simplify our upcoming iterations here.
  
  ## Testing 
  - [x] Existing tests pass

  Dylan Hurd · 2026-02-16 22:30:23 +00:00
  19afbc35c1
• fix(protocol): make local image test Bazel-friendly (#11799)

  Fixes Bazel build failure in //codex-rs/protocol:protocol-unit-tests.
  
  The test used include_bytes! to read a PNG from codex-core assets; Cargo
  can read it,
  but Bazel sandboxing can't, so the crate fails to compile.
  
  This change inlines a tiny valid PNG in the test to keep it hermetic.
  
  Related regression: #10590 (cc: @charley-oai)

  Josh McKinney · 2026-02-14 00:53:15 +00:00
  067f8b1be0
• tui: preserve remote image attachments across resume/backtrack (#10590)

  ## Summary
  This PR makes app-server-provided image URLs first-class attachments in
  TUI, so they survive resume/backtrack/history recall and are resubmitted
  correctly.
  
  <img width="715" height="491" alt="Screenshot 2026-02-12 at 8 27 08 PM"
  src="https://github.com/user-attachments/assets/226cbd35-8f0c-4e51-a13e-459ef5dd1927"
  />
  
  Can delete the attached image upon backtracking:
  <img width="716" height="301" alt="Screenshot 2026-02-12 at 8 27 31 PM"
  src="https://github.com/user-attachments/assets/4558d230-f1bd-4eed-a093-8e1ab9c6db27"
  />
  
  In both history and composer, remote images are rendered as normal
  `[Image #N]` placeholders, with numbering unified with local images.
  
  ## What changed
  - Plumb remote image URLs through TUI message state:
    - `UserHistoryCell`
    - `BacktrackSelection`
    - `ChatComposerHistory::HistoryEntry`
    - `ChatWidget::UserMessage`
  - Show remote images as placeholder rows inside the composer box (above
  textarea), and in history cells.
  - Support keyboard selection/deletion for remote image rows in composer
  (`Up`/`Down`, `Delete`/`Backspace`).
  - Preserve remote-image-only turns in local composer history (Up/Down
  recall), including restore after backtrack.
  - Ensure submit/queue/backtrack resubmit include remote images in model
  input (`UserInput::Image`), and keep request shape stable for
  remote-image-only turns.
  - Keep image numbering contiguous across remote + local images:
    - remote images occupy `[Image #1]..[Image #M]`
    - local images start at `[Image #M+1]`
    - deletion renumbers consistently.
  - In protocol conversion, increment shared image index for remote images
  too, so mixed remote/local image tags stay in a single sequence.
  - Simplify restore logic to trust in-memory attachment order (no
  placeholder-number parsing path).
  - Backtrack/replay rollback handling now queues trims through
  `AppEvent::ApplyThreadRollback` and syncs transcript overlay/deferred
  lines after trims, so overlay/transcript state stays consistent.
  - Trim trailing blank rendered lines from user history rendering to
  avoid oversized blank padding.
  
  ## Docs + tests
  - Updated: `docs/tui-chat-composer.md` (remote image flow,
  selection/deletion, numbering offsets)
  - Added/updated tests across `tui/src/chatwidget/tests.rs`,
  `tui/src/app.rs`, `tui/src/app_backtrack.rs`, `tui/src/history_cell.rs`,
  and `tui/src/bottom_pane/chat_composer.rs`
  - Added snapshot coverage for remote image composer states, including
  deleting the first of two remote images.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-tui`
  
  ## Codex author
  `codex fork 019c2636-1571-74a1-8471-15a3b1c3f49d`

  Charley Cunningham · 2026-02-13 14:54:06 -08:00
  26a7cd21e2
• feat: make sandbox read access configurable with ReadOnlyAccess (#11387)

  `SandboxPolicy::ReadOnly` previously implied broad read access and could
  not express a narrower read surface.
  This change introduces an explicit read-access model so we can support
  user-configurable read restrictions in follow-up work, while preserving
  current behavior today.
  
  It also ensures unsupported backends fail closed for restricted-read
  policies instead of silently granting broader access than intended.
  
  ## What
  
  - Added `ReadOnlyAccess` in protocol with:
    - `Restricted { include_platform_defaults, readable_roots }`
    - `FullAccess`
  - Updated `SandboxPolicy` to carry read-access configuration:
    - `ReadOnly { access: ReadOnlyAccess }`
    - `WorkspaceWrite { ..., read_only_access: ReadOnlyAccess }`
  - Preserved existing behavior by defaulting current construction paths
  to `ReadOnlyAccess::FullAccess`.
  - Threaded the new fields through sandbox policy consumers and call
  sites across `core`, `tui`, `linux-sandbox`, `windows-sandbox`, and
  related tests.
  - Updated Seatbelt policy generation to honor restricted read roots by
  emitting scoped read rules when full read access is not granted.
  - Added fail-closed behavior on Linux and Windows backends when
  restricted read access is requested but not yet implemented there
  (`UnsupportedOperation`).
  - Regenerated app-server protocol schema and TypeScript artifacts,
  including `ReadOnlyAccess`.
  
  ## Compatibility / rollout
  
  - Runtime behavior remains unchanged by default (`FullAccess`).
  - API/schema changes are in place so future config wiring can enable
  restricted read access without another policy-shape migration.

  Michael Bolin · 2026-02-11 18:31:14 -08:00
  abbd74e2be
• fix(tui): conditionally restore status indicator using message phase (#10947)

  TLDR: use new message phase field emitted by preamble-supported models
  to determine whether an AgentMessage is mid-turn commentary. if so,
  restore the status indicator afterwards to indicate the turn has not
  completed.
  
  ### Problem
  `commit_tick` hides the status indicator while streaming assistant text.
  For preamble-capable models, that text can be commentary mid-turn, so
  hiding was correct during streaming but restore timing mattered:
  - restoring too aggressively caused jitter/flashing
  - not restoring caused indicator to stay hidden before subsequent work
  (tool calls, web search, etc.)
  
  ### Fix
  - Add optional `phase` to `AgentMessageItem` and propagate it from
  `ResponseItem::Message`
  - Keep indicator hidden during streamed commit ticks, restore only when:
    - assistant item completes as `phase=commentary`, and
    - stream queues are idle + task is still running.
  - Treat `phase=None` as final-answer behavior (no restore) to keep
  existing behavior for non-preamble models
  
  ### Tests
  Add/update tests for:
  - no idle-tick restore without commentary completion
  - commentary completion restoring status before tool begin
  - snapshot coverage for preamble/status behavior
  
  ---------
  
  Co-authored-by: Josh McKinney <joshka@openai.com>

  sayan-oai · 2026-02-07 02:39:52 +00:00
  5d2702f6b8
• fix(core) switching model appends model instructions (#10651)

  ## Summary
  When switching models, we should append the instructions of the new
  model to the conversation as a developer message.
  
  ## Test
  - [x] Adds a unit test

  Dylan Hurd · 2026-02-05 05:50:38 +00:00
  e482978261
• feat(app-server, core): allow text + image content items for dynamic tool outputs (#10567)

  Took over the work that @aaronl-openai started here:
  https://github.com/openai/codex/pull/10397
  
  Now that app-server clients are able to set up custom tools (called
  `dynamic_tools` in app-server), we should expose a way for clients to
  pass in not just text, but also image outputs. This is something the
  Responses API already supports for function call outputs, where you can
  pass in either a string or an array of content outputs (text, image,
  file):
  https://platform.openai.com/docs/api-reference/responses/create#responses_create-input-input_item_list-item-function_tool_call_output-output-array-input_image
  
  So let's just plumb it through in Codex (with the caveat that we only
  support text and image for now). This is implemented end-to-end across
  app-server v2 protocol types and core tool handling.
  
  ## Breaking API change
  NOTE: This introduces a breaking change with dynamic tools, but I think
  it's ok since this concept was only recently introduced
  (https://github.com/openai/codex/pull/9539) and it's better to get the
  API contract correct. I don't think there are any real consumers of this
  yet (not even the Codex App).
  
  Old shape:
  `{ "output": "dynamic-ok", "success": true }`
  
  New shape:
  ```
  {
      "contentItems": [
        { "type": "inputText", "text": "dynamic-ok" },
        { "type": "inputImage", "imageUrl": "data:image/png;base64,AAA" }
      ]
    "success": true
  }
  ```

  Owen Lin · 2026-02-04 16:12:47 -08:00
  5ea107a088
• fix(core) updated request_rule guidance (#10379)

  ## Summary
  Update guidance for request_rule
  
  ## Testing
  - [x] Unit tests pass

  Dylan Hurd · 2026-02-03 22:29:52 -08:00
  968c029471
• chore: nuke chat/completions API (#10157)
  jif-oai · 2026-02-03 11:31:57 +00:00
  d2394a2494
• chore: add phase to message responseitem (#10455)

  ### What
  
  add wiring for `phase` field on `ResponseItem::Message` to lay
  groundwork for differentiating model preambles and final messages.
  currently optional.
  
  follows pattern in #9698.
  
  updated schemas with `just write-app-server-schema` so we can see type
  changes.
  
  ### Tests
  Updated existing tests for SSE parsing and hydrating from history

  sayan-oai · 2026-02-03 02:52:26 +00:00
  fc05374344
• feat: replace custom mcp-types crate with equivalents from rmcp (#10349)

  We started working with MCP in Codex before
  https://crates.io/crates/rmcp was mature, so we had our own crate for
  MCP types that was generated from the MCP schema:
  
  
  https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md
  
  Now that `rmcp` is more mature, it makes more sense to use their MCP
  types in Rust, as they handle details (like the `_meta` field) that our
  custom version ignored. Though one advantage that our custom types had
  is that our generated types implemented `JsonSchema` and `ts_rs::TS`,
  whereas the types in `rmcp` do not. As such, part of the work of this PR
  is leveraging the adapters between `rmcp` types and the serializable
  types that are API for us (app server and MCP) introduced in #10356.
  
  Note this PR results in a number of changes to
  `codex-rs/app-server-protocol/schema`, which merit special attention
  during review. We must ensure that these changes are still
  backwards-compatible, which is possible because we have:
  
  ```diff
  - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, };
  + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, };
  ```
  
  so `ContentBlock` has been replaced with the more general `JsonValue`.
  Note that `ContentBlock` was defined as:
  
  ```typescript
  export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource;
  ```
  
  so the deletion of those individual variants should not be a cause of
  great concern.
  
  Similarly, we have the following change in
  `codex-rs/app-server-protocol/schema/typescript/Tool.ts`:
  
  ```
  - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, };
  + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, };
  ```
  
  so:
  
  - `annotations?: ToolAnnotations` ➡️ `JsonValue`
  - `inputSchema: ToolInputSchema` ➡️ `JsonValue`
  - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue`
  
  and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349).
  * #10357
  * __->__ #10349
  * #10356

  Michael Bolin · 2026-02-02 17:41:55 -08:00
  66447d5d2c
• fix(rules) Limit rules listed in conversation (#10351)

  ## Summary
  We should probably warn users that they have a million rules, and help
  clean them up. But for now, we should handle this unbounded case.
  
  Limit rules listed in conversations, with shortest / broadest rules
  first.
  
  ## Testing
  - [x] Updated unit tests

  Dylan Hurd · 2026-02-02 02:26:15 +00:00
  8b95d3e082
• add missing fields to WebSearchAction and update app-server types (#10276)

  - add `WebSearchAction` to app-server v2 types
  - add `queries` to `WebSearchAction::Search` type
  
  Updated tests.

  sayan-oai · 2026-01-30 16:37:56 -08:00
  eb86663dcb
• [connectors] Support connectors part 2 - slash command and tui (#9728)

  - [x] Support `/apps` slash command to browse the apps in tui.
  - [x] Support inserting apps to prompt using `$`.
  - [x] Lots of simplification/renaming from connectors to apps.

  Matthew Zeng · 2026-01-28 19:51:58 -08:00
  b9cd089d1f
• feat(core) RequestRule (#9489)

  ## Summary
  Instead of trying to derive the prefix_rule for a command mechanically,
  let's let the model decide for us.
  
  ## Testing
  - [x] tested locally

  Dylan Hurd · 2026-01-28 08:43:17 +00:00
  996e09ca24
• fix: handle all web_search actions and in progress invocations (#9960)

  ### Summary
  - Parse all `web_search` tool actions (`search`, `find_in_page`,
  `open_page`).
  - Previously we only parsed + displayed `search`, which made the TUI
  appear to pause when the other actions were being used.
  - Show in progress `web_search` calls as `Searching the web`
    - Previously we only showed completed tool calls
  
  <img width="308" height="149" alt="image"
  src="https://github.com/user-attachments/assets/90a4e8ff-b06a-48ff-a282-b57b31121845"
  />
  
  ### Tests
  Added + updated tests, tested locally
  
  ### Follow ups
  Update VSCode extension to display these as well

  sayan-oai · 2026-01-27 03:33:48 +00:00
  86adf53235
• change collaboration mode to struct (#9793)

  Shouldn't cause behavioral change

  Ahmed Ibrahim · 2026-01-23 17:00:23 -08:00
  69cfc73dc6
• feat(core) update Personality on turn (#9644)

  ## Summary
  Support updating Personality mid-Thread via UserTurn/OverwriteTurn. This
  is explicitly unused by the clients so far, to simplify PRs - app-server
  and tui implementations will be follow-ups.
  
  ## Testing
  - [x] added integration tests

  Dylan Hurd · 2026-01-22 12:04:23 -08:00
  8b3521ee77
• Support end_turn flag (#9698)

  Experimental flag that signals the end of the turn.

  pakrym-oai · 2026-01-22 17:27:48 +00:00
  b511c38ddb
• fix(core) Preserve base_instructions in SessionMeta (#9427)

  ## Summary
  This PR consolidates base_instructions onto SessionMeta /
  SessionConfiguration, so we ensure `base_instructions` is set once per
  session and should be (mostly) immutable, unless:
  - overridden by config on resume / fork
  - sub-agent tasks, like review or collab
  
  
  In a future PR, we should convert all references to `base_instructions`
  to consistently used the typed struct, so it's less likely that we put
  other strings there. See #9423. However, this PR is already quite
  complex, so I'm deferring that to a follow-up.
  
  ## Testing
  - [x] Added a resume test to assert that instructions are preserved. In
  particular, `resume_switches_models_preserves_base_instructions` fails
  against main.
  
  Existing test coverage thats assert base instructions are preserved
  across multiple requests in a session:
  - Manual compact keeps baseline instructions:
  core/tests/suite/compact.rs:199
  - Auto-compact keeps baseline instructions:
  core/tests/suite/compact.rs:1142
  - Prompt caching reuses the same instructions across two requests:
  core/tests/suite/prompt_caching.rs:150 and
  core/tests/suite/prompt_caching.rs:157
  - Prompt caching with explicit expected string across two requests:
  core/tests/suite/prompt_caching.rs:213 and
  core/tests/suite/prompt_caching.rs:222
  - Resume with model switch keeps original instructions:
  core/tests/suite/resume.rs:136
  - Compact/resume/fork uses request 0 instructions for later expected
  payloads: core/tests/suite/compact_resume_fork.rs:215

  Dylan Hurd · 2026-01-19 21:59:36 -08:00
  675f165c56
• Add collaboration modes test prompts (#9443)

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

  Ahmed Ibrahim · 2026-01-18 11:39:08 -08:00
  f72f87fbee
• Add collaboration developer instructions (#9424)

  - Add additional instructions when they are available
  - Make sure to update them on change either UserInput or UserTurn

  Ahmed Ibrahim · 2026-01-18 01:31:14 +00:00
  1478a88eb0
• Add text element metadata to types (#9235)

  Initial type tweaking PR to make the diff of
  https://github.com/openai/codex/pull/9116 smaller
  
  This should not change any behavior, just adds some fields to types

  charley-oai · 2026-01-14 16:41:50 -08:00
  4a9c2bcc5a