3201 Commits

• feat: add network proxy feature flag (#20147)

  ## Why
  
  The permissions migration is making
  `permissions.<profile>.network.enabled` the canonical sandbox network
  bit, while proxy startup is a separate concern. Enabling network access
  should not implicitly start the proxy, and users who are still on legacy
  sandbox modes need a separate place to opt into proxy startup and
  provide proxy-specific settings.
  
  This follow-up to #19900 gives the network proxy its own feature surface
  instead of overloading permission-profile network semantics.
  
  ## What changed
  
  - Add an experimental `network_proxy` feature with a configurable
  `[features.network_proxy]` table.
  - Overlay `features.network_proxy` settings onto the configured proxy
  state after permission-profile selection, so the proxy only starts when
  the active `NetworkSandboxPolicy` already allows network access.
  - Preserve `[experimental_network]` startup behavior independently of
  the new feature flag.
  
  ## Behavior and examples
  
  There are now three related knobs:
  
  - `permissions.<profile>.network.enabled` controls whether the active
  permission profile has network access at all.
  - `features.network_proxy` enables proxy restrictions for an
  already-network-enabled profile.
  - Legacy `sandbox_mode` plus `[sandbox_workspace_write].network_access`
  still control whether legacy `workspace-write` has network access at
  all.
  
  The rule is:
  
  - network off + proxy flag on -> network stays off, proxy is a no-op
  - network on + proxy flag off -> unrestricted direct network
  - network on + proxy flag on -> network stays on, with proxy
  restrictions applied
  
  For permission profiles, the feature toggle adds proxy restrictions only
  when network access is already enabled:
  
  ```toml
  default_permissions = "workspace"
  
  [permissions.workspace.filesystem]
  ":minimal" = "read"
  
  [permissions.workspace.network]
  enabled = true
  
  [features]
  network_proxy = true
  ```
  
  If `network.enabled = false`, the same feature flag is a no-op: network
  remains off and the proxy does not start.
  
  For legacy sandbox config, `network_access` remains the master switch:
  
  ```toml
  sandbox_mode = "workspace-write"
  
  [sandbox_workspace_write]
  network_access = true
  
  [features]
  network_proxy = true
  ```
  
  That keeps legacy `workspace-write` network access on, but routes it
  through the proxy policy. If `network_access = false`, the proxy feature
  is a no-op and legacy `workspace-write` remains offline.
  
  The same proxy opt-in can be supplied from the CLI:
  
  ```bash
  codex -c 'features.network_proxy=true'
  ```
  
  Additional proxy settings can be supplied when a table is needed:
  
  ```bash
  codex \
    -c 'features.network_proxy.enabled=true' \
    -c 'features.network_proxy.enable_socks5=false'
  ```
  
  The intended behavior matrix is:
  
  | Config surface | Network setting | `features.network_proxy` | Direct
  sandbox network | Proxy |
  | --- | --- | --- | --- | --- |
  | Permission profile | `network.enabled = false` | off | restricted |
  off |
  | Permission profile | `network.enabled = false` | on | restricted | off
  |
  | Permission profile | `network.enabled = true` | off | enabled | off |
  | Permission profile | `network.enabled = true` | on | enabled | on |
  | Legacy `workspace-write` | `network_access = false` | off | restricted
  | off |
  | Legacy `workspace-write` | `network_access = false` | on | restricted
  | off |
  | Legacy `workspace-write` | `network_access = true` | off | enabled |
  off |
  | Legacy `workspace-write` | `network_access = true` | on | enabled | on
  |
  
  `[experimental_network]` requirements remain separate from the user
  feature toggle and still start the proxy on their own.
  
  Relevant code:
  -
  [`features/src/feature_configs.rs`](https://github.com/openai/codex/blob/43785aff47/codex-rs/features/src/feature_configs.rs#L58-L117)
  defines the feature-specific proxy config.
  -
  [`core/src/config/mod.rs`](https://github.com/openai/codex/blob/43785aff47/codex-rs/core/src/config/mod.rs#L1959-L1964)
  reads the feature table, and [later applies it only when network access
  is already
  enabled](https://github.com/openai/codex/blob/43785aff47/codex-rs/core/src/config/mod.rs#L2448-L2458).
  
  ## Verification
  
  Added focused coverage for:
  - keeping the proxy off when `features.network_proxy` is enabled but
  sandbox network access is disabled
  - the full permission-profile and legacy `workspace-write` matrix above
  - preserving `[experimental_network]` startup without the feature
  - reusing profile-supplied proxy settings when the feature is enabled
  
  Ran:
  - `cargo test -p codex-features`
  - `cargo test -p codex-core network_proxy_feature`
  - `cargo test -p codex-core
  experimental_network_requirements_enable_proxy_without_feature`

  viyatb-oai · 2026-05-11 14:12:00 -07:00
  c7b55cdc46
• [elicitation] Advertise new url elicitation capability when auth_elicitation is enabled. (#22188)

  ## Why
  
  We've added support for auth elicitation behind the auth_elicitation
  flag, but servers need to explicitly check the capability before it
  decides to send elicitations in order to be backward compatible. This PR
  adds the capability advertising conditioned on the flag.
  
  ## What changed
  
  - Build `client_elicitation_capability` from the `AuthElicitation`
  feature state.
  - Thread that capability through MCP config, session startup, and
  `McpConnectionManager` so RMCP initialization advertises the correct
  elicitation support.
  - Advertise both `form` and `url` elicitation when the feature is
  enabled, and preserve the empty default capability when it is disabled.
  - Add coverage for the feature-derived config shape and the advertised
  initialization payload.
  
  ## Testing
  
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-core
  to_mcp_config_preserves_auth_elicitation_feature_from_config`
  - `cargo test -p codex-core` *(currently fails outside this change in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`
  with a stack overflow after unrelated tests have started running)*

  Matthew Zeng · 2026-05-11 12:23:55 -07:00
  192481d1a1
• feat(connectors): support managed app tool approval requirements (#21061)

  ## Why
  
  Managed requirements can already centrally disable apps, but they could
  not express the per-tool app approval rules that normal config already
  supports. That left admins without a way to enforce connector tool
  approvals through `/etc/codex/requirements.toml` or cloud requirements.
  
  ## What changed
  
  - Extend app requirements with per-tool `approval_mode` entries.
  - Merge managed app tool requirements across managed sources while
  preserving higher-precedence exact tool settings.
  - Apply managed tool approvals separately from user app config so
  managed policy is matched only on raw MCP `tool.name`, while user config
  keeps the existing raw-name-then-title convenience fallback.
  - Add coverage for local requirements, cloud requirements parsing,
  managed-over-user precedence, and a title-collision case that must not
  widen managed auto-approval.
  
  ## Configuration shape
  
  Local `/etc/codex/requirements.toml` and cloud requirements use the same
  TOML shape:
  
  ```toml
  [apps.connector_123123.tools."calendar/list_events"]
  approval_mode = "approve"
  ```
  
  This is a per-tool approval rule keyed by app ID and raw MCP tool name,
  not an app-level boolean such as `apps.connector_123123.approve = true`.

  viyatb-oai · 2026-05-11 19:08:26 +00:00
  d0fa2d81d8
• fix(permissions): preserve managed deny-read during escalation (#15977)

  ## Why
  
  Managed filesystem `deny_read` requirements are administrator-enforced
  restrictions on specific paths. Once those requirements are active,
  Codex should not drop them just because an execution path would
  otherwise leave the sandbox.
  
  Before this change, an explicit escalation, a prefix-rule allow, a
  sandbox-denial retry, or an app-server legacy sandbox override could
  rebuild the runtime policy without those managed read-deny entries and
  expose a path the administrator had marked unreadable.
  
  This is narrower than general sandbox-mode constraints. If an enterprise
  only sets `allowed_sandbox_modes`, a trusted `prefix_rule(..., decision
  = "allow")` can still run its matching command unsandboxed; this PR only
  preserves managed filesystem `deny_read` restrictions across those
  paths.
  
  ## What Changed
  
  - Mark filesystem policies built from managed `deny_read` requirements
  so callers can tell when those deny entries must survive escalation.
  - Preserve managed deny-read entries when runtime permission profiles
  are rebuilt through protocol, app-server, or legacy sandbox-policy
  compatibility paths.
  - Keep managed deny-read attempts inside the selected sandbox on the
  first attempt and after sandbox-denial retries.
  - Preserve the same behavior in the zsh-fork escalation path, including
  prefix-rule-driven escalation.
  - Add a regression test showing the opposite case too: without managed
  deny-read, a prefix-rule allow still chooses unsandboxed execution.
  
  ## Verification
  
  Targeted automated verification:
  
  ```shell
  cargo test -p codex-core shell_request_escalation_execution_is_explicit -- --nocapture
  cargo test -p codex-core prefix_rule_uses_unsandboxed_execution_without_managed_deny_read -- --nocapture
  cargo test -p codex-core prefix_rule_preserves_managed_deny_read_escalation -- --nocapture
  cargo test -p codex-protocol permission_profile_round_trip_preserves_filesystem_policy_metadata -- --nocapture
  cargo test -p codex-protocol preserving_deny_entries_keeps_unrestricted_policy_enforceable -- --nocapture
  cargo test -p codex-app-server-protocol permission_profile_file_system_permissions_preserves_policy_metadata -- --nocapture
  cargo check -p codex-app-server -p codex-tui
  ```
  
  Smoke-test invocations:
  
  ```shell
  # macOS exact deny + allowed control
  codex exec --skip-git-repo-check -C "$ROOT" \
    -c 'default_permissions="deny_read_smoke"' \
    -c 'permissions.deny_read_smoke.filesystem={":minimal"="read",":project_roots"={"."="write","secrets"="none","future-secret"="none","**/*.env"="none"}}' \
    'Run shell commands only. Print the contents of allowed.txt. Then test whether reading secrets/exact-secret.txt succeeds without printing that file if it does. End with exactly two lines: allowed=<contents> and exact_secret=<BLOCKED or READABLE>.'
  
  # Linux exact deny + allowed control
  codex exec --skip-git-repo-check -C "$ROOT" \
    -c 'default_permissions="deny_read_smoke"' \
    -c 'permissions.deny_read_smoke.filesystem={":minimal"="read",glob_scan_max_depth=3,":project_roots"={"."="write","secrets"="none","future-secret"="none","**/*.env"="none"}}' \
    'Run shell commands only. Print the contents of allowed.txt. Then test whether reading secrets/exact-secret.txt succeeds without printing that file if it does. End with exactly two lines: allowed=<contents> and exact_secret=<BLOCKED or READABLE>.'
  ```
  
  Observed manual smoke matrix:
  
  | Case | macOS Seatbelt | Linux bubblewrap |
  | --- | --- | --- |
  | `cat allowed.txt` | Pass | Pass |
  | `cat secrets/exact-secret.txt` | Blocked | Blocked |
  | `cat envs/root.env` | Blocked | Blocked |
  | `cat envs/nested/one.env` | Blocked | Blocked |
  | `cat envs/nested/two.env` | Blocked | Blocked |
  | `cat alias-to-secrets/exact-secret.txt` | Blocked | Blocked |
  | Missing denied path | A file created after sandbox setup remained
  unreadable | Creation was blocked by the reserved missing-path
  placeholder, and the placeholder was cleaned up after exit |
  | Real `codex exec` shell turn | Pass | Pass |
  
  Notes:
  
  - The Linux smoke run used the fallback glob walker because the devbox
  did not have `rg` installed.
  - The smoke matrix verifies the end-to-end filesystem behavior on macOS
  and Linux; the escalation-specific behavior is covered by the focused
  tests above.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: Charlie Marsh <charliemarsh@openai.com>

  viyatb-oai · 2026-05-11 11:49:44 -07:00
  6506765168
• fix(exec-policy) use is_known_safe_command less (#20305)

  ## Summary
  Restricts behavior of `is_known_safe_command` only to modes where it is
  explicitly part of the documented behavior:
  - when `environment_lacks_sandbox_protections`
  - in `AskForApproval::UnlessTrusted`
  
  Notably, as a result of this, escalations for commands that pass
  `is_known_safe_commands` are no longer auto-approved in
  AskForApproval::OnRequest or AskForApproval::Granular.
  
  ## Testing
  - [x] Updated unit tests
  - [x] Updated approvals scenario tests.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Dylan Hurd · 2026-05-11 11:37:53 -07:00
  e783dab44c
• Unified mentions in TUI (#19068)

  This PR replaces the TUI’s file-only `@mention` popup with a unified
  mentions experience. Typing `@...` now searches across filesystem
  matches, installed plugins, and skills in one popup, with result types
  clearly labeled and selectable from the same flow.
  
  - Adds a unified `@mentions` popup that returns:
    - plugins
    - skills
    - files
    - directories
  
  - Adds search modes so users can narrow the popup without changing their
  query:
    - All Results _(default/same as Codex App)_
    - Filesystem Only
    - Plugins _(...and skills)_
  
  - Preserves existing insertion behavior:
    - selected file paths are inserted into the prompt
    - paths with spaces are quoted
    - image file selections still attach as images when possible
    - selecting a plugin or skill inserts the corresponding `$name`
  - the composer records the canonical mention binding, such as
  `plugin://...` or the skill path
  
  - Expanded `@mentions` rendering:
    - type tags for Plugin, Skill, File, and Dir
    - distinct plugin/filesystem colors
    - stable fixed-height layout (8 rows)
    - truncation behavior for narrow terminals
  
  Note:
  - The unified mentions popup does not display app connectors under
  `@mention` results for Codex App parity. Connector mentions remain
  available through the existing `$mention` path.
  
  
  https://github.com/user-attachments/assets/f93781ed-57d3-4cb5-9972-675bc5f3ef3f

  canvrno-oai · 2026-05-11 11:34:52 -07:00
  eaf05c9002
• Add process-scoped SQLite telemetry (#22154)

  ## Summary
  - add SQLite init, backfill-gate, and fallback telemetry without
  introducing a cross-cutting state-db access wrapper
  - install one process-scoped telemetry sink after OTEL startup and let
  low-level state/rollout paths emit through it directly
  - add process-start metrics for the process owners that initialize
  SQLite
  
  ---------
  
  Co-authored-by: Owen Lin <owen@openai.com>

  jif-oai · 2026-05-11 11:32:40 -07:00
  b401666ca5
• Make auto-review denial short-circuit use a rolling review window (#22110)

  ## Why
  
  Long-running turns can accumulate enough denied auto-review decisions to
  trip the global short-circuit even when those denials are spread far
  apart. The breaker should still stop genuinely bad loops, but it should
  judge recent behavior instead of lifetime turn history.
  
  ## What changed
  
  - Replaced the lifetime `10 total denials` threshold with `10 denials in
  the last 50 reviews`.
  - Kept the existing `3 consecutive denials` interrupt behavior
  unchanged.
  - Tracked recent auto-review outcomes in the circuit breaker and updated
  the warning copy to report the rolling-window count.
  - Renamed the new rolling-window coverage to `auto_review_*` test names.
  - Added coverage that confirms older denials fall out of the 50-review
  window and no longer trigger the breaker.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-core guardian_rejection_circuit_breaker --lib`
  - `cargo test -p codex-core auto_review_rejection_circuit_breaker --lib`

  Won Park · 2026-05-11 11:03:11 -07:00
  0dbad2a348
• Fix goal update and add /goal edit command in TUI (#21954)

  ## Why
  
  Users have requested the ability to edit a goal's objective after a goal
  has been created. This PR exposes a new `/goal edit` command in the TUI
  to address this request.
  
  In the process of implementing this, I also noticed an existing bug in
  the goal runtime. When a goal's objective is updated through the
  `thread/goal/set` app server API, the goal runtime didn't emit a new
  steering prompt to tell the agent about the new objective. This PR also
  fixes this hole.
  
  ## What Changed
  
  - Adds `/goal edit` in the TUI, opening an edit box prefilled with the
  current goal objective.
  - Keeps active and paused goals in their current state, resets completed
  goals to active, keeps budget-limited goals budget-limited, and
  preserves the existing token budget.
  - Changes the existing `thread/goal/set` behavior so editing an
  objective preserves goal accounting instead of resetting it. The older
  reset-on-new-objective behavior was left over from before
  `thread/goal/clear`; clients that need to reset accounting can now clear
  the existing goal and create a new one.
  - Reuses the existing goal set API path; this does not add or change
  app-server protocol surface area.
  - Adds a dedicated goal runtime steering prompt when an externally
  persisted goal mutation changes the objective, so active turns receive
  the updated objective.
  
  ## Validation
  
  - Make sure `/goal edit` returns an error if no goal currently exists
  - Make sure `/goal edit` displays an edit box that can be optionally
  canceled with no side effects
  - Make sure that an edited goal results in a steer so the agent starts
  pursuing the new objective
  - Make sure the new objective is reflected in the goal if you use
  `/goal` to display the goal summary
  - Make sure that `/goal edit` doesn't reset the token budget, time/token
  accounting on the updated goal

  Eric Traut · 2026-05-11 10:49:19 -07:00
  1e65b3e0af
• chore: drop built-in MCPs (#22173)

  Drop something that was never used

  jif-oai · 2026-05-11 19:45:08 +02:00
  32b1ae7099
• Improve goal continuation based on feedback (#22045)

  ## Summary
  
  This PR updates the goal continuation prompt to address feedback from
  early adopters. There are two primary changes:
  
  1. Goal continuation and budget-limit steering prompts now use hidden
  user-context messages instead of hidden developer messages.
  2. The goal continuation prompt is refined to improve the model's
  ability to fully complete the active goal rather than stop at a smaller
  or merely passing subset.
  
  The user-message transition is important for two reasons. First, it
  eliminates an issue where older steering messages could be responded to
  again after a new turn. Second, it works better with compaction because
  user messages are treated differently from developer messages during
  compaction.
  
  The prompt refinements make persistence explicit, ground work in current
  evidence, encourage `update_plan` for multi-step progress visibility,
  and require stronger completion audits before calling `update_goal`. It
  also removes the elapsed-time reporting in the prompt; I saw evidence
  that this was causing the model to shortcut work as it became nervous
  about time.
  
  These changes were tested with evals. Chriss4123 has also been running
  independent evals in
  [#19910](https://github.com/openai/codex/issues/19910), and many of the
  improvements in this PR were suggested by him.
  
  ## Verification
  
  - Tested with evals.
  - Added and updated focused `codex-core` coverage for hidden goal user
  context, continuation and budget-limit request shape, prompt rendering,
  and objective delimiter escaping.

  Eric Traut · 2026-05-11 09:51:21 -07:00
  96836e15ed
• Revert "[codex] Harden overflow auto-compaction recovery" (#22170)

  Reverts openai/codex#22141

  Ahmed Ibrahim · 2026-05-11 19:33:15 +03:00
  69f3183a8e
• [codex] Harden overflow auto-compaction recovery (#22141)

  ## Why
  Dogfooder feedback exposed two correctness gaps in normal-loop overflow
  recovery:
  
  1. a sampling request that hit `ContextWindowExceeded` could keep
  re-entering auto-compaction indefinitely if the compacted retry still
  did not fit, and
  2. local compact-history rebuilds flattened user messages down to text,
  so an overflowing `[image, "what is this?"]` turn could be retried
  without the image after compaction.
  
  That means recovery could either fail to terminate cleanly or proceed
  with a materially weakened version of the user request.
  
  ## What changed
  - Move normal-loop `ContextWindowExceeded` handling into the sampling
  retry loop, so successful rescue compaction consumes the provider retry
  budget instead of creating an unbounded outer-turn loop.
  - Keep compacted user-history rebuilds structured:
  `collect_user_messages` now carries user `UserInput` content rather than
  flattened strings, and `build_compacted_history` reconstructs full user
  messages from that structured representation.
  - Preserve image inputs while retaining the existing text-budget
  truncation behavior for compacted user history.
  - Preserve existing compaction-task failure handling and client-session
  reset behavior while bounding repeated overflow retries.
  - Add focused regression coverage for:
    - recovery after a normal-loop overflow,
    - retry-budget exhaustion after repeated overflow,
    - local recovery preserving image + text input,
    - remote recovery preserving image + text input,
    - remote compaction v2 preserving image + text input, and
    - compaction failure still terminating cleanly.
  
  The main behavior changes are in `codex-rs/core/src/session/turn.rs` and
  `codex-rs/core/src/compact.rs`.
  
  ## Verification
  - Not run locally; relying on PR CI for this update.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-11 16:16:49 +00:00
  15e79f3c26
• Add x-codex-ws-stream-request-start-ms (#22113)

  For capturing client-side timing information.

  Andrey Mishchenko · 2026-05-11 08:15:52 -07:00
  704ad620f6
• feat: move extensions tool (#22163)

  This PR is just moving stuff around

  jif-oai · 2026-05-11 17:14:43 +02:00
  8e12c12a07
• feat: wire extension tool bundles into core (#22147)

  ## Why
  
  This is the next narrow step toward moving concrete tool families out of
  core. After #22138 introduced `codex-tool-api`, we still needed a real
  end-to-end seam that lets an extension own an executable tool definition
  once and have core install it without the temporary `extension-api`
  wrapper or a dependency on `codex-tools`.
  
  `codex-tool-api` is the small extension-facing execution contract, while
  `codex-tools` still has a different job: host-side shared tool metadata
  and planning logic that is not “run this contributed tool”, like spec
  shaping, namespaces, discovery, code-mode augmentation, and
  MCP/dynamic-to-Responses API conversion
  
  ## What changed
  
  - Moved the shared leaf tool-spec and JSON Schema types into
  `codex-tool-api`, so the executable contract now lives with
  [`ToolBundle`](https://github.com/openai/codex/blob/c538758095337d4fe0a52a172363ccede4066bda/codex-rs/tool-api/src/bundle.rs#L19-L70).
  - Replaced the temporary extension-side tool wrapper with direct
  `ToolBundle` use in `codex-extension-api`.
  - Taught core to collect contributed bundles, include them in spec
  planning, register them through
  [`ToolRegistryBuilder::register_tool_bundle`](https://github.com/openai/codex/blob/c538758095337d4fe0a52a172363ccede4066bda/codex-rs/core/src/tools/registry.rs#L653-L667),
  and dispatch them through the existing router/runtime path.
  - Added focused coverage for contributed tools becoming model-visible
  and dispatchable, plus spec-planning coverage for contributed function
  and freeform tools.
  
  ## Verification
  
  - Added `extension_tool_bundles_are_model_visible_and_dispatchable` in
  `core/src/tools/router_tests.rs`.
  - Added spec-plan coverage in `core/src/tools/spec_plan_tests.rs` for
  contributed extension bundles.
  
  ## Related
  
  - Follow-up to #22138

  jif-oai · 2026-05-11 16:42:29 +02:00
  672cc1f669
• extension: move git attribution into an extension (#21738)

  ## Why
  
  Git commit attribution is prompt policy, not session orchestration.
  After #21737 adds the extension-registry seam, this moves that
  prompt-only behavior out of `codex-core` so `Session` can consume
  extension-contributed prompt fragments instead of owning a one-off
  policy path itself.
  
  Before this PR, `Session` injected the trailer instruction directly from
  `codex-core` ([session
  assembly](https://github.com/openai/codex/blob/a57a747eb667753118217b8bb47dfd1fff88cbde/codex-rs/core/src/session/mod.rs#L2733-L2739),
  [helper
  module](https://github.com/openai/codex/blob/a57a747eb667753118217b8bb47dfd1fff88cbde/codex-rs/core/src/commit_attribution.rs#L1-L33)).
  This branch moves that same responsibility into
  [`codex-git-attribution`](https://github.com/openai/codex/blob/b5029a67360fe5c948aa849d4cf65fd2597ebaae/codex-rs/ext/git-attribution/src/lib.rs#L14-L100).
  
  ## What changed
  
  - Added the `codex-git-attribution` extension crate.
  - Snapshot `CodexGitCommit` plus `commit_attribution` at thread start,
  then contribute the developer-policy fragment through the extension
  registry.
  - Register the extension in app-server thread extensions.
  - Remove the old `codex-core` helper module and direct `Session`
  injection path.
  
  This keeps the existing behavior intact: the prompt is only contributed
  when `CodexGitCommit` is enabled, blank attribution still disables the
  trailer, and the default remains `Codex <noreply@openai.com>`.
  
  ## Stack
  
  - Stacked on #21737.

  jif-oai · 2026-05-11 12:53:15 +02:00
  569ff6a1c4
• extension: wire extension registries into sessions (#21737)

  ## Why
  
  [#21736](https://github.com/openai/codex/pull/21736) introduces the
  typed extension API, but the runtime does not yet carry a registry
  through thread/session startup or give contributors host-owned stores to
  read from. This PR wires that host-side path so later feature migrations
  can move product-specific behavior behind typed contributions without
  adding another bespoke seam directly to `codex-core`.
  
  ## What changed
  
  - Thread `ExtensionRegistry<Config>` through `ThreadManager`,
  `CodexSpawnArgs`, `Session`, and sub-agent spawn paths.
  - Wire `ThreadStartContributor` and `ContextContributor`
  - Expose the small supporting surface needed by non-core callers that
  construct threads directly, including `empty_extension_registry()`
  through `codex-core-api`.
  
  This PR lands the host plumbing only: the app-server registry is still
  empty, and concrete feature migrations are intended to follow
  separately.

  jif-oai · 2026-05-11 11:38:18 +02:00
  436c0df658
• Persist 'priority' service tier as fast in config (#21991)

  ### Motivation
  - Normalize persisted service tier so selecting the request value
  `priority` (or legacy `fast`) is stored as `fast` while preserving
  unknown tier IDs and keeping request-time behavior unchanged.
  
  ### Description
  - Update persistence logic in `codex-rs/core/src/config/edit.rs` so
  `ConfigEdit::SetServiceTier` maps request values: `priority`/`fast` ->
  `"fast"`, `flex` -> `"flex"`, and leaves unknown strings unchanged.
  - Add unit tests in `codex-rs/core/src/config/edit_tests.rs` that verify
  a `priority` selection is written to `config.toml` as `"fast"` and that
  unknown tiers are preserved.
  - Add a config load test in `codex-rs/core/src/config/config_tests.rs`
  to ensure `service_tier = "priority"` still resolves to the `priority`
  request value at load time.
  - Add the required import `use
  codex_protocol::config_types::ServiceTier;` to the edited modules.
  
  ### Testing
  - Ran `just fmt` and `just fix -p codex-core` to apply formatting and
  lints and they completed successfully.
  - Ran `cargo test -p codex-core --lib service_tier` (focused unit tests
  for the change) and the tests passed.
  - Ran `cargo test -p codex-protocol` and the protocol test suite passed.
  - Note: an initial broader `cargo test -p codex-core service_tier`
  invocation matched integration tests and produced unrelated
  failures/hangs, so that run was interrupted and the focused `--lib`
  unit-test invocation was used instead.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/cloud/tasks/task_i_69ffc5a1262c8321af91b69c9845147f)

  Ahmed Ibrahim · 2026-05-10 06:22:46 +03:00
  178c3d3005
• tests: cover sandbox link write behavior (#21819)

  ## Why
  
  [PR #1705](https://github.com/openai/codex/pull/1705) moved
  `apply_patch` execution under the configured sandbox and called out the
  need for integration coverage. We already covered textual `../` escapes,
  but did not have coverage for link aliases that live inside a writable
  workspace while pointing at, or aliasing, files visible outside it.
  
  This PR locks in the current sandbox boundary without changing
  production write semantics. Symlink escapes into a read-only outside
  root should fail and leave the outside file unchanged. Existing hard
  links are characterized separately: if a user-created hard link already
  exists inside the writable root, sandboxed writes preserve normal
  hard-link semantics rather than replacing the link and silently breaking
  that relationship.
  
  ## What Changed
  
  - Added
  `apply_patch_cli_does_not_write_through_symlink_escape_outside_workspace`
  to verify `apply_patch` cannot update a symlink that targets a file
  outside the writable workspace.
  - Added `apply_patch_cli_preserves_existing_hard_link_outside_workspace`
  to verify `apply_patch` intentionally writes through an existing hard
  link and does not unlink or replace it.
  - Added `file_system_sandboxed_write_preserves_existing_hard_link` to
  verify sandboxed `fs/writeFile` preserves an existing hard link and
  writes the shared inode.
  
  ## Testing
  
  - `cargo test -p codex-exec-server file_system_sandboxed_write`
  - `cargo test -p codex-core
  apply_patch_cli_does_not_write_through_symlink_escape_outside_workspace`
  - `cargo test -p codex-core
  apply_patch_cli_preserves_existing_hard_link_outside_workspace`
  - `just fix -p codex-exec-server -p codex-core`
  - `just fix -p codex-core`
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21819).
  * #21845
  * __->__ #21819

  Michael Bolin · 2026-05-09 08:28:15 -07:00
  0c70698e24
• [codex] compact network context rendering (#21875)

  ## Why
  
  The model-visible `<network>` context currently repeats indentation and
  a pair of XML tags for every allowed or denied domain. Large domain sets
  spend a surprising amount of prompt budget on that scaffolding instead
  of the actual policy values.
  
  ## What changed
  
  - Render allowed domains as one comma-separated `<allowed>` value
  instead of one element per domain.
  - Render denied domains the same way.
  - Keep the full allow/deny domain sets model-visible while updating the
  serialization and settings-update coverage for the denser shape.
  
  ## Example
  
  Before:
  ```xml
  <network enabled="true">
    <allowed>api.example.test</allowed>
    <allowed>cdn.example.test</allowed>
    <denied>blocked.example.test</denied>
  </network>
  ```
  
  After:
  ```xml
  <network enabled="true"><allowed>api.example.test,cdn.example.test</allowed><denied>blocked.example.test</denied></network>
  ```
  
  ## Validation
  
  - `cargo test -p codex-core environment_context`
  - `cargo test -p codex-core
  build_settings_update_items_emits_environment_item_for_network_changes`
  - Ran a local `codex` session with a real network context containing 121
  allowed domains and 42 denied domains, then inspected the raw prompt
  with `raw_token_viewer_cli.py`. With the same domain set, the rendered
  `<network>` section shrank from 7,175 characters across 161 lines to
  3,666 characters on one line, and the containing environment-context
  block fell from 6,428 tokens to 5,379 tokens.

  sayan-oai · 2026-05-09 03:52:48 +00:00
  77d9223e9f
• Move file watcher out of core (#21290)

  ## Why
  
  The app-server watcher relocation leaves the generic filesystem watcher
  as the last watcher-specific implementation still living inside
  `codex-core`. Moving that code to a small crate keeps `codex-core`
  focused on thread execution and lets app-server depend on the watcher
  without reaching back into core for filesystem watching primitives.
  
  This PR is stacked on #21287.
  
  ## What changed
  
  - Added a new `codex-file-watcher` crate containing the existing watcher
  implementation and its unit tests.
  - Updated app-server `fs_watch`, `skills_watcher`, and listener state to
  import watcher types from `codex-file-watcher`.
  - Removed the `file_watcher` module and `notify` dependency from
  `codex-core`.
  - Updated Cargo workspace metadata and `Cargo.lock` for the new internal
  crate.
  
  ## Validation
  
  - `cargo check -p codex-file-watcher -p codex-core -p codex-app-server`
  - `cargo test -p codex-file-watcher`
  - `cargo test -p codex-app-server
  skills_changed_notification_is_emitted_after_skill_change`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fix -p codex-file-watcher`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`

  pakrym-oai · 2026-05-08 18:19:23 -07:00
  c579da41b1
• Reapply "Move skills watcher to app-server" (#21652)

  ## Why
  
  PR #21460 reverted the earlier move of skills change watching from
  `codex-core` into app-server. This reapplies that boundary change so
  app-server owns client-facing `skills/changed` notifications and core no
  longer carries the watcher.
  
  ## What
  
  - Restore the app-server `SkillsWatcher` and register it from thread
  listener setup.
  - Remove the core-owned skills watcher and its core live-reload
  integration surface.
  - Restore app-server coverage for `skills/changed` notifications after a
  watched skill file changes.
  
  ## Validation
  
  - `cargo test -p codex-app-server --test all
  suite::v2::skills_list::skills_changed_notification_is_emitted_after_skill_change
  -- --exact --nocapture`
  - `cargo test -p codex-core --lib --no-run`

  pakrym-oai · 2026-05-08 17:41:15 -07:00
  408e6218ab
• Make environment provider snapshots path-free (#21794)

  ## Summary
  - make EnvironmentProvider::snapshot path-free and keep providers
  focused on provider-owned remote environments
  - let provider snapshots request local inclusion via include_local, with
  environments.toml including local and CODEX_EXEC_SERVER_URL excluding
  local
  - move reserved local environment construction into EnvironmentManager
  using ExecServerRuntimePaths
  
  Follow-up to https://github.com/openai/codex/pull/20667
  
  ## Testing
  - just fmt
  - git diff --check
  - devbox: bazel build --bes_backend= --bes_results_url=
  //codex-rs/exec-server:exec-server
  - devbox: bazel test --bes_backend= --bes_results_url=
  //codex-rs/exec-server:exec-server-unit-tests
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 15:30:00 -07:00
  dac108f2f1
• Using cached connector directory for discoverable tools list (#21497)

  ## Summary
  
  Startup tool construction currently depends on connector directory
  metadata for `tool_suggest` discoverables. On a cold directory cache,
  that can put slow connector-directory requests on the blocking path even
  though the tools array only needs directory data for install
  suggestions, not for the live connector MCP tools themselves.
  
  This PR keeps the discoverables path off that cold network fetch:
  - read connector directory metadata from cache only when building
  discoverable tools
  - persist connector directory metadata to
  `~/.codex/cache/codex_app_directory/<hash>.json` and use it to hydrate
  the in-memory cache on later runs before the normal refresh path updates
  it
  - use connector-directory-specific cache naming to distinguish this
  metadata cache from the separate Codex Apps tools-spec cache
  
  This reduces first-turn startup work without changing how live connector
  MCP tools are sourced. Longer term, directory-backed install suggestions
  should move to a search-based flow so they no longer need to be inlined
  into the tools prompt at all.
  
  ## Testing
  
  - `cargo test -p codex-connectors`
  - `cargo test -p codex-chatgpt`
  - `cargo test -p codex-core
  request_plugin_install_is_available_without_search_tool_after_discovery_attempts`
  - `cargo test -p codex-core
  tool_suggest_uses_connector_id_fallback_when_directory_cache_is_empty`

  Matthew Zeng · 2026-05-08 14:14:11 -07:00
  2f3a2d7a86
• Enable --deny-warnings for cargo shear (#21616)

  ## Summary
  
  In https://github.com/openai/codex/pull/21584, we disabled doctests for
  crates that lack any doctests. We can enforce that property via `cargo
  shear --deny-warnings`: crates that lack doctests will be flagged if
  doctests are enabled, and crates with doctests will be flagged if
  doctests are disabled.
  
  A few additional notes:
  
  - By adding `--deny-warnings`, `cargo shear` also flagged a number of
  modules that were not reachable at all. Some of those have been removed.
  - This PR removes a usage of `windows_modules!` (since `cargo shear` and
  `rustfmt` couldn't see through it) in favor of simple `#[cfg(target_os =
  "windows")]` macros. As a consequence, many of these files exhibit churn
  in this PR, since they weren't being formatted by `rustfmt` at all on
  main.
  - Again, to make the code more analyzable, this PR also removes some
  usages of `#[path = "cwd_junction.rs"]` in favor of a more standard
  module structure. The bin sidecar structure is still retained, but,
  e.g., `windows-sandbox-rs/src/bin/command_runner.rs‎` was moved to
  `windows-sandbox-rs/src/bin/command_runner/main.rs`, and so on.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charlie Marsh · 2026-05-08 20:29:00 +00:00
  7c9731c9af
• [codex] Remove legacy after tool use hooks (#21805)

  ## Why
  
  The legacy `AfterToolUse` hook path was still wired through core tool
  dispatch even though the hooks registry never populated any handlers for
  it. The supported hook surface is `PostToolUse`, so the old
  infrastructure was dead code on the hot path.
  
  ## What changed
  
  - Removed the legacy `AfterToolUse` dispatch from `codex-core` tool
  execution.
  - Removed the unused legacy hook payload types and exports from
  `codex-hooks`.
  - Simplified legacy notify handling now that `HookEvent` only carries
  `AfterAgent`.
  
  ## Validation
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-core registry`

  pakrym-oai · 2026-05-08 13:20:05 -07:00
  46e2250bcf
• [codex] Delete function-style apply_patch (#21651)

  ## Why
  
  `apply_patch` is now a freeform/custom tool. Keeping the old
  JSON/function-style registration and parsing path left another way for
  models and tests to invoke `apply_patch`, which made the tool surface
  harder to reason about.
  
  ## What changed
  
  - Removed the `ApplyPatchToolType::Function` variant, JSON `apply_patch`
  spec, and handler support for function payloads.
  - Kept `apply_patch_tool_type = freeform` as the supported model
  metadata path, including Bedrock catalog metadata.
  - Migrated `apply_patch` tests and SSE fixtures to custom/freeform tool
  calls.
  
  ## Verification
  
  - `cargo test -p codex-tools -p codex-protocol -p codex-model-provider`
  - `cargo test -p codex-core tools::handlers::apply_patch --lib`
  - `cargo test -p codex-core --test all
  apply_patch_tool_executes_and_emits_patch_events`
  - `cargo test -p codex-core --test all
  apply_patch_reports_parse_diagnostics`
  - `cargo test -p codex-exec test_apply_patch_tool`
  - `just fix -p codex-core`
  - `just fix -p codex-tools -p codex-protocol -p codex-model-provider -p
  codex-exec`

  pakrym-oai · 2026-05-08 13:00:57 -07:00
  e783341b70
• [codex] request desktop attestation from app (#20619)

  ## Summary
  
  TL;DR: teaches `codex-rs` / app-server to request a desktop-provided
  attestation token and attach it as `x-oai-attestation` on the scoped
  ChatGPT Codex request paths.
  
  ![DeviceCheck attestation
  interface](https://raw.githubusercontent.com/openai/codex/dev/jm/devicecheck-diagram-assets/pr-assets/devicecheck-attestation-interface.png)
  
  ## Details
  
  This PR teaches the Codex app-server runtime how to request and attach
  an attestation token. It does not generate DeviceCheck tokens directly;
  instead, it relies on the connected desktop app to advertise that it can
  generate attestation and then asks that app for a fresh header value
  when needed.
  
  The flow is:
  
  1. The Codex desktop app connects to app-server.
  2. During `initialize`, the app can advertise that it supports
  `requestAttestation`.
  3. Before app-server calls selected ChatGPT Codex endpoints, it sends
  the internal server request `attestation/generate` to the app.
  4. app-server receives a pre-encoded header value back.
  5. app-server forwards that value as `x-oai-attestation` on the scoped
  outbound requests.
  
  The code in this repo is mostly protocol and runtime plumbing: it adds
  the app-server request/response shape, introduces an attestation
  provider in core, wires that provider into Responses / compaction /
  realtime setup paths, and covers the intended scoping with tests. The
  signed macOS DeviceCheck generation remains owned by the desktop app PR.
  
  ## Related PR
  
  - Codex desktop app implementation:
  https://github.com/openai/openai/pull/878649
  
  ## Validation
  
  <details>
  <summary>Tests run</summary>
  
  ```sh
  cargo test -p codex-app-server-protocol
  cargo test -p codex-core attestation --lib
  cargo test -p codex-app-server --lib attestation
  ```
  
  Also ran:
  
  ```sh
  just fix -p codex-core
  just fix -p codex-app-server
  just fix -p codex-app-server-protocol
  just fmt
  just write-app-server-schema
  ```
  
  </details>
  
  <details>
  <summary>E2E DeviceCheck validation</summary>
  
  First validated the signed desktop app boundary directly: launched a
  packaged signed `Codex.app`, sent `attestation/generate`, decoded the
  returned `v1.` attestation header, and validated the extracted
  DeviceCheck token with `personal/jm/verify_devicecheck_token.py` using
  bundle ID `com.openai.codex`. Apple returned `status_code: 200` and
  `is_ok: true`.
  
  Then ran the fuller app + app-server flow. The packaged `Codex.app`
  launched a current-branch app-server via `CODEX_CLI_PATH`, and a local
  MITM proxy intercepted outbound `chatgpt.com` traffic. The app-server
  requested `attestation/generate` from the real Electron app process, and
  the intercepted `/backend-api/codex/responses` traffic included
  `x-oai-attestation` on both routes:
  
  ```text
  GET  /backend-api/codex/responses  Upgrade: websocket  x-oai-attestation: present
  POST /backend-api/codex/responses  Upgrade: none       x-oai-attestation: present
  ```
  
  The captured header decoded to a DeviceCheck token that also validated
  with Apple for `com.openai.codex` (`status_code: 200`, `is_ok: true`,
  team `2DC432GLL2`).
  
  </details>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Jiaming Zhang · 2026-05-08 12:36:02 -07:00
  5f4d0ec343
• Remove ToolName display helper (#21465)

  ## Why
  
  `ToolName::display()` made it too easy to flatten tool identity and
  accidentally compare rendered strings. Tool identity should stay
  structural until a legacy string boundary actually requires the
  flattened spelling.
  
  ## What
  
  - Removes `ToolName::display()` and relies on the existing `Display`
  impl for messages and errors.
  - Adds structural ordering for `ToolName` and uses it for
  sorting/deduping deferred tools.
  - Carries `ToolName` through tool/sandbox plumbing, flattening only at
  legacy boundaries such as hook payloads, telemetry tags, and Responses
  tool names.
  - Updates MCP normalization tests to assert `ToolName` structure instead
  of rendered strings.
  
  ## Testing
  
  - `cargo test -p codex-mcp test_normalize_tools`
  - `cargo test -p codex-core unavailable_tool`
  - `just fix -p codex-protocol`
  - `just fix -p codex-mcp`
  - `just fix -p codex-core`

  pakrym-oai · 2026-05-08 12:17:48 -07:00
  61142b6169
• Load configured environments from CODEX_HOME (#20667)

  ## Why
  
  The earlier PRs add stdio transport support and the config-backed
  environment provider, but the feature remains inert until normal Codex
  entrypoints construct `EnvironmentManager` with enough context to
  discover `CODEX_HOME/environments.toml`. This final stack PR activates
  the provider while preserving the legacy `CODEX_EXEC_SERVER_URL`
  fallback when no environments file exists.
  
  **Stack position:** this is PR 5 of 5. It is the product wiring PR that
  activates the configured environment provider added in PR 4.
  
  ## What Changed
  
  - Thread `codex_home` into `EnvironmentManagerArgs`.
  - Change `EnvironmentManager::new(...)` to load the provider from
  `CODEX_HOME`.
  - Preserve legacy behavior by falling back to
  `DefaultEnvironmentProvider::from_env()` when `environments.toml` is
  absent.
  - Make `environments.toml`-backed managers start new threads with all
  configured environments, default first, while keeping the legacy env-var
  path single-default.
  - Update the app-server, TUI, exec, MCP server, connector, prompt-debug,
  and thread-manager-sample callsites to pass `codex_home` and handle
  provider-loading errors.
  
  ## Self-Review Notes
  
  - The multi-environment startup path is intentionally tied to the
  `environments.toml` provider. Using `>1` configured environment as the
  only signal would also expand the legacy `CODEX_EXEC_SERVER_URL`
  provider because it keeps `local` addressable alongside `remote`.
  - The startup environment list is still derived inside
  `EnvironmentManager`; the provider only says whether its snapshot should
  start new threads with all configured environments.
  - The thread-manager sample was updated to pass the current
  `ThreadManager::new(...)` installation id argument so the stack compiles
  under Bazel.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - 4. https://github.com/openai/codex/pull/20666 - Add CODEX_HOME
  environments TOML provider
  - **5. This PR:** https://github.com/openai/codex/pull/20667 - Load
  configured environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `bazel build --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/thread-manager-sample:codex-thread-manager-sample`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/exec-server:exec-server-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=default_thread_environment_selections_use_manager_default_id
  //codex-rs/core:core-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=start_thread_uses_all_default_environments_from_codex_home
  //codex-rs/core:core-unit-tests`
  
  ## Documentation
  
  This activates `CODEX_HOME/environments.toml`; user-facing documentation
  should be added before this stack is treated as a documented public
  workflow.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 11:17:56 -07:00
  5f2543b74e
• [codex] Generalize service tier slash commands (#21745)

  ## Why
  
  `/fast` was wired as a one-off slash command even though model metadata
  now exposes service tiers as catalog data. That meant adding another
  tier, such as a slower/cheaper tier, would require more hardcoded TUI
  plumbing instead of letting the model catalog drive the available
  commands.
  
  This change makes service-tier commands data-driven: each advertised
  `service_tiers` entry becomes a `/name` command using the catalog
  description, while the request path sends the tier `id` only when the
  selected model supports it.
  
  ## What Changed
  
  - Removed the hardcoded `/fast` slash-command variant and introduced
  dynamic service-tier command items in the composer and command popup.
  - Added toggle behavior for service-tier commands: invoking `/name`
  selects that tier, and invoking it again clears the selection.
  - Preserved the existing Fast-mode keybinding/status affordances by
  resolving the current model tier whose name is `fast`, while still
  sending the tier request value such as `priority`.
  - Persisted service-tier selections as raw request strings so non-fast
  tiers can round-trip through config.
  - Updated the Bedrock catalog entry to advertise fast support through
  `service_tiers` with `id: "priority"` and `name: "fast"`.
  - Added defensive filtering in core so unsupported selected service
  tiers are omitted from `/responses` requests.
  
  ## Validation
  
  - Added/updated coverage for dynamic service-tier slash command lookup,
  popup descriptions, composer dispatch, TUI fast toggling, and
  unsupported-tier omission in core request construction.
  - Local tests were not run per request.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 20:09:51 +03:00
  7c0e54bf59
• api: send hyphenated session and thread headers (#21757)

  ## Why
  Some consumers expect conventional hyphenated HTTP headers. Codex
  already sends the session and thread IDs on outbound Responses requests,
  but it only uses the underscore spellings today, which makes those IDs
  harder to consume in systems that normalize or reject underscore header
  names.
  
  Full context here:
  https://openai.slack.com/archives/C08KCGLSPSQ/p1778248578422369
  
  ## What changed
  - `build_session_headers` now emits both `session_id` and `session-id`
  when a session ID is present.
  - It does the same for `thread_id` and `thread-id`.
  - Added regression coverage in `codex-api/tests/clients.rs` and
  `core/tests/suite/client.rs` so both the lower-level client tests and
  the end-to-end request tests assert the two header spellings are
  present.
  
  ## Test plan
  - Added header assertions in `codex-api/tests/clients.rs`.
  - Added request-header assertions in `core/tests/suite/client.rs` for
  both the `/v1/responses` and `/api/codex/responses` request paths.

  jif-oai · 2026-05-08 17:11:19 +02:00
  bd8fc9adb9
• Update models.json (#19896)

  Automated update of models.json.
  
  ---------
  
  Co-authored-by: aibrahim-oai <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>

  github-actions[bot] · 2026-05-08 17:41:55 +03:00
  aadcae9f3c
• [codex] Enable apply_patch freeform by default (#21687)

  ## Summary
  - enable `apply_patch_freeform` by default in the feature registry
  
  ## Why
  - make the freeform `apply_patch` tool available by default when model
  metadata does not explicitly opt into another mode
  
  ## Validation
  - `just fmt`
  - did not run tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 13:15:00 +00:00
  cce059467a
• Allow string service tiers in config TOML (#21697)

  ## Why
  
  `service_tier` in `config.toml` and profile config was still modeled as
  an enum, which blocked newer or experimental service tier IDs even
  though the runtime paths already carry string IDs.
  
  This change makes the TOML-facing config accept string service tier IDs
  directly while keeping the legacy `fast` alias behavior by normalizing
  it to the request value `priority`.
  
  ## What Changed
  
  - change the TOML-facing `service_tier` fields in global and profile
  config to `Option<String>`
  - keep config-load normalization so legacy `fast` still resolves to
  `priority`
  - persist resolved service tier strings directly in config locks so
  arbitrary IDs round-trip cleanly
  - regenerate the config schema and add config coverage for arbitrary
  string IDs plus legacy `fast` normalization
  
  ## Verification
  
  - added config tests for arbitrary string service tiers and legacy
  `fast` normalization
  - ran `just write-config-schema`
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 15:15:00 +03:00
  317213fd33
• Omit service_tier from remote /responses/compact requests under API auth (#21676)

  ## Summary
  
  API-key-auth remote compaction requests should not inherit
  `service_tier` from normal `/responses` turns. This path needs to match
  API auth expectations, while ChatGPT-auth remote compaction should keep
  reusing the shared request fields that still apply there.
  
  This change keeps the decision inline in
  `codex-rs/core/src/compact_remote.rs` only. Under API key auth, the
  classic remote `/responses/compact` path now omits `service_tier`; under
  ChatGPT auth, it keeps reusing the configured tier.
  `codex-rs/core/src/compact_remote_v2.rs` is unchanged. The remote
  compaction parity coverage and snapshots were updated to assert the
  API-key omission and preserve the ChatGPT-auth behavior.
  
  ## Testing
  
  - Updated remote compaction parity coverage in
  `codex-rs/core/tests/suite/compact_remote.rs` and the corresponding
  snapshots.

  Ahmed Ibrahim · 2026-05-08 11:15:14 +03:00
  71d80f9a14
• [codex-analytics] plumb protocol-native review timing (#21434)

  ## Why
  
  We want terminal tool review analytics, but the reducer should not stamp
  review timing from its own wall clock.
  
  This PR plumbs review timing through the real protocol and app-server
  seams so downstream analytics can consume the emitter's timestamps
  directly. Guardian reviews keep their enriched `started_at` /
  `completed_at` analytics fields by deriving those legacy second-based
  values from the same protocol-native millisecond lifecycle timestamps,
  rather than sampling a separate analytics clock.
  
  ## What changed
  
  - add `started_at_ms` to user approval request payloads
  - add `started_at_ms` / `completed_at_ms` to guardian review
  notifications
  - preserve Guardian review `started_at` / `completed_at` enrichment from
  the protocol-native timing source
  - stamp typed `ServerResponse` analytics facts with app-server-observed
  `completed_at_ms`
  - thread the new timing fields through core, protocol, app-server, TUI,
  and analytics fixtures
  
  ## Verification
  
  - `cargo test -p codex-app-server outgoing_message --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-app-server-protocol guardian --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-tui guardian --manifest-path codex-rs/Cargo.toml`
  - `cargo test -p codex-analytics analytics_client_tests --manifest-path
  codex-rs/Cargo.toml`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21434).
  * #18748
  * __->__ #21434
  * #18747
  * #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-07 20:31:41 -07:00
  99016ec732
• Send response.processed after remote compaction v2 (#21642)

  ## Why
  
  Remote compaction v2 consumes a normal Responses stream, but that
  compaction-specific stream consumer dropped the `response.completed` id.
  As a result, the `responses_websocket_response_processed` lifecycle
  notification was emitted for normal turn sampling but not after a v2
  remote compaction response was fully processed.
  
  ## What changed
  
  - Return the completed response id alongside the v2 `context_compaction`
  output item.
  - After v2 compacted history is installed, send `response.processed`
  through the same websocket session when the feature is enabled.
  - Add websocket regression coverage for a remote compaction v2 request
  followed by `response.processed`.
  
  ## Verification
  
  - `cargo test -p codex-core --test all
  responses_websocket_sends_response_processed_after_remote_compaction_v2
  -- --nocapture`
  - `cargo test -p codex-core
  collect_context_compaction_output_accepts_additional_output_items --
  --nocapture`

  pakrym-oai · 2026-05-07 19:57:36 -07:00
  dfa1e864a2
• Add CODEX_HOME environments TOML provider (#20666)

  ## Why
  
  After stdio transports and provider-owned defaults exist, Codex needs a
  config-backed provider that can describe more than the single legacy
  `CODEX_EXEC_SERVER_URL` remote. This PR adds that provider without
  activating it in product entrypoints yet, keeping parser/validation
  review separate from runtime wiring.
  
  **Stack position:** this is PR 4 of 5. It builds on PR 3's
  provider/default model and adds the `environments.toml` provider used by
  PR 5.
  
  ## What Changed
  
  - Add `environment_toml.rs` as the TOML-specific home for parsing,
  validation, and provider construction.
  - Keep the TOML schema/provider structs private; the public constructor
  added here is `EnvironmentManager::from_codex_home(...)`.
  - Add `TomlEnvironmentProvider`, including validation for:
    - reserved ids such as `local` and `none`
    - duplicate ids
    - unknown explicit defaults
    - empty programs or URLs
    - exactly one of `url` or `program` per configured environment
  - Support websocket environments with `url = "ws://..."` / `wss://...`.
  - Support stdio-command environments with `program = "..."`.
  - Add helpers to load `environments.toml` from `CODEX_HOME`, but do not
  wire entrypoints to call them yet.
  - Add the `toml` dependency for parsing.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - **4. This PR:** https://github.com/openai/codex/pull/20666 - Add
  CODEX_HOME environments TOML provider
  - 5. https://github.com/openai/codex/pull/20667 - Load configured
  environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  Not run locally; this was split out of the original draft stack.
  
  ## Documentation
  
  This introduces the config shape for `environments.toml`; user-facing
  documentation should be added before this stack is treated as a
  documented public workflow.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 01:37:47 +00:00
  07b695190f
• Route view_image through selected environments

  Route view_image through selected environments so image reads use the selected turn environment and cwd, with schema exposure limited to multi-environment toolsets.\n\nCo-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 01:29:03 +00:00
  1bfc3d9773
• [codex] Remove remote thread store implementation (#21596)

  Remove the remote thread-store backend and checked-in protobuf
  artifacts. We've moved these into another crate that link against this
  one.
  
  Also remove the config settings for thread store backend selection,
  since we'll instead pass an instantiated thread store into the core-api
  crate's main entrypoint.

  Tom · 2026-05-08 00:02:46 +00:00
  79ad209ce6
• codex-otel: add configurable trace metadata (#21556)

  Add Codex config for static trace span attributes and structured W3C
  tracestate field upserts. The config flows through OtelSettings so
  callers can attach trace metadata without touching every span call site.
  
  Apply span attributes with an SDK span processor so every exported
  trace span carries the configured metadata. Model tracestate as nested
  member fields so configured keys can be upserted while unrelated
  propagated state in the same member is preserved.
  
  Validate configured tracestate before installing provider-global state,
  including header-unsafe values the SDK does not reject by itself. This
  keeps Codex from propagating malformed trace context from config.
  
  Update the config schema, public docs, and OTLP loopback coverage for
  config parsing, span export, propagation, and invalid-header rejection.

  bbrown-oai · 2026-05-07 16:06:57 -07:00
  31b233c7c6
• Disable empty Cargo test targets (#21584)

  ## Summary
  
  `cargo test` has entails both running standard Rust tests and doctests.
  It turns out that the doctest discovery is fairly slow, and it's a cost
  you pay even for crates that don't include any doctests.
  
  This PR disables doctests with `doctest = false` for crates that lack
  any doctests.
  
  For the collection of crates below, this speeds up test execution by
  >4x.
  
  E.g., before this PR:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):      1.849 s ±  4.455 s    [User: 0.752 s, System: 1.367 s]
    Range (min … max):    0.418 s … 14.529 s    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):     428.6 ms ±   6.9 ms    [User: 187.7 ms, System: 219.7 ms]
    Range (min … max):   418.0 ms … 436.8 ms    10 runs
  ```
  
  For a single crate, with >2x speedup, before:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     491.1 ms ±   9.0 ms    [User: 229.8 ms, System: 234.9 ms]
    Range (min … max):   480.9 ms … 512.0 ms    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     213.9 ms ±   4.3 ms    [User: 112.8 ms, System: 84.0 ms]
    Range (min … max):   206.8 ms … 221.0 ms    13 runs
  ```
  
  Co-authored-by: Codex <noreply@openai.com>

  Charlie Marsh · 2026-05-07 15:44:17 -07:00
  54ef99a365
• Route ThreadManager rollout path reads through thread store (#21265)

  - Route ThreadManager rollout-path resume/fork through ThreadStore
  history reads.
  - Add in-memory store coverage proving path-addressed reads are used.
  
  This isn't strictly necessary for the ThreadStore migration, since these
  ThreadManager methods _only_ work for path-based lookups, but I'm trying
  to migrate all the rollout recorder callsites to use the threadstore
  were possible for consistency.

  Tom · 2026-05-07 11:25:25 -07:00
  4242bba2eb
• Move thread name edits to ThreadStore (#21264)

  - Route live thread renames through `ThreadStore` metadata updates.
  - Read resumed thread names from store metadata with legacy local
  fallback preserved in the store.

  Tom · 2026-05-07 11:12:22 -07:00
  56823ec46b
• [codex] Move tool specs onto handlers (#21461)

  ## Why
  
  This is the next stacked step after deleting the tool-handler kind
  indirection. Specs should come from the registered handlers themselves
  so registry construction has a single source of truth for handler
  behavior and exposed tool definitions.
  
  ## What changed
  
  - Added `ToolHandler::spec()` plus handler-provided parallel/code-mode
  metadata, and made `ToolRegistryBuilder::register_handler` automatically
  collect specs from registered handlers.
  - Moved builtin tool spec construction into the corresponding handlers
  and their adjacent `_spec` modules, including shell, unified exec, apply
  patch, view image, request plugin install, tool search, MCP resource,
  goals, planning, permissions, agent jobs, and multi-agent tools.
  - Reworked configurable handlers to receive their tool-building options
  through constructors, with non-optional handler options where the
  handler is always spec-backed. Shell fallback handlers keep an explicit
  no-spec mode because they are also registered as hidden dispatch
  aliases.
  - Kept `CodeModeExecuteHandler` on the explicit configured wrapper so
  the code-mode exec spec can still be built from the nested registry.
  
  ## Verification
  
  - `cargo check -p codex-core`
  - `cargo test -p codex-core tools::spec_plan::tests`
  - `cargo test -p codex-core tools::spec::tests`
  - `cargo test -p codex-core tools::handlers::multi_agents_spec::tests`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core
  tools::handlers::multi_agents::tests`
  - `cargo test -p codex-core tools::handlers::apply_patch::tests`
  - `cargo test -p codex-core tools::handlers::unified_exec::tests`
  - `just fix -p codex-core`
  - `git diff --check`

  pakrym-oai · 2026-05-07 10:48:36 -07:00
  566f2cb612
• app-server: refresh live threads from latest config snapshot (#21187)

  ## Why
  
  App-server config writes were leaving existing threads partially stale.
  After a config mutation, the app-server told each live thread to run
  `Op::ReloadUserConfig`, but that path only re-read the user
  `config.toml` layer. Settings that came from the app-server's
  materialized config snapshot did not propagate to existing threads until
  restart.
  
  This change prevent a FS access from `core` for CCA.
  
  ## What changed
  
  - add `CodexThread::refresh_runtime_config()` and
  `Session::refresh_runtime_config()` so the app-server can push a freshly
  rebuilt config snapshot into a live thread
  - rebuild the latest config with each thread's `cwd` after config
  mutations, then refresh the thread from that snapshot instead of asking
  it to reload only `config.toml`
  - keep session-static settings unchanged during refresh, while updating
  runtime-refreshable state such as the config layer stack,
  `tool_suggest`, and derived hook/plugin/skill state
  - keep `reload_user_config_layer()` as the file-backed fallback for
  legacy local reload flows, but route the shared refresh logic through
  the new runtime refresh path
  
  ## Testing
  
  - add a session test that verifies `refresh_runtime_config()` rebuilds
  hooks from refreshed config
  - add a session test that verifies runtime-refreshable fields update
  while session-static settings like `model` and `notify` stay unchanged
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-07 19:22:04 +02:00
  eb0462f2af
• [codex] Remove string-keyed MCP tool maps (#21454)

  ## Summary
  
  This PR removes the synthetic `HashMap<String, ToolInfo>` keys from MCP
  tool discovery. `McpConnectionManager::list_all_tools()` now returns
  normalized `Vec<ToolInfo>`, and downstream code derives identity from
  `ToolInfo::canonical_tool_name()`.
  
  The motivation is to keep model-visible tool identity on
  `ToolName`/`ToolInfo` instead of parallel string map keys, so future
  namespace changes do not have to preserve otherwise-unused lookup keys.
  
  ## Changes
  
  - Rename the MCP normalization path from `qualify_tools` to
  `normalize_tools_for_model` and return tool values directly.
  - Flow MCP tool lists through connectors, plugin injection, router/spec
  building, code mode, and tool search as vectors/slices.
  - Keep direct/deferred subtraction local to `mcp_tool_exposure`, using
  `ToolName` values.
  - Update tests to compare `ToolName` instances where MCP identity
  matters.
  
  ## Validation
  
  - `cargo test -p codex-mcp test_normalize_tools`
  - `cargo test -p codex-core mcp_tool_exposure`
  - `cargo test -p codex-core
  direct_mcp_tools_register_namespaced_handlers`
  - `cargo test -p codex-core
  search_tool_registers_namespaced_mcp_tool_aliases`
  - `just fix -p codex-mcp`
  - `just fix -p codex-core`

  pakrym-oai · 2026-05-07 10:16:10 -07:00
  857e731478
• fix: preserve exact turn diffs after partial apply_patch failures (#21518)

  ## Why
  
  Follow-up to #21180: turn diffs are operation-backed now, but a failed
  `apply_patch` can still leave exact filesystem mutations behind. For
  example, a move can write the destination file before failing to remove
  the source. Treating the whole call as unknowable then drops a change
  that Codex actually knows happened, so the emitted turn diff can drift
  from the workspace.
  
  ## What changed
  
  -
  [`apply-patch`](https://github.com/openai/codex/blob/f55724e0276a9b3213170daf2701ccfa0ce22646/codex-rs/apply-patch/src/lib.rs#L248-L345)
  now returns `ApplyPatchFailure` with the exact committed prefix
  accumulated before an error. If a write failure may already have mutated
  the target, the delta is marked inexact instead of being reused blindly.
  - Move handling now records the destination write before attempting
  source removal, so a partially failed move can still report the
  destination file that definitely landed
  ([code](https://github.com/openai/codex/blob/f55724e0276a9b3213170daf2701ccfa0ce22646/codex-rs/apply-patch/src/lib.rs#L463-L521)).
  -
  [`ApplyPatchRuntime`](https://github.com/openai/codex/blob/f55724e0276a9b3213170daf2701ccfa0ce22646/codex-rs/core/src/tools/runtimes/apply_patch.rs#L49-L67)
  now accumulates committed deltas across attempts and forwards them even
  when the visible tool result is failed or sandbox-denied ([runtime
  path](https://github.com/openai/codex/blob/f55724e0276a9b3213170daf2701ccfa0ce22646/codex-rs/core/src/tools/runtimes/apply_patch.rs#L223-L250),
  [event
  path](https://github.com/openai/codex/blob/f55724e0276a9b3213170daf2701ccfa0ce22646/codex-rs/core/src/tools/events.rs#L215-L225)).
  - `TurnDiffTracker` now consumes committed exact deltas rather than only
  fully successful patches; exact-empty failures leave the aggregate
  unchanged, while inexact deltas still invalidate it.
  
  ## Verification
  
  - Added a regression test covering a failed move that still emits the
  committed destination diff:
  [`apply_patch_failed_move_preserves_committed_destination_diff`](https://github.com/openai/codex/blob/f55724e0276a9b3213170daf2701ccfa0ce22646/codex-rs/core/tests/suite/apply_patch_cli.rs#L1517-L1586).
  - Kept explicit coverage that an inexact delta clears the aggregate
  instead of publishing a guessed diff:
  [`apply_patch_clears_aggregated_diff_after_inexact_delta`](https://github.com/openai/codex/blob/f55724e0276a9b3213170daf2701ccfa0ce22646/codex-rs/core/tests/suite/apply_patch_cli.rs#L1589-L1655).
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-07 18:05:45 +02:00
  9b6c6f7a01