2618 Commits

• fix(tui): reflow scrollback on terminal resize (#18575)

  Fixes multiple scrollback and terminal resize issues: #5538, #5576,
  #8352, #12223, #16165, and #15380.
  
  ## Why
  
  Codex writes finalized transcript output into terminal scrollback after
  wrapping it for the current viewport width. A later terminal resize
  could leave that scrollback shaped for the old width, so wider windows
  kept narrow output and narrower windows could show stale wrapping
  artifacts until enough new output replaced the visible area.
  
  This is also the foundation PR for responsive markdown tables. Table
  rendering needs finalized transcript content to be width-sensitive after
  insertion, not only while content is first streaming. Markdown table
  rendering itself stays in #18576.
  
  ## Stack
  
  - PR1: resize backlog reflow and interrupt cleanup
  - #18576: markdown table support
  
  ## What Changed
  
  - Rebuild source-backed transcript history when the terminal width
  changes. `terminal_resize_reflow` is introduced through the experimental
  feature system, but is enabled by default for this rollout so we can
  validate behavior across real terminals.
  - Preserve assistant and plan stream source so finalized streaming
  output can participate in resize reflow after consolidation.
  - Debounce resize work, but force a final source-backed reflow when a
  resize happened during active or unconsolidated streaming output.
  - Clear stale pending history lines on resize so old-width wrapped
  output is not emitted just before rebuilt scrollback.
  - Bound replay work with `[tui.terminal_resize_reflow].max_rows`:
  omitted uses terminal-specific defaults, `0` keeps all rendered rows,
  and a positive value sets an explicit cap. The cap applies both while
  initially replaying a resumed transcript into scrollback and when
  rebuilding scrollback after terminal resize.
  - Consolidate interrupted assistant streams before cleanup, then clear
  pending stream output and active-tail state consistently.
  - Move resize reflow and thread event buffering helpers out of `app.rs`
  into dedicated TUI modules.
  - Add focused coverage for resize reflow, feature-gated behavior,
  streaming source preservation, interrupted output cleanup,
  unicode-neutral text, terminal-specific row caps, and composer/layout
  stability.
  
  ## Runtime Bounds
  
  Resize reflow keeps only the most recent rendered rows when a row cap is
  active. The default is `auto`, which maps to the detected terminal's
  default scrollback size where Codex can identify it: VS Code `1000`,
  Windows Terminal `9001`, WezTerm `3500`, and Alacritty `10000`.
  Terminals without a dedicated mapping use the conservative fallback of
  `1000` rows. Users can override this with `[tui.terminal_resize_reflow]
  max_rows = N`, or set `max_rows = 0` to disable row limiting.
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui reflow`
  - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui
  transcript_reflow`
  - `just fix -p codex-tui`
  - PR CI in progress on the squashed branch

  Felipe Coury · 2026-04-25 22:00:32 -03:00
  5591912f0b
• [codex] Bypass managed network for escalated exec (#19595)

  ## Why
  
  `sandbox_permissions = "require_escalated"` is treated as an explicit
  request to approve the command and run it outside the
  filesystem/platform sandbox. Before this change, shell and unified exec
  still registered managed network approval context and could inject
  Codex-managed proxy state into the child process, which meant an
  approved escalated command could still hit a second network approval
  path.
  
  This PR makes that escalation boundary consistent: once a command is
  explicitly approved to run outside the sandbox, Codex does not also
  route that process through the managed network proxy.
  
  ## Security impact
  
  Command/filesystem sandbox approval now implies network approval for
  that command. If an untrusted command or script is allowed to run with
  `require_escalated`, its network calls are unsandboxed: Codex-managed
  network allowlists and denylists are not respected for that process, so
  the command can exfiltrate any data it can read.
  
  ## What changed
  
  - Skip managed network approval specs for
  `SandboxPermissions::RequireEscalated`.
  - Pass `network: None` into shell, zsh-fork shell, and unified exec
  sandbox preparation for explicitly escalated requests.
  - Strip Codex-managed proxy environment variables when
  `CODEX_NETWORK_PROXY_ACTIVE` is present, while preserving user proxy env
  when the Codex marker is absent.
  - Add regression coverage for the prepared exec request so the old
  behavior cannot silently reappear.
  
  ## Verification
  
  - `cargo test -p codex-core explicit_escalation`
  - `cargo clippy -p codex-core --all-targets -- -D warnings`

  viyatb-oai · 2026-04-25 23:23:58 +00:00
  9aaa5d9358
• Add goal core runtime (4 / 5) (#18076)

  Adds the core runtime behavior for active goals on top of the model
  tools from PR 3.
  
  ## Why
  
  A long-running goal should be a core runtime concern, not something
  every client has to implement. Core owns the turn lifecycle, tool
  completion boundaries, interruptions, resume behavior, and token usage,
  so it is the right place to account progress, enforce budgets, and
  decide when to continue work.
  
  ## What changed
  
  - Centralized goal lifecycle side effects behind
  `Session::goal_runtime_apply(GoalRuntimeEvent::...)`.
  - Starts goal continuation turns only when the session is idle; pending
  user input and mailbox work take priority.
  - Accounts token and wall-clock usage at turn, tool, mutation,
  interrupt, and resume boundaries; `get_thread_goal` remains read-only.
  - Preserves sub-second wall-clock remainder across accounting boundaries
  so long-running goals do not drift downward over time.
  - Treats token budget exhaustion as a soft stop by marking the goal
  `budget_limited` and injecting wrap-up steering instead of aborting the
  active turn.
  - Suppresses budget steering when `update_goal` marks a goal complete.
  - Pauses active goals on interrupt and auto-reactivates paused goals
  when a thread resumes outside plan mode.
  - Suppresses repeated automatic continuation when a continuation turn
  makes no tool calls.
  - Added continuation and budget-limit prompt templates.
  
  ## Verification
  
  - Added focused core coverage for continuation scheduling, accounting
  boundaries, budget-limit steering, completion accounting, interrupt
  pause behavior, resume auto-activation, and wall-clock remainder
  accounting.

  Eric Traut · 2026-04-24 21:16:00 -07:00
  4167628622
• Add goal model tools (3 / 5) (#18075)

  Adds the model-facing goal tools on top of the app-server API from PR 2.
  
  ## Why
  
  Once goals are persisted and exposed to clients, the model needs a
  small, constrained tool surface for goal workflows. The tool contract
  should let the model inspect goals, create them only when explicitly
  requested, and mark them complete without giving it broad control over
  user/runtime-owned state.
  
  ## What changed
  
  - Added `get_goal`, `create_goal`, and `update_goal` tool specs behind
  the `goals` feature flag.
  - Added core goal tool handlers that validate objectives and token
  budgets before mutating persisted state.
  - Constrained `create_goal` to create only when no goal exists, with
  optional `token_budget` only when a budget is explicitly provided.
  - Tightened the `create_goal` instructions so the model does not infer
  goals from ordinary task requests.
  - Constrained `update_goal` to expose only goal completion; pause,
  resume, clear, and budget-limited transitions remain user- or
  runtime-controlled.
  - Registered the goal tools in the tool registry and kept them out of
  review contexts where they should not appear.
  
  ## Verification
  
  - Added tool-registry coverage for feature gating and tool availability.
  - Added core session tests for create/get/update behavior, duplicate
  goal rejection, budget validation, and completion-only updates.

  Eric Traut · 2026-04-24 20:54:40 -07:00
  32ace07ac5
• Add goal app-server API (2 / 5) (#18074)

  Adds the app-server v2 goal API on top of the persisted goal state from
  PR 1.
  
  ## Why
  
  Clients need a stable app-server surface for reading and controlling
  materialized thread goals before the model tools and TUI can use them.
  Goal changes also need to be observable by app-server clients, including
  clients that resume an existing thread.
  
  ## What changed
  
  - Added v2 `thread/goal/get`, `thread/goal/set`, and `thread/goal/clear`
  RPCs for materialized threads.
  - Added `thread/goal/updated` and `thread/goal/cleared` notifications so
  clients can keep local goal state in sync.
  - Added resume/snapshot wiring so reconnecting clients see the current
  goal state for a thread.
  - Added app-server handlers that reconcile persisted rollout state
  before direct goal mutations.
  - Updated the app-server README plus generated JSON and TypeScript
  schema fixtures for the new API surface.
  
  ## Verification
  
  - Added app-server v2 coverage for goal get/set/clear behavior,
  notification emission, resume snapshots, and non-local thread-store
  interactions.

  Eric Traut · 2026-04-24 20:53:41 -07:00
  6c874f9b34
• Remove js_repl feature (#19410)
  Curtis 'Fjord' Hawthorne · 2026-04-24 17:49:29 -07:00
  8a559e7938
• permissions: remove legacy read-only access modes (#19449)

  ## Why
  
  `ReadOnlyAccess` was a transitional legacy shape on `SandboxPolicy`:
  `FullAccess` meant the historical read-only/workspace-write modes could
  read the full filesystem, while `Restricted` tried to carry partial
  readable roots. The partial-read model now belongs in
  `FileSystemSandboxPolicy` and `PermissionProfile`, so keeping it on
  `SandboxPolicy` makes every legacy projection reintroduce lossy
  read-root bookkeeping and creates unnecessary noise in the rest of the
  permissions migration.
  
  This PR makes the legacy policy model narrower and explicit:
  `SandboxPolicy::ReadOnly` and `SandboxPolicy::WorkspaceWrite` represent
  the old full-read sandbox modes only. Split readable roots, deny-read
  globs, and platform-default/minimal read behavior stay in the runtime
  permissions model.
  
  ## What changed
  
  - Removes `ReadOnlyAccess` from
  `codex_protocol::protocol::SandboxPolicy`, including the generated
  `access` and `readOnlyAccess` API fields.
  - Updates legacy policy/profile conversions so restricted filesystem
  reads are represented only by `FileSystemSandboxPolicy` /
  `PermissionProfile` entries.
  - Keeps app-server v2 compatible with legacy `fullAccess` read-access
  payloads by accepting and ignoring that no-op shape, while rejecting
  legacy `restricted` read-access payloads instead of silently widening
  them to full-read legacy policies.
  - Carries Windows sandbox platform-default read behavior with an
  explicit override flag instead of depending on
  `ReadOnlyAccess::Restricted`.
  - Refreshes generated app-server schema/types and updates tests/docs for
  the simplified legacy policy shape.
  
  ## Verification
  
  - `cargo check -p codex-app-server-protocol --tests`
  - `cargo check -p codex-windows-sandbox --tests`
  - `cargo test -p codex-app-server-protocol sandbox_policy_`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19449).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19391
  * __->__ #19449

  Michael Bolin · 2026-04-24 17:16:58 -07:00
  789f387982
• [codex] Forward Codex Apps tool call IDs to backend metadata (#19207)

  ## Summary
  - include the outer tool `call_id` in Codex Apps MCP request metadata
  under `_meta._codex_apps.call_id`
  - preserve existing Codex Apps metadata like `resource_uri` and
  `contains_mcp_source`
  - add request metadata coverage for both the existing-metadata and
  no-existing-metadata cases
  
  ## Why
  The paired backend change in
  [openai/openai#850796](https://github.com/openai/openai/pull/850796)
  updates MCP compliance logging to prefer `_meta._codex_apps.call_id`
  instead of the JSON-RPC request id. This client change sends that outer
  tool call id so the backend can record the model/tool call identifier
  when it is available.
  
  This is wire-compatible with older backends because `_meta._codex_apps`
  is already reserved backend-only metadata. Backends that do not read
  `call_id` will ignore the extra field.
  
  ## Testing
  - `cargo test -p codex-core request_meta`
  - `just fmt`
  - `just fix -p codex-core`

  rreichel3-oai · 2026-04-24 18:49:34 -04:00
  219c65dc2f
• feat: Compress skill paths with root aliases (#19098)

  Add skill root tracking so model-visible skill lists can use short path
  aliases when absolute paths would exceed the metadata budget.

  xl-openai · 2026-04-24 15:49:07 -07:00
  1e560f33e1
• [codex] add non-local thread store regression harness (#19266)

  - Add an integration test that guarantees nothing gets written to codex
  home dir or sqlite when running a rollout with a non-local ThreadStore
  - Add an in-memory "spy" ThreadStore for tests like this
  
  Note I could not find a good way to also ensure there were no filesystem
  _reads_ that didn't go through threadstore. I explored a more elaborate
  sandboxed-subprocess approach but it isn't platform portable and felt
  like it wasn't (yet) worth it.

  Tom · 2026-04-24 15:45:44 -07:00
  588f7a9fc4
• Migrate fork and resume reads to thread store (#18900)

  - Route cold thread/resume and thread/fork source loading through
  ThreadStore reads instead of direct rollout path operations
  - Keep lookups that explicitly specify a rollout-path using the local
  thread store methods but return an invalid-request error for remote
  ThreadStore configurations
  - Add some additional unit tests for code path coverage

  Tom · 2026-04-24 13:51:37 -07:00
  0a9b559c0b
• permissions: make legacy profile conversion cwd-free (#19414)

  ## Why
  
  The profile conversion path still required a `cwd` even when it was only
  translating a legacy `SandboxPolicy` into a `PermissionProfile`. That
  made profile producers invent an ambient `cwd`, which is exactly the
  anchoring we are trying to remove from permission-profile data. A legacy
  workspace-write policy can be represented symbolically instead: `:cwd =
  write` plus read-only `:project_roots` metadata subpaths.
  
  This PR creates that cwd-free base so the rest of the stack can stop
  threading cwd through profile construction. Callers that actually need a
  concrete runtime filesystem policy for a specific cwd still have an
  explicitly named cwd-bound conversion.
  
  ## What Changed
  
  - `PermissionProfile::from_legacy_sandbox_policy` now takes only
  `&SandboxPolicy`.
  - `FileSystemSandboxPolicy::from_legacy_sandbox_policy` is now the
  symbolic, cwd-free projection for profiles.
  - The old concrete projection is retained as
  `FileSystemSandboxPolicy::from_legacy_sandbox_policy_for_cwd` for
  runtime/boundary code that must materialize legacy cwd behavior.
  - Workspace-write profiles preserve `CurrentWorkingDirectory` and
  `ProjectRoots` special entries instead of materializing cwd into
  absolute paths.
  
  ## Verification
  
  - `cargo check -p codex-protocol -p codex-core -p
  codex-app-server-protocol -p codex-app-server -p codex-exec -p
  codex-exec-server -p codex-tui -p codex-sandboxing -p
  codex-linux-sandbox -p codex-analytics --tests`
  - `just fix -p codex-protocol -p codex-core -p codex-app-server-protocol
  -p codex-app-server -p codex-exec -p codex-exec-server -p codex-tui -p
  codex-sandboxing -p codex-linux-sandbox -p codex-analytics`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19414).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19391
  * __->__ #19414

  Michael Bolin · 2026-04-24 13:42:05 -07:00
  13e0ec1614
• chore: drop MCP Plugins and App from Morpheus (#19380)

  Quick fix of https://github.com/openai/codex/issues/18333

  jif-oai · 2026-04-24 17:57:48 +02:00
  f802f0a391
• Add agents.interrupt_message for interruption markers (#19351)

  ## Why
  
  Agent interruptions currently always persist a model-visible
  interrupted-turn marker before emitting `TurnAborted`. That marker is
  useful by default because it gives the next model turn context about a
  deliberately interrupted task, but some deployments need to suppress
  that history injection entirely while still keeping the client-visible
  interruption event.
  
  ## What changed
  
  - Add `[agents] interrupt_message = false` to disable the model-visible
  interrupted-turn marker.
  - Resolve the setting into `Config::agent_interrupt_message_enabled`,
  defaulting to `true` so existing behavior is unchanged.
  - Apply the setting to both live interrupted turns and interrupted fork
  snapshots.
  - Keep emitting `TurnAborted` even when the history marker is disabled.
  - Regenerate `core/config.schema.json` for the new
  `agents.interrupt_message` field.
  
  ## Testing
  
  - `cargo test -p codex-core load_config_resolves_agent_interrupt_message
  -- --nocapture`
  - `cargo test -p codex-core
  disabled_interrupted_fork_snapshot_appends_only_interrupt_event --
  --nocapture`
  - `cargo test -p codex-core
  multi_agent_v2_interrupted_marker_uses_developer_input_message --
  --nocapture`
  - `cargo test -p codex-core
  multi_agent_v2_followup_task_can_disable_interrupted_marker --
  --nocapture`
  - `cargo test -p codex-core
  multi_agent_v2_followup_task_interrupts_busy_child_without_losing_message
  -- --nocapture`
  - `cargo check -p codex-core`

  jif-oai · 2026-04-24 16:02:45 +02:00
  28742866c7
• feat: surface multi-agent thread limit in spawn description (#19360)

  ## Summary
  - Thread `agent_max_threads` into `ToolsConfig` and
  `SpawnAgentToolOptions`.
  - Render the configured `max_concurrent_threads_per_session` value in
  the MultiAgentV2 `spawn_agent` description.
  - Cover the description text in `codex-tools` unit tests and
  `codex-core` tool spec tests.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core spawn_agent_description`
  - `git diff --check`
  
  ## Notes
  - `cargo test -p codex-core` was also attempted, but unrelated
  environment-sensitive tests failed with the active local environment.
  Examples: approvals reviewer defaults observed `AutoReview` instead of
  `User`, request-permissions event tests did not emit events, and
  proxy-env tests saw `http://127.0.0.1:50604` from the active proxy
  environment.
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-24 15:13:54 +02:00
  deb4509302
• Make MultiAgentV2 interruption markers assistant-authored (#19124)

  ## Why
  
  `MultiAgentV2` follow-up messages are delivered to agents as
  assistant-authored `InterAgentCommunication` envelopes. When
  `followup_task` used `interrupt: true`, the interrupted-turn guidance
  was still persisted as a contextual user message, so model-visible
  history made a system-generated interruption boundary look
  user-authored.
  
  This keeps interruption guidance consistent with the rest of the v2
  inter-agent message stream while preserving the legacy marker shape for
  non-v2 sessions.
  
  ## What changed
  
  - Make `interrupted_turn_history_marker` feature-aware.
  - Record the interrupted-turn marker as an assistant `OutputText`
  message when `Feature::MultiAgentV2` is enabled.
  - Keep the existing user contextual fragment for non-v2 sessions.
  - Apply the same feature-aware marker to interrupted fork snapshots.
  - Add coverage for the live `followup_task` interrupt path and the
  helper-level v2 marker shape.
  
  ## Testing
  
  - `cargo test -p codex-core
  multi_agent_v2_followup_task_interrupts_busy_child_without_losing_message
  -- --nocapture`
  - `cargo test -p codex-core
  multi_agent_v2_interrupted_marker_uses_assistant_output_message --
  --nocapture`
  - `cargo test -p codex-core interrupted_fork_snapshot -- --nocapture`

  jif-oai · 2026-04-24 13:39:26 +02:00
  120aa07d81
• Hide unsupported MCP bearer_token from config schema (#19294)

  ## Summary
  
  Fixes #19275.
  
  Codex runtime rejects inline MCP `bearer_token` config entries and asks
  users to configure `bearer_token_env_var` instead, but the generated
  config schema still advertised `mcp_servers.<name>.bearer_token` as a
  supported field. That made editor/schema validation disagree with
  runtime validation.
  
  This keeps `bearer_token` in `RawMcpServerConfig` so Codex can continue
  producing the targeted runtime error for recent or existing configs, but
  skips the field during schemars generation. The checked-in
  `core/config.schema.json` fixture now exposes `bearer_token_env_var`
  without exposing unsupported inline `bearer_token`.
  
  ## Verification
  
  - Added `config_schema_hides_unsupported_inline_mcp_bearer_token` to
  assert the generated schema hides `bearer_token` while preserving
  `bearer_token_env_var`.
  - Ran `cargo test -p codex-config`.
  - Ran `cargo test -p codex-core config_schema`.

  Eric Traut · 2026-04-24 00:17:43 -07:00
  6f87eb0479
• chore: apply truncation policy to unified_exec (#19247)

  we were not respecting turn's `truncation_policy` to clamp output tokens
  for `unified_exec` and `write_stdin`.
  
  this meant truncation was only being applied by `ContextManager` before
  the output was stored in-memory (so it _was_ being truncated from
  model-visible context), but the full output was persisted to rollout on
  disk.
  
  now we respect that `truncation_policy` and `ContextManager`-level
  truncation remains a backup.
  
  ### Tests
  added tests, tested locally.

  sayan-oai · 2026-04-24 00:17:39 -07:00
  e083b6c757
• Reject unsupported js_repl image MIME types (#19292)

  ## Summary
  
  `codex.emitImage` accepted arbitrary image MIME types for byte payloads
  and data URLs. That allowed a value like `image/rgba` to be wrapped as
  an `input_image`, even though it is not a supported encoded image
  format, so the invalid image could reach the model-input path and
  trigger output sanitization.
  
  This results in a panic in debug builds because the output sanitization
  is meant as a final safety net, not a primary means of rejecting invalid
  image types. I've hit this case multiple times when executing certain
  long-running tasks.
  
  This PR rejects unsupported image MIME types before they are emitted
  from `js_repl`.
  
  ## Changes
  
  - Validate `codex.emitImage({ bytes, mimeType })` in the JS kernel so
  only encoded PNG, JPEG, WebP, or GIF payloads are accepted.
  - Apply the same MIME allowlist to direct image data URLs, including the
  Rust host-side validation path.
  - Clarify the JS REPL instructions so agents know byte payloads must
  already be encoded as PNG/JPEG/WebP/GIF.

  Eric Traut · 2026-04-24 00:14:51 -07:00
  ac8c9fc49c
• Resolve relative agent role config paths from layers (#19261)

  Fixes #19257.
  
  ## Summary
  
  Agent roles declared in config layers can set `config_file` to a
  relative path, but deserializing the layer-local `[agents.*]` table
  happened without an `AbsolutePathBuf` base path. That caused configs
  like `config_file = "agents/my-role.toml"` to fail with `AbsolutePathBuf
  deserialized without a base path`.
  
  This updates agent role layer loading to deserialize `[agents.*]` while
  the layer config folder is active as the path base, matching the
  behavior documented for `AgentRoleToml.config_file`. It also adds
  coverage for a user config layer with a relative agent role
  `config_file`.

  Eric Traut · 2026-04-23 23:23:11 -07:00
  d87d918716
• permissions: make profiles represent enforcement (#19231)

  ## Why
  
  `PermissionProfile` is becoming the canonical permissions abstraction,
  but the old shape only carried optional filesystem and network fields.
  It could describe allowed access, but not who is responsible for
  enforcing it. That made `DangerFullAccess` and `ExternalSandbox` lossy
  when profiles were exported, cached, or round-tripped through app-server
  APIs.
  
  The important model change is that active permissions are now a disjoint
  union over the enforcement mode. Conceptually:
  
  ```rust
  pub enum PermissionProfile {
      Managed {
          file_system: FileSystemSandboxPolicy,
          network: NetworkSandboxPolicy,
      },
      Disabled,
      External {
          network: NetworkSandboxPolicy,
      },
  }
  ```
  
  This distinction matters because `Disabled` means Codex should apply no
  outer sandbox at all, while `External` means filesystem isolation is
  owned by an outside caller. Those are not equivalent to a broad managed
  sandbox. For example, macOS cannot nest Seatbelt inside Seatbelt, so an
  inner sandbox may require the outer Codex layer to use no sandbox rather
  than a permissive one.
  
  ## How Existing Modeling Maps
  
  Legacy `SandboxPolicy` remains a boundary projection, but it now maps
  into the higher-fidelity profile model:
  
  - `ReadOnly` and `WorkspaceWrite` map to `PermissionProfile::Managed`
  with restricted filesystem entries plus the corresponding network
  policy.
  - `DangerFullAccess` maps to `PermissionProfile::Disabled`, preserving
  the “no outer sandbox” intent instead of treating it as a lax managed
  sandbox.
  - `ExternalSandbox { network_access }` maps to
  `PermissionProfile::External { network }`, preserving external
  filesystem enforcement while still carrying the active network policy.
  - Split runtime policies that legacy `SandboxPolicy` cannot faithfully
  express, such as managed unrestricted filesystem plus restricted
  network, stay `Managed` instead of being collapsed into
  `ExternalSandbox`.
  - Per-command/session/turn grants remain partial overlays via
  `AdditionalPermissionProfile`; full `PermissionProfile` is reserved for
  complete active runtime permissions.
  
  ## What Changed
  
  - Change active `PermissionProfile` into a tagged union: `managed`,
  `disabled`, and `external`.
  - Keep partial permission grants separate with
  `AdditionalPermissionProfile` for command/session/turn overlays.
  - Represent managed filesystem permissions as either `restricted`
  entries or `unrestricted`; `glob_scan_max_depth` is non-zero when
  present.
  - Preserve old rollout compatibility by accepting the pre-tagged `{
  network, file_system }` profile shape during deserialization.
  - Preserve fidelity for important edge cases: `DangerFullAccess`
  round-trips as `disabled`, `ExternalSandbox` round-trips as `external`,
  and managed unrestricted filesystem + restricted network stays managed
  instead of being mistaken for external enforcement.
  - Preserve configured deny-read entries and bounded glob scan depth when
  full profiles are projected back into runtime policies, including
  unrestricted replacements that now become `:root = write` plus deny
  entries.
  - Regenerate the experimental app-server v2 JSON/TypeScript schema and
  update the `command/exec` README example for the tagged
  `permissionProfile` shape.
  
  ## Compatibility
  
  Legacy `SandboxPolicy` remains available at config/API boundaries as the
  compatibility projection. Existing rollout lines with the old
  `PermissionProfile` shape continue to load. The app-server
  `permissionProfile` field is experimental, so its v2 wire shape is
  intentionally updated to match the higher-fidelity model.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo check --tests`
  - `cargo test -p codex-protocol permission_profile`
  - `cargo test -p codex-protocol
  preserving_deny_entries_keeps_unrestricted_policy_enforceable`
  - `cargo test -p codex-app-server-protocol
  permission_profile_file_system_permissions`
  - `cargo test -p codex-app-server-protocol serialize_client_response`
  - `cargo test -p codex-core
  session_configured_reports_permission_profile_for_external_sandbox`
  - `just fix`
  - `just fix -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`

  Michael Bolin · 2026-04-23 23:02:18 -07:00
  4816b89204
• feat: let model providers own model discovery (#18950)

  ## Why
  
  `codex-models-manager` had grown to own provider-specific concerns:
  constructing OpenAI-compatible `/models` requests, resolving provider
  auth, emitting request telemetry, and deciding how provider catalogs
  should be sourced. That made the manager harder to reuse for providers
  whose model catalog is not fetched from the OpenAI `/models` endpoint,
  such as Amazon Bedrock.
  
  This change moves provider-specific model discovery behind
  provider-owned implementations, so the models manager can focus on
  refresh policy, cache behavior, picker ordering, and model metadata
  merging.
  
  ## What Changed
  
  - Introduced a `ModelsManager` trait with separate `OpenAiModelsManager`
  and `StaticModelsManager` implementations.
  - Added `ModelsEndpointClient` so OpenAI-compatible HTTP fetching lives
  outside `codex-models-manager`.
  - Moved `/models` request construction, provider auth resolution,
  timeout handling, and request telemetry into `codex-model-provider` via
  `OpenAiModelsEndpoint`.
  - Added provider-owned `models_manager(...)` construction so configured
  OpenAI-compatible providers use `OpenAiModelsManager`, while
  static/catalog-backed providers can return `StaticModelsManager`.
  - Added an Amazon Bedrock static model catalog for the GPT OSS Bedrock
  model IDs.
  - Updated core/session/thread manager code and tests to depend on
  `Arc<dyn ModelsManager>`.
  - Moved offline model test helpers into
  `codex_models_manager::test_support`.
  ## Metadata References
  
  The Bedrock catalog metadata is based on the official Amazon Bedrock
  OpenAI model documentation:
  
  - [Amazon Bedrock OpenAI
  models](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-openai.html)
  lists the Bedrock model IDs, text input/output modalities, and `128,000`
  token context window for `gpt-oss-20b` and `gpt-oss-120b`.
  - [Amazon Bedrock `gpt-oss-120b` model
  card](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-oss-120b.html)
  lists the `bedrock-runtime` model ID `openai.gpt-oss-120b-1:0`, the
  `bedrock-mantle` model ID `openai.gpt-oss-120b`, text-only modalities,
  and `128K` context window.
  - [OpenAI `gpt-oss-120b` model
  docs](https://developers.openai.com/api/docs/models/gpt-oss-120b)
  document configurable reasoning effort with `low`, `medium`, and `high`,
  plus text input/output modality.
  
  The display names, default reasoning effort, and priority ordering are
  Codex-local catalog choices.
  
  ## Test Plan
  - Manually verified app-server model listing with an AWS profile:
  
  ```shell
  CODEX_HOME="$(mktemp -d)" cargo run -p codex-app-server-test-client -- \
    --codex-bin ./target/debug/codex \
    -c 'model_provider="amazon-bedrock"' \
    -c 'model_providers.amazon-bedrock.aws.profile="codex-bedrock"' \
    -c 'model_providers.amazon-bedrock.aws.region="us-west-2"' \
    model-list
  ```
  
  The response returned the Bedrock catalog with `openai.gpt-oss-120b-1:0`
  as the default model and `openai.gpt-oss-20b-1:0` as the second listed
  model, both text-only and supporting low/medium/high reasoning effort.

  Celia Chen · 2026-04-24 04:28:25 +00:00
  e8d8080818
• feat: Use short SHA versions for curated plugin cache entries (#19095)

  Curated plugin cache entries now use an 8-character SHA prefix, instead
  of the full SHA, as the cache folder version number.

  xl-openai · 2026-04-23 21:15:03 -07:00
  53be451673
• Add sticky environment API and thread state (#18897)

  ## Summary
  - add sticky environment selections to app-server v2 thread/start and
  turn/start request flow
  - carry thread-level selections through core session/thread state
  - add app-server coverage for sticky selections and turn overrides
  
  ## Stack
  1. This PR: API and thread persistence
  2. #18898: config.toml named environment loading
  3. #18899: downstream tool/runtime consumers
  
  ## Validation
  - Not run locally; split only.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-23 18:57:13 -07:00
  49fb25997f
• [rollout_trace] Add debug trace reduction command (#18880)

  ## Summary
  
  Adds the debug CLI entry point for reducing recorded rollout traces.
  This gives developers a direct way to inspect whether the emitted trace
  stream reduces into the expected conversation/runtime model.
  
  ## Stack
  
  This is PR 5/5 in the rollout trace stack.
  
  - [#18876](https://github.com/openai/codex/pull/18876): Add rollout
  trace crate
  - [#18877](https://github.com/openai/codex/pull/18877): Record core
  session rollout traces
  - [#18878](https://github.com/openai/codex/pull/18878): Trace tool and
  code-mode boundaries
  - [#18879](https://github.com/openai/codex/pull/18879): Trace sessions
  and multi-agent edges
  - [#18880](https://github.com/openai/codex/pull/18880): Add debug trace
  reduction command
  
  ## Review Notes
  
  This PR is intentionally last: it depends on the trace crate, core
  recorder, runtime/tool events, and session/agent edge data all existing.
  The command should remain a debug/developer tool and avoid adding new
  runtime behavior.
  
  The useful review question is whether the CLI exposes the reducer in the
  smallest practical way for local inspection without turning the debug
  command into a supported user-facing workflow.

  cassirer-openai · 2026-04-24 01:56:48 +00:00
  e3c8720a99
• refactor: route Codex auth through AuthProvider (#18811)

  ## Summary
  
  This PR moves Codex backend request authentication from direct
  bearer-token handling to `AuthProvider`.
  
  The new `codex-auth-provider` crate defines the shared request-auth
  trait. `CodexAuth::provider()` returns a provider that can apply all
  headers needed for the selected auth mode.
  
  This lets ChatGPT token auth and AgentIdentity auth share the same
  callsite path:
  - ChatGPT token auth applies bearer auth plus account/FedRAMP headers
  where needed.
  - AgentIdentity auth applies AgentAssertion plus account/FedRAMP headers
  where needed.
  
  Reference old stack: https://github.com/openai/codex/pull/17387/changes
  
  ## Callsite Migration
  
  | Area | Change |
  | --- | --- |
  | backend-client | accepts an `AuthProvider` instead of a raw
  token/header |
  | chatgpt client/connectors | applies auth through
  `CodexAuth::provider()` |
  | cloud tasks | keeps Codex-backend gating, applies auth through
  provider |
  | cloud requirements | uses Codex-backend auth checks and provider
  headers |
  | app-server remote control | applies provider headers for backend calls
  |
  | MCP Apps/connectors | gates on `uses_codex_backend()` and keys caches
  from generic account getters |
  | model refresh | treats AgentIdentity as Codex-backend auth |
  | OpenAI file upload path | rejects non-Codex-backend auth before
  applying headers |
  | core client setup | keeps model-provider auth flow and allows
  AgentIdentity through provider-backed OpenAI auth |
  
  ## Stack
  
  1. https://github.com/openai/codex/pull/18757: full revert
  2. https://github.com/openai/codex/pull/18871: isolated Agent Identity
  crate
  3. https://github.com/openai/codex/pull/18785: explicit AgentIdentity
  auth mode and startup task allocation
  4. This PR: migrate Codex backend auth callsites through AuthProvider
  5. https://github.com/openai/codex/pull/18904: accept AgentIdentity JWTs
  and load `CODEX_AGENT_IDENTITY`
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-23 17:14:02 -07:00
  5882f3f95e
• Fix /review interrupt and TUI exit wedges (#18921)

  Addresses #11267
  
  ## Summary
  `/review` can be interrupted while it is still spawning the review
  sub-agent. That spawn path lives in `codex-core` and did not observe the
  task cancellation token until after `Codex::spawn` returned, so an
  interrupted review could keep building a child session and leave the TUI
  in a wedged state.
  
  The TUI exit path also waited indefinitely for app-server
  `thread/unsubscribe`, which made Ctrl+C look broken if the app-server
  was already stuck. This makes interactive delegate startup
  cancellation-aware and bounds the TUI shutdown-first unsubscribe wait
  with a short UI escape-hatch timeout.
  
  ## Testing
  I reproed the hang using the steps in the bug report. Confirmed hang no
  longer exists after fix.

  Eric Traut · 2026-04-23 13:28:12 -07:00
  3f8c06e457
• shell-escalation: carry resolved permission profiles (#18287)

  ## Why
  
  Shell escalation still has adapter code that expects a legacy sandbox
  policy, but command approvals should carry the resolved
  `PermissionProfile` so callers can reason about the granted permissions
  canonically.
  
  ## What changed
  
  This introduces profile-shaped resolved escalation permissions while
  retaining the derived legacy sandbox policy for the Unix escalation
  adapter. It updates approval types, the escalation server protocol, and
  tests that inspect escalated command permissions.
  
  ## Verification
  
  - `cargo test -p codex-core --test all handle_container_exec_ --
  --nocapture`
  - `cargo test -p codex-core --test all handle_sandbox_ -- --nocapture`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18287).
  * #18288
  * __->__ #18287

  Michael Bolin · 2026-04-23 12:46:19 -07:00
  9c0eced391
• [rollout_trace] Trace tool and code-mode boundaries (#18878)

  ## Summary
  
  Extends rollout tracing across tool dispatch and code-mode runtime
  boundaries. This records canonical tool-call lifecycle events and links
  code-mode execution/wait operations back to the model-visible calls that
  caused them.
  
  ## Stack
  
  This is PR 3/5 in the rollout trace stack.
  
  - [#18876](https://github.com/openai/codex/pull/18876): Add rollout
  trace crate
  - [#18877](https://github.com/openai/codex/pull/18877): Record core
  session rollout traces
  - [#18878](https://github.com/openai/codex/pull/18878): Trace tool and
  code-mode boundaries
  - [#18879](https://github.com/openai/codex/pull/18879): Trace sessions
  and multi-agent edges
  - [#18880](https://github.com/openai/codex/pull/18880): Add debug trace
  reduction command
  
  ## Review Notes
  
  This PR is about attribution. Reviewers should focus on whether direct
  tool calls, code-mode-originated tool calls, waits, outputs, and
  cancellation boundaries are recorded with enough source information for
  deterministic reduction without coupling the reducer to live runtime
  internals.
  
  The stack remains valid after this layer: tool and code-mode traces
  reduce through the existing crate model, while the broader session and
  multi-agent relationships are added in the next PR.

  cassirer-openai · 2026-04-23 12:22:11 -07:00
  6d09b6752d
• mcp: include permission profiles in sandbox state (#18286)

  ## Why
  
  MCP tool calls can receive a serialized `SandboxState` when a server
  declares the sandbox-state capability. That state is one of the places
  MCP runtimes learn what permissions Codex is operating under. As the
  permissions migration makes `PermissionProfile` the canonical
  representation, MCP consumers should be able to read that profile
  directly instead of reconstructing permissions from the legacy
  `SandboxPolicy`.
  
  ## What changed
  
  - Adds optional `permissionProfile` to `codex_mcp::SandboxState`, while
  keeping `sandboxPolicy` for existing MCP consumers.
  - Populates `permissionProfile` from the current `TurnContext` when
  serializing sandbox state for MCP tool calls.
  
  ## Verification
  
  - Current GitHub Actions for this PR are passing.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18286).
  * #18288
  * #18287
  * __->__ #18286

  Michael Bolin · 2026-04-23 12:21:26 -07:00
  ff22982d75
• tui: carry permission profiles on user turns (#18285)

  ## Why
  
  Per-turn permission overrides should use the same canonical profile
  abstraction as session configuration. That lets TUI submissions preserve
  exact configured permissions without round-tripping through legacy
  sandbox fields.
  
  ## What changed
  
  This adds `permission_profile` to user-turn operations, threads it
  through TUI/app-server submission paths, fills the new field in existing
  test fixtures, and adds coverage that composer submission includes the
  configured profile.
  
  ## Verification
  
  - `cargo test -p codex-tui permissions -- --nocapture`
  - `cargo test -p codex-core --test all permissions_messages --
  --nocapture`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18285).
  * #18288
  * #18287
  * #18286
  * __->__ #18285

  Michael Bolin · 2026-04-23 11:54:17 -07:00
  f90cc0ee64
• Add remote thread config endpoint (#18908)

  ## Why
  
  App-server needs a way to fetch thread-scoped config from the remote
  thread config service when the user config opts into that behavior. This
  mirrors the existing experimental remote thread store endpoint while
  keeping local/noop behavior as the default.
  
  Startup paths also need to avoid silently dropping the remote config
  endpoint after the first config load. The stdio app-server path
  discovers the endpoint from the initial config and installs the real
  thread config loader for later config builds, while in-process clients
  used by TUI/exec now select the same remote loader directly from their
  provided config.
  
  ## What changed
  
  - Added `experimental_thread_config_endpoint` to `ConfigToml`, `Config`,
  and `core/config.schema.json`.
  - Added config parsing coverage for the new setting.
  - Updated app-server startup to select `RemoteThreadConfigLoader` from
  the initially loaded config, falling back to `NoopThreadConfigLoader`
  when unset.
  - Let `ConfigManager` replace its thread config loader after startup
  discovery so later config loads use the selected loader.
  - Updated in-process app-server client startup to pass
  `RemoteThreadConfigLoader` when its config has
  `experimental_thread_config_endpoint` set.
  
  ## Verification
  
  - Added `experimental_thread_config_endpoint_loads_from_config_toml`.
  - Added
  `runtime_start_args_use_remote_thread_config_loader_when_configured`.
  - Ran `cargo check -p codex-app-server --lib`.
  - Ran `cargo test -p codex-app-server-client`.

  Rasmus Rygaard · 2026-04-23 11:46:06 -07:00
  f11583b8f6
• Use Auto-review wording for fallback rationale (#19168)

  ## Why
  
  PR #18797 currently surfaces fallback rationale text that names Guardian
  directly.
  
  ## What changed
  
  - Updated the bare allow and bare deny fallback rationales in
  `codex-rs/core/src/guardian/prompt.rs` from Guardian to Auto-review.
  - Updated the existing bare allow parser test and added explicit bare
  deny parser coverage.
  
  ## Verification
  
  - `cargo test -p codex-core parse_guardian_assessment_treats_bare`

  maja-openai · 2026-04-23 11:42:43 -07:00
  cff337e4e3
• Move marketplace add/remove and startup sync out of core. (#19099)

  Move more things to core-plugins.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-23 11:27:17 -07:00
  198eddd25d
• [codex] Implement remote thread store methods (#19008)
  Tom · 2026-04-23 17:49:28 +00:00
  f1061d9d07
• [codex] Route live thread writes through ThreadStore (#18882)

  Begin migrating the thread write codepaths to ThreadStore.
  
  This starts using ThreadStore inside of core session code, not only in
  the app server code.
  
  Rework the interfaces around thread recording/persistence. We're left
  with the following:
  
  * `ThreadManager`: owns the process-level registry of loaded threads and
  handles cross-thread orchestration: start, resume, fork, lookup, remove,
  and route ops to running CodexThreads.
  * `CodexThread`: represents one loaded/running thread from the outside.
  It is the handle app-server and callers use to submit ops, inspect
  session metadata, and shut the thread down.
  * `LiveThread`: session-owned persistence lifecycle handle for one
  active thread. Core session code uses it to append rollout items,
  materialize lazy persistence, flush, shutdown, discard init-failed
  writers, and load that thread’s persisted history.
  * `ThreadStore`: storage backend abstraction. It answers “how are
  threads persisted, read, listed, updated, archived?” Local and remote
  implementations live behind this trait.
  * `LocalThreadStore`: local ThreadStore implementation. It owns the
  file/sqlite-specific details and keeps RolloutRecorder as a local
  implementation detail.
  
  This is a few too many Thread abstractions for my liking, but they do
  all represent different concepts / needs / layers.
  
  Migration note: in places where the core code explicitly requires a
  path, rather than a thread ID, throw an error if we're running with a
  remote store.
  
  Cover the new local live-writer lifecycle with focused tests and
  preserve app-server thread-start behavior, including ephemeral pathless
  sessions.

  Tom · 2026-04-23 10:17:09 -07:00
  f1923a38b1
• feat: drop spawned-agent context instructions (#19127)

  ## Why
  
  MultiAgentV2 children should not receive an extra model-visible
  developer fragment just because they were spawned. The parent/configured
  developer instructions should carry through normally, but the dedicated
  `<spawned_agent_context>` block is no longer desired.
  
  ## What changed
  
  - Removed the `SpawnAgentInstructions` context fragment and its
  `<spawned_agent_context>` wrapper.
  - Stopped appending spawned-agent instructions in
  `codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs`.
  - Updated subagent notification coverage to assert inherited parent
  developer instructions without expecting the spawned-agent wrapper.
  
  ## Verification
  
  - `cargo test -p codex-core --test all
  spawned_multi_agent_v2_child_inherits_parent_developer_context --
  --nocapture`
  - `cargo test -p codex-core --test all
  skills_toggle_skips_instructions_for_parent_and_spawned_child --
  --nocapture`
  - `cargo test -p codex-core --test all subagent_notifications --
  --nocapture`

  jif-oai · 2026-04-23 18:54:45 +02:00
  a2f868c9d6
• Reject agents.max_threads with multi_agent_v2 (#19129)

  ## Why
  
  `multi_agent_v2` uses the v2 agent lifecycle, so accepting the legacy
  `agents.max_threads` limit alongside it creates conflicting
  configuration semantics. Config load should fail early with a clear
  error instead of allowing both knobs to be set.
  
  ## What Changed
  
  - During config load, detect when the effective `multi_agent_v2` feature
  is enabled and `agents.max_threads` is explicitly set.
  - Return an `InvalidInput` error: `agents.max_threads cannot be set when
  multi_agent_v2 is enabled`.
  
  ## Verification
  
  - `cargo test -p codex-core multi_agent_v2_rejects_agents_max_threads`
  passed locally with a temporary focused test for this behavior.
  - `cargo test -p codex-core` was also run; the new focused path passed,
  but the crate suite has unrelated pre-existing failures in managed
  config/proxy/request-permissions tests.

  jif-oai · 2026-04-23 13:31:54 +02:00
  d3b044938d
• Fix auto-review config compatibility across protocol and SDK (#19113)

  ## Why
  
  This keeps the partial Guardian subagent -> Auto-review rename
  forward-compatible across mixed Codex installations. Newer binaries need
  to understand the new `auto_review` spelling, but they cannot write it
  to shared `~/.codex/config.toml` yet because older CLI/app-server
  bundles only know `user` and `guardian_subagent` and can fail during
  config load before recovering.
  
  The Python SDK had the opposite compatibility gap: app-server responses
  can contain `approvalsReviewer: "auto_review"`, but the checked-in
  generated SDK enum did not accept that value.
  
  ## What Changed
  
  - Keep `ApprovalsReviewer::AutoReview` readable from both
  `guardian_subagent` and `auto_review`, while serializing it as
  `guardian_subagent` in both protocol crates.
  - Update TUI Auto-review persistence tests so enabling Auto-review
  writes `approvals_reviewer = "guardian_subagent"` while UI copy still
  says Auto-review.
  - Map managed/cloud `feature_requirements.auto_review` to the existing
  `Feature::GuardianApproval` gate without adding a broad local
  `[features].auto_review` key or changing config writes.
  - Add `auto_review` to the Python SDK `ApprovalsReviewer` enum and cover
  `ThreadResumeResponse` validation.
  
  ## Testing
  
  - `cargo test -p codex-protocol approvals_reviewer`
  - `cargo test -p codex-app-server-protocol approvals_reviewer`
  - `cargo test -p codex-tui
  update_feature_flags_enabling_guardian_selects_auto_review`
  - `cargo test -p codex-tui
  update_feature_flags_enabling_guardian_in_profile_sets_profile_auto_review_policy`
  - `cargo test -p codex-core
  feature_requirements_auto_review_disables_guardian_approval`
  - `pytest
  sdk/python/tests/test_client_rpc_methods.py::test_thread_resume_response_accepts_auto_review_reviewer`
  - `git diff --check`

  Won Park · 2026-04-23 03:12:56 -07:00
  17ae906048
• Support MCP tools in hooks (#18385)

  ## Summary
  
  Lifecycle hooks currently treat `PreToolUse`, `PostToolUse`, and
  `PermissionRequest` as Bash-only flows
  - hook schema constrains `tool_name` to `Bash`
  - hook input assumes a command-shaped `tool_input`
  - core hook dispatch path passes only shell command strings
  
  That means hooks cannot target MCP tools even though MCP tool names are
  model-visible and stable
  
  This change generalizes those hook paths so they can match and receive
  payloads for MCP tools while preserving the existing Bash behavior.
  
  ## Reviewer Notes
  
  I think these are the key files
  - `codex-rs/core/src/tools/handlers/mcp.rs`
  - `codex-rs/core/src/mcp_tool_call.rs`
  
  Otherwise the changes across apply_patch, shell, and unified_exec are
  mainly to rewire everything to be `tool_input` based instead of just
  `command` so that it'll make sense for MCP tools.
  
  ## Changes
  
  - Allow `PreToolUse`, `PostToolUse`, and `PermissionRequest` hook inputs
  to carry arbitrary `tool_name` and `tool_input` values instead of
  hard-coding `Bash` and command-only payloads.
  - Add MCP hook payload support through `McpHandler`, using the
  model-visible tool name from `ToolInvocation` and the raw MCP arguments
  as `tool_input`.
  - Include MCP tool responses in `PostToolUse` by serializing
  `McpToolOutput` into the hook response payload.
  - Run `PermissionRequest` hooks for MCP approval requests after
  remembered approval checks and before falling back to user-facing MCP
  elicitation.
  - Preserve exact matching for literal hook matchers like `Bash` and
  `mcp__memory__create_entities`, while keeping regex matcher support for
  patterns like `mcp__memory__.*` and `mcp__.*__write.*`.
  
  ---------
  
  Co-authored-by: Andrei Eternal <eternal@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-23 07:33:57 +00:00
  305825abd9
• feat: Warn and continue on unknown feature requirements (#19038)

  Requirements feature flags now fail open like config feature flags, but
  with a startup warning.
  
  <img width="443" height="68" alt="image"
  src="https://github.com/user-attachments/assets/76767fa7-8ce8-4fc7-8a09-902fcdda6298"
  />

  xl-openai · 2026-04-22 22:50:44 -07:00
  951be1a8a1
• Add safety check notification and error handling (#19055)

  Adds a new app-server notification that fires when a user account has
  been flagged for potential safety reasons.

  Eric Traut · 2026-04-22 22:24:12 -07:00
  bbff4ee61a
• Default Fast service tier for eligible ChatGPT plans (#19053)

  ## Why
  
  Enterprise and business-like ChatGPT plans should get Codex's Fast
  service tier by default when the user or caller has not made an explicit
  service-tier choice. At the same time, callers need a durable way to
  choose standard routing without adding a new persisted `standard`
  service tier value. This keeps existing config compatibility while
  letting core own the managed default policy.
  
  ## What changed
  
  - Resolve the effective service tier in core at session creation:
  explicit `fast` or `flex` wins, explicit null/clear or
  `[notice].fast_default_opt_out = true` resolves to standard routing, and
  otherwise eligible ChatGPT plans resolve to Fast when FastMode is
  enabled.
  - Add `[notice].fast_default_opt_out` as the persisted opt-out marker
  for managed Fast defaults.
  - Treat app-server/TUI `service_tier: null` as an explicit
  standard/clear choice by preserving that intent through config loading.
  - Update TUI rendering to use core's effective service tier for startup
  and status surfaces while still keeping `config.service_tier` as the
  explicit configured choice.
  - Update `/fast off` to clear `service_tier`, persist the opt-out
  marker, and send explicit standard for subsequent turns.
  
  ## Verification
  
  - Added unit coverage for config override/notice handling, service-tier
  resolution, runtime null clearing, and `/fast off` turn propagation.
  - `cargo build -p codex-cli`
  
  Full test suite was not run locally per author request.

  Shijie Rao · 2026-04-22 21:54:44 -07:00
  02170996e6
• protocol: report session permission profiles (#18282)

  ## Why
  
  Clients that observe `SessionConfigured` need the same canonical
  permission view that app-server thread responses provide. Reporting the
  profile in protocol events lets clients keep their local state
  synchronized without reinterpreting legacy sandbox fields.
  
  ## What changed
  
  This adds `permission_profile` to `SessionConfigured` and propagates it
  through core, exec JSON output, MCP server messages, and TUI
  history/widget handling.
  
  ## Verification
  
  - `cargo test -p codex-tui permissions -- --nocapture`
  - `cargo test -p codex-core --test all permissions_messages --
  --nocapture`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18282).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * #18283
  * __->__ #18282

  Michael Bolin · 2026-04-22 21:29:32 -07:00
  082fc4f632
• codex: support hooks in config.toml and requirements.toml (#18893)

  ## Summary
  
  Support the existing hooks schema in inline TOML so hooks can be
  configured from both `config.toml` and enterprise-managed
  `requirements.toml` without requiring a separate `hooks.json` payload.
  
  This gives enterprise admins a way to ship managed hook policy through
  the existing requirements channel while still leaving script delivery to
  MDM or other device-management tooling, and it keeps `hooks.json`
  working unchanged for existing users.
  
  This also lays the groundwork for follow-on managed filtering work such
  as #15937, while continuing to respect project trust gating from #14718.
  It does **not** implement `allow_managed_hooks_only` itself.
  
  NOTE: yes, it's a bit unfortunate that the toml isn't formatted as
  closely as normal to our default styling. This is because we're trying
  to stay compatible with the spec for plugins/hooks that we'll need to
  support & the main usecase here is embedding into requirements.toml
  
  ## What changed
  
  - moved the shared hook serde model out of `codex-rs/hooks` into
  `codex-rs/config` so the same schema can power `hooks.json`, inline
  `config.toml` hooks, and managed `requirements.toml` hooks
  - added `hooks` support to both `ConfigToml` and
  `ConfigRequirementsToml`, including requirements-side `managed_dir` /
  `windows_managed_dir`
  - treated requirements-managed hooks as one constrained value via
  `Constrained`, so managed hook policy is merged atomically and cannot
  drift across requirement sources
  - updated hook discovery to load requirements-managed hooks first, then
  per-layer `hooks.json`, then per-layer inline TOML hooks, with a warning
  when a single layer defines both representations
  - threaded managed hook metadata through discovered handlers and exposed
  requirements hooks in app-server responses, generated schemas, and
  `/debug-config`
  - added hook/config coverage in `codex-rs/config`, `codex-rs/hooks`,
  `codex-rs/core/src/config_loader/tests.rs`, and
  `codex-rs/core/tests/suite/hooks.rs`
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-app-server config_api`
  
  ## Documentation
  
  Companion updates are needed in the developers website repo for:
  
  - the hooks guide
  - the config reference, sample, basic, and advanced pages
  - the enterprise managed configuration guide
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  Andrei Eternal · 2026-04-22 21:20:09 -07:00
  2b2de3f38b
• feat(request-permissions) approve with strict review (#19050)

  ## Summary
  Allow the user to approve a request_permissions_tool request with the
  condition that all commands in the rest of the turn are reviewed by
  guardian, regardless of sandbox status.
  
  ## Testing
  - [x] Added unit tests
  - [x] Ran locally

  Dylan Hurd · 2026-04-23 01:56:32 +00:00
  5e71da1424
• chore(auto-review) feature => stable (#19063)

  ## Summary
  Turn on Auto Review
  
  ## Testing
  - [x] Update unit tests

  Dylan Hurd · 2026-04-22 18:51:39 -07:00
  c6ab601824
• core: box multi-agent wrapper futures (#19059)

  ## Why
  
  While debugging the Windows stack overflows we saw in
  [#13429](https://github.com/openai/codex/pull/13429) and then again in
  [#18893](https://github.com/openai/codex/pull/18893), I hit another
  overflow in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`.
  
  That test drives the legacy multi-agent spawn / close / resume path. The
  behavior was fine, but several thin async wrappers were still inlining
  much larger `AgentControl` futures into their callers, which was enough
  to overflow the default Windows stack.
  
  ## What
  
  - Box the thin `AgentControl` wrappers around `spawn_agent_internal`,
  `resume_single_agent_from_rollout`, and `shutdown_agent_tree`.
  - Box the corresponding legacy `multi_agents` handler calls in `spawn`,
  `resume_agent`, and `close_agent`.
  - Keep behavior unchanged while reducing future size on this call path
  so the Windows test no longer overflows its stack.
  
  ## Testing
  
  - `cargo test -p codex-core --lib
  tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed
  -- --exact --nocapture`
  - `cargo test -p codex-core` (this still hit unrelated local
  integration-test failures because `codex.exe` / `test_stdio_server.exe`
  were not present in this shell; the relevant unit tests passed)

  Michael Bolin · 2026-04-22 17:48:13 -07:00
  3cc3763e6c
• Rename approvals reviewer variant to auto-review (#19056)

  ## Why
  
  `approvals_reviewer` now uses `auto_review` as the canonical config/API
  value after #18504, but the Rust enum variant and nearby helper/test
  names still used `GuardianSubagent` / guardian approval wording. That
  made follow-up code and reviews confusing even though the external value
  had already moved to Auto-review.
  
  ## What changed
  
  - Renamed `ApprovalsReviewer::GuardianSubagent` to
  `ApprovalsReviewer::AutoReview`.
  - Updated protocol, app-server, config, core, TUI, exec, and analytics
  test callsites.
  - Renamed nearby helper/test names from guardian approval wording to
  Auto-review wording where they refer to the approvals reviewer mode.
  - Preserved wire compatibility:
    - `auto_review` remains the canonical serialized value.
    - `guardian_subagent` remains accepted as a legacy alias.
  
  This intentionally does not rename the `[features].guardian_approval`
  key, `Feature::GuardianApproval`, `core/src/guardian`, analytics event
  names, or app-server Guardian review event types.
  
  ## Verification
  
  - `cargo test -p codex-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
  - `cargo test -p codex-app-server-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
  - `cargo test -p codex-config approvals_reviewer`
  - `cargo test -p codex-tui update_feature_flags`
  - `cargo test -p codex-core permissions_instructions`
  - `cargo test -p codex-tui permissions_selection`

  Won Park · 2026-04-22 17:22:35 -07:00
  83ec1eb5d6
• hooks: emit Bash PostToolUse when exec_command completes via write_stdin (#18888)

  Fixes #16246.
  
  ## Why
  
  `exec_command` already emits `PreToolUse`, but long-running unified exec
  commands that finish on a later `write_stdin` poll could miss the
  matching `PostToolUse`. That left the Bash hook lifecycle inconsistent,
  broke expectations around `tool_use_id` and `tool_input.command`, and
  meant `PostToolUse` block/replacement feedback could fail to replace the
  final session output before it reached model context.
  
  This keeps the fix scoped to the `exec_command` / `write_stdin`
  lifecycle. Broader non-Bash hook expansion is still out of scope here
  and remains tracked separately in #16732.
  
  ## What changed
  
  - Compute and store `PostToolUsePayload` while handlers still have
  access to their concrete output type, and carry `tool_use_id` through
  that payload.
  - Preserve the original hook-facing `exec_command` string through
  unified exec state (`ExecCommandRequest`, `ProcessEntry`,
  `PreparedProcessHandles`, and `ExecCommandToolOutput`) via
  `hook_command`, and remove the now-unused `session_command` output
  metadata.
  - Emit exactly one Bash `PostToolUse` for long-running `exec_command`
  sessions when a later `write_stdin` poll observes final completion,
  using the original `exec_command` call id and hook-facing command.
  - Keep one-shot `exec_command` behavior aligned with the same payload
  construction, including interactive completions that return a final
  result directly.
  - Apply `PostToolUse` block/replacement feedback before the final
  `write_stdin` completion output is sent back to the model.
  - Keep `write_stdin` itself out of `PreToolUse` matching so it continues
  to act as transport/polling for the original Bash tool call.
  - Restore plain matcher behavior for tool-name matchers such as `Bash`
  and `Edit|Write`, while still treating patterns with regex characters
  (for example `mcp__.*`) as regexes.
  - Add unit coverage for unified exec payload construction and parallel
  session separation, plus a core integration regression that verifies a
  blocked `PostToolUse` replaces the final `write_stdin` output in model
  context.
  
  ## Testing
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-core post_tool_use_payload`
  - `cargo test -p codex-core
  post_tool_use_blocks_when_exec_session_completes_via_write_stdin`

  Andrei Eternal · 2026-04-22 17:14:22 -07:00
  eed0e07825