3226 Commits

• hooks: use new session IDs instead of thread IDs for hooks, apply parent's session ID to subagents' hooks (#22268)

  ## Why
  
  hook semantics treat `session_id` as shared across a root session and
  its subagents. Codex hooks were still emitting the current thread ID,
  which made spawned agents look like independent sessions and made it
  harder for hook integrations to correlate work across a root thread and
  its spawned helpers
  
  This change makes hooks use Codex's existing shared session identity so
  hook `session_id` matches the root-thread session across spawned
  subagents.
  
  ## What Changed
  
  - switch hook payloads to use the existing shared session identity from
  core instead of the current thread ID
  - cover all hook surfaces that expose `session_id`, including
  `SessionStart`, tool hooks, compact hooks, prompt-submit hooks, stop
  hooks, and legacy after-agent dispatch

  Andrei Eternal · 2026-05-12 19:05:10 -07:00
  fbfbfe5fc5
• feat: route guardian review model selection through providers (#22258)

  ## Why
  
  Guardian review selection was hard-coded in `core`, which worked for the
  default OpenAI path but did not give provider implementations a way to
  choose backend-specific reviewer model IDs. That matters for Amazon
  Bedrock: guardian review should run through the Bedrock/Mantle provider
  using Bedrock's `openai.gpt-5.4` model ID, instead of accidentally
  selecting a reviewer model that implies the OpenAI backend.
  
  ## What Changed
  
  - Added provider-owned approval review model selection via
  `ModelProvider::approval_review_model_selection`.
  - Moved the existing default selection policy into the provider
  abstraction: prefer the requested reviewer model when it is available,
  otherwise fall back to the active turn model, preferring `Low` reasoning
  when supported.
  - Added an Amazon Bedrock override that pins guardian review to
  `openai.gpt-5.4` with `Low` reasoning.

  Celia Chen · 2026-05-13 01:55:46 +00:00
  e2eb7c30fe
• feat: Expose plugin versions and gate plugin sharing (#22397)

  - Adds localVersion to plugin summaries and remoteVersion to share
  context, including generated API schemas.
  - Hydrates local and remote plugin versions from manifests and remote
  release metadata.
  - Adds default-on plugin_sharing gate for shared-with-me listing and
  plugin/share/save, with disabled-path errors
      and focused coverage.

  xl-openai · 2026-05-12 17:56:30 -07:00
  d1430fd61e
• [codex] Remove tool search bucket limit override (#22381)

  ## Why
  
  `tool_search` still carries the server-specific result-cap path added in
  #17684 for `computer-use`: when the model omitted `limit`, a matching
  result expanded the search to 20 and then `limit_results_by_bucket`
  applied per-bucket caps. That makes default result handling depend on a
  one-off server exception instead of the single
  `TOOL_SEARCH_DEFAULT_LIMIT` path.
  
  This PR removes that custom branch so omitted `limit` values use the
  ordinary global default consistently. The implementation being retired
  is the pre-change bucketed search path in
  [`tool_search.rs`](https://github.com/openai/codex/blob/5e3ee5eddfa5333f2e0b011880abf0cbf92bd295/codex-rs/core/src/tools/handlers/tool_search.rs#L121-L190).
  
  ## What changed
  
  - Collapse `ToolSearchHandler::search` back to one BM25 search with the
  resolved limit.
  - Remove `limit_results_by_bucket`, the `computer-use` constants, and
  the omitted-limit plumbing that only existed for the override.
  - Drop dead `ToolSearchEntry::limit_bucket` metadata from deferred MCP
  and dynamic search entries.
  - Remove tests and helpers that only asserted the deleted override
  behavior.
  - Add direct handler-level unit coverage for omitted/default and
  explicit `tool_search` result limits.
  
  ## Validation
  
  - `cargo test -p codex-core tool_search`
  - The matching unit tests passed, including the new omitted/default and
  explicit result-limit coverage.
  - The broader `--test all` search-tool fixture phase then failed before
  sending mocked response requests in
  `tool_search_indexes_only_enabled_non_app_mcp_tools` and
  `tool_search_uses_non_app_mcp_server_instructions_as_namespace_description`.
  - `cargo test -p codex-core`
  - The touched tool-search coverage passed before the run later aborted
  in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`
  with a stack overflow.

  sayan-oai · 2026-05-13 00:46:07 +00:00
  1ae9867296
• Unify thread metadata updates above store (#22236)

  - make ThreadStore::update_thread_metadata accept a broad range of
  metadata patches
  - keep ThreadStore::append_items as raw canonical history append (no
  metadata side effects)
  - in the local store, write these metadata updates to a combination of
  sqlite and rollout jsonl files for backwards-compat. It special cases
  which fields need to go into jsonl vs sqlite vs whatever, confining the
  awkwardness to just this implementation
  - in remote stores we can simply persist the metadata directly to a
  database, no special casing required.
  - move the "implicit metadata updates triggered by appending rollout
  items" from the RolloutRecorder (which is local-threadstore-specific) to
  the LiveThread layer above the ThreadStore, inside of a private helper
  utility called ThreadMetadataSync. LiveThread calls ThreadStore
  append_items and update_metadata separately.
  - Add a generic update metadata method to ThreadManager that works on
  both live threads and "cold" threads
  - Call that ThreadManager method from app server code, so app server
  doesn't need to worry about whether the thread is live or not

  Tom · 2026-05-13 00:28:15 +00:00
  c51c65ad09
• [codex] Add search term coverage for tool_search (#22398)

  ## Why
  
  `tool_search` already had solid end-to-end coverage for discovery and
  follow-up execution, but it did not prove that distinct pieces of
  indexed search text actually work in integration. In particular, we were
  not exercising whether unique tool names, descriptions, namespaces,
  underscore-expanded dynamic names, and schema-property terms were
  sufficient to surface the expected deferred tools.
  
  This change adds focused integration coverage for those term sources so
  regressions in search text construction are caught by a real `TestCodex`
  flow instead of only by lower-level unit tests.
  
  ## What changed
  
  - added a small helper in `core/tests/suite/search_tool.rs` to assert
  that a `tool_search_output` contains an expected namespace child tool
  - added an MCP integration test that issues several `tool_search_call`s
  and verifies distinct query terms match the expected app tools:
    - exact tool name: `calendar_timezone_option_99`
    - tool description phrase: `uploaded document`
    - top-level schema property: `starts_at`
  - added a dynamic-tool integration test that verifies distinct query
  terms match the expected deferred dynamic tool:
    - exact name: `quasar_ping_beacon`
    - underscore-expanded name: `quasar ping beacon`
    - description phrase: `saffron metronome`
    - namespace: `orbit_ops`
    - schema property: `chrono_spec`
  
  ## Validation
  
  - `cargo test -p codex-core tool_search_matches_`
  
  ## Docs
  
  No documentation update needed.

  pakrym-oai · 2026-05-13 00:24:07 +00:00
  f11ad1eacb
• core: box multi-agent handler futures (#22266)

  ## Why
  
  This is the base PR in the split stack for the permissions migration. It
  isolates stack-safety work that had been mixed into the larger
  permissions PR, so reviewers can evaluate the async-future changes
  separately from the permissions model changes in #22267.
  
  The main risk this addresses is large or recursive multi-agent futures
  overflowing smaller runner stacks. A follow-up review also called out
  that `shutdown_live_agent` must remain quiescent: callers should not
  remove a live agent from tracking or release its spawn slot until the
  worker loop has actually terminated.
  
  ## What Changed
  
  - Boxes the large async futures in the multi-agent spawn, resume, and
  close tool handlers.
  - Boxes the `AgentControl` spawn and recursive close/shutdown paths that
  can otherwise build very deep futures.
  - Keeps `shutdown_live_agent` waiting for thread termination before
  removing/releasing the live agent, preserving the previous shutdown
  ordering while still boxing the recursive close path.
  
  ## Verification Strategy
  
  The focused local coverage was `cargo test -p codex-core multi_agents`,
  which exercises the multi-agent spawn/resume/close handlers, cascade
  close/resume behavior, and the shutdown path touched by this PR.
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22266).
  * #22330
  * #22329
  * #22328
  * #22327
  * __->__ #22266

  Michael Bolin · 2026-05-12 17:22:25 -07:00
  9e7cdbd0d2
• Refactor namespaced tool spec registration (#22256)

  ## Summary
  
  This refactor makes tool handlers the owner of the specs they can
  publish, so registry construction can register handlers once and
  separately publish only the specs that should be model-visible.
  
  The main motivation is deferred tools: MCP and dynamic tools still need
  handlers registered up front, but deferred tools should be discoverable
  through `tool_search` rather than emitted in the initial tool spec list.
  
  ## What changed
  
  - `McpHandler` and `DynamicToolHandler` can return their own `ToolSpec`.
  - `build_tool_registry_builder` now collects handlers, registers them
  through the no-spec path, and publishes only non-deferred handler specs.
  - Deferred MCP and dynamic tool names are combined into one
  `all_deferred_tools` set that drives spec filtering, code-mode
  deferred-tool signaling, and `tool_search` registration.
  - `tool_search` registration now requires both deferred tools and
  `namespace_tools`.
  - Namespace specs are merged in `spec_plan`, preserving top-level spec
  order, sorting tools within each namespace, and backfilling empty
  namespace descriptions.
  - Hosted web search and image-generation specs are included in the
  collected spec vector before namespace merge/publication, and tool-name
  tests that should not care about hosted relative order now compare sets.
  
  ## Testing
  
  - `cargo test -p codex-core tools::spec::tests:: -- --nocapture`
  - `cargo test -p codex-core tools::spec_plan::tests:: -- --nocapture`
  - `cargo test -p codex-core
  tools::router::tests::specs_filter_deferred_dynamic_tools --
  --nocapture`
  - `cargo test -p codex-core
  suite::prompt_caching::prompt_tools_are_consistent_across_requests --
  --nocapture`
  - `just fmt`
  - `just fix -p codex-core`
  - `cargo test -p codex-core -- --skip
  tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`
  passed the library suite after skipping the known stack-overflowing unit
  test.
  
  Full `cargo test -p codex-core` currently hits a stack overflow in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`;
  the same focused test reproduces on `origin/main`.

  pakrym-oai · 2026-05-12 17:09:14 -07:00
  0173f71143
• code-mode: carry nested tool kind through runtime (#22377)

  ## Why
  
  Code mode only used nested spec lookup at execution time to rediscover
  whether a nested tool should be invoked as a function tool or a freeform
  tool.
  
  That information is already present in the enabled tool metadata that
  code mode builds to expose `tools.*` and `ALL_TOOLS`, so re-looking it
  up from the router was redundant and kept execution coupled to a
  separate spec lookup path.
  
  ## What Changed
  
  - thread `CodeModeToolKind` through the code-mode runtime `ToolCall`
  event and `CodeModeNestedToolCall`
  - emit the nested tool kind directly from the V8 callback using the
  already-enabled tool metadata
  - build nested tool payloads from the propagated kind instead of calling
  `find_spec`
  - remove the now-unused `find_spec` plumbing from the router and
  parallel runtime helpers
  - add unit coverage for function vs freeform payload shaping and update
  affected router tests
  
  ## Testing
  
  - `cargo test -p codex-code-mode`
  - `cargo test -p codex-core code_mode::tests`
  - `cargo test -p codex-core
  extension_tool_bundles_are_model_visible_and_dispatchable`
  - `cargo test -p codex-core
  model_visible_specs_filter_deferred_dynamic_tools`

  pakrym-oai · 2026-05-12 23:34:37 +00:00
  960d42ddae
• chore(config) include_collaboration_mode_instructions (#22383)

  ## Summary
  Adds include_collaboration_mode_instructions, which is a config
  equivalent to include_permissions_instructions for collaboration modes.
  Desired for situations where we want to disable this instruction from
  entering the context
  
  ## Testing
  - [x] Added unit test

  Dylan Hurd · 2026-05-12 15:50:10 -07:00
  8123bddb16
• tools: remove is_mutating dispatch gating (#22382)

  ## Why
  
  Tool dispatch had two serialization mechanisms:
  
  - `supports_parallel_tool_calls` decides whether a tool participates in
  the shared parallel-execution lock.
  - `is_mutating` separately gated some calls inside dispatch.
  
  That second hook no longer carried its weight. The remaining
  parallel-support flag is already the per-tool concurrency policy, so
  keeping a second mutating gate made dispatch harder to follow and left
  behind extra session plumbing that only existed for that path.
  
  ## What changed
  
  - Removed `is_mutating` from tool handlers and deleted the
  `tool_call_gate` path that existed only to support it.
  - Simplified dispatch and routing to rely on the existing per-tool
  `supports_parallel_tool_calls` boolean.
  - Dropped the now-unused handler overrides and related session/test
  scaffolding.
  - Kept the router/parallel tests focused on the surviving per-tool
  behavior.
  - Removed the unused `codex-utils-readiness` dependency from
  `codex-core` as a follow-up fix for `cargo shear`.
  
  ## Testing
  
  - `cargo test -p codex-core
  parallel_support_does_not_match_namespaced_local_tool_names`
  - `cargo test -p codex-core mcp_parallel_support_uses_handler_data`
  - `cargo test -p codex-core
  tools_without_handlers_do_not_support_parallel`

  pakrym-oai · 2026-05-12 22:44:54 +00:00
  862b2122ee
• [codex] Tighten unified exec sandbox setup (#22207)

  ## Summary
  - tighten unified exec sandbox initialization
  - preserve the requested process workdir independently from sandbox
  setup
  - add regression coverage for the updated invariant
  
  ## Validation
  - Ran `/tmp/cargo-tools/bin/just fmt`.
  - Ran the targeted `codex-core` regression test successfully.
  - Ran `cargo test -p codex-core`; it did not complete cleanly because
  unrelated existing agent/config-loader tests failed and the run later
  aborted on a stack overflow in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`.
  
  Co-authored-by: Codex <noreply@openai.com>

  Chris Bookholt · 2026-05-12 08:41:00 -07:00
  5e3ee5eddf
• feat(tui): add ambient terminal pets (#21206)

  ## Why
  
  The Codex App has animated pets, but the TUI had no equivalent ambient
  companion surface. This brings that experience into terminal Codex while
  keeping the main chat flow usable: the pet should feel present, but it
  cannot cover transcript text, composer input, approvals, or picker
  content.
  
  The feature also needs to be terminal-aware. Different terminals support
  different image protocols, tmux can interfere with image rendering, and
  some users will want pets disabled entirely or anchored differently
  depending on their layout.
  
  <table>
  <tr><td>
  <img width="4110" height="2584" alt="CleanShot 2026-05-05 at 12 41
  45@2x"
  src="https://github.com/user-attachments/assets/68a1fcbc-2104-48d6-b834-69c6aaa95cdf"
  />
  <p align="center">macOS - Ghostty, iTerm2 and WezTerm with Custom
  Pet</p>
  </td></tr>
  <tr><td>
  ![Uploading CleanShot 2026-05-10 at 20.28.30.png…]()
  <p align="center">Windows Terminal</p>
  </td></tr>
  <tr><td>
  <img width="3902" height="2752" alt="CleanShot 2026-05-05 at 12 39
  02@2x"
  src="https://github.com/user-attachments/assets/300e2931-6b00-467e-91cb-ab8e28470500"
  />
  <p align="center">Linux - WezTerm and Ghostty</p>
  </td></tr>
  </table>
  
  ## What Changed
  
  - Add a TUI ambient pet renderer in `codex-rs/tui/src/pets/`.
  - Port the app-style pet animation states so the sprite changes with
  task status, waiting-for-input states, review/ready states, and
  failures.
  - Add `/pets` selection UI with a preview pane, loading state, built-in
  pet choices, and a first-row `Disable terminal pets` option.
  - Download built-in pet spritesheets on demand from the same public CDN
  path already used by Android, under
  `https://persistent.oaistatic.com/codex/pets/v1/...`, and cache them
  locally under `~/.codex/cache/tui-pets/`.
  - Keep custom pets local.
  - Add config support for pet selection, disabling pets, and choosing
  whether the pet follows the composer bottom or anchors to the terminal
  bottom.
  - Reserve layout space around the pet so transcript wrapping, live
  responses, and composer input do not render underneath the sprite.
  - Gate image rendering by terminal capability, disable image pets under
  tmux, and support both Kitty Graphics and SIXEL terminals.
  - Add redraw cleanup for terminal image artifacts, including sixel cell
  clearing.
  
  ## Current Scope
  
  - This is an initial TUI version of ambient pets, not full App parity.
  - It focuses on ambient sprite rendering, `/pets` selection, custom
  pets, terminal capability gating, and on-demand CDN-backed built-in
  assets.
  - The ambient text overlay is currently disabled, so the TUI renders the
  pet sprite without extra status text beside it.
  
  ## How to Test
  
  1. Start Codex TUI in a terminal with image support.
  2. Run `/pets`.
  3. Confirm the picker shows built-in pets plus custom pets, and the
  first item is `Disable terminal pets`.
  4. On a fresh `~/.codex/cache/tui-pets/`, move onto a built-in pet and
  confirm the first preview downloads the spritesheet from the shared
  Codex pets CDN and renders successfully.
  5. Move through the pet list and confirm subsequent built-in previews
  use the local cache.
  6. Select a pet, then send and receive messages. Confirm transcript and
  composer text wrap before the pet instead of rendering underneath the
  sprite.
  7. Change the pet anchor setting and confirm the pet can either follow
  the composer bottom or sit at the terminal bottom.
  8. Return to `/pets`, choose `Disable terminal pets`, and confirm the
  sprite disappears cleanly.
  
  Targeted tests:
  - `cargo test -p codex-tui ambient_pet_`
  - `cargo test -p codex-tui
  resize_reflow_wraps_transcript_early_when_pet_is_enabled`
  - `cargo insta pending-snapshots`

  Felipe Coury · 2026-05-12 10:43:17 -03:00
  95b332c820
• [rollout-trace] Add x-codex-inference-call-id header to inference calls. (#22311)

  This allows us to attach call logs to inference requests in traces.

  cassirer-openai · 2026-05-12 05:55:11 -07:00
  cb55b769d1
• feat: guardian as an extension (contributors part) (#22216)

  Part 1 of guardian as extension. This bind all the logic to spawn
  another agent from an extension and it adds `ThreadId` in the start
  thread collaborator

  jif-oai · 2026-05-12 14:41:45 +02:00
  d996f5366f
• feat(sandbox): add Windows deny-read parity (#18202)

  ## Why
  
  The split filesystem policy stack already supports exact and glob
  `access = none` read restrictions on macOS and Linux. Windows still
  needed subprocess handling for those deny-read policies without claiming
  enforcement from a backend that cannot provide it.
  
  ## Key finding
  
  The unelevated restricted-token backend cannot safely enforce deny-read
  overlays. Its `WRITE_RESTRICTED` token model is authoritative for write
  checks, not read denials, so this PR intentionally fails that backend
  closed when deny-read overrides are present instead of claiming
  unsupported enforcement.
  
  ## What changed
  
  This PR adds the Windows deny-read enforcement layer and makes the
  backend split explicit:
  
  - Resolves Windows deny-read filesystem policy entries into concrete ACL
  targets.
  - Preserves exact missing paths so they can be materialized and denied
  before an enforceable sandboxed process starts.
  - Snapshot-expands existing glob matches into ACL targets for Windows
  subprocess enforcement.
  - Honors `glob_scan_max_depth` when expanding Windows deny-read globs.
  - Plans both the configured lexical path and the canonical target for
  existing paths so reparse-point aliases are covered.
  - Threads deny-read overrides through the elevated/logon-user Windows
  sandbox backend and unified exec.
  - Applies elevated deny-read ACLs synchronously before command launch
  rather than delegating them to the background read-grant helper.
  - Reconciles persistent deny-read ACEs per sandbox principal so policy
  changes do not leave stale deny-read ACLs behind.
  - Fails closed on the unelevated restricted-token backend when deny-read
  overrides are present, because its `WRITE_RESTRICTED` token model is not
  authoritative for read denials.
  
  ## Landed prerequisites
  
  These prerequisite PRs are already on `main`:
  
  1. #15979 `feat(permissions): add glob deny-read policy support`
  2. #18096 `feat(sandbox): add glob deny-read platform enforcement`
  3. #17740 `feat(config): support managed deny-read requirements`
  
  This PR targets `main` directly and contains only the Windows deny-read
  enforcement layer.
  
  ## Implementation notes
  
  - Exact deny-read paths remain enforceable on the elevated path even
  when they do not exist yet: Windows materializes the missing path before
  applying the deny ACE, so the sandboxed command cannot create and read
  it during the same run.
  - Existing exact deny paths are preserved lexically until the ACL
  planner, which then adds the canonical target as a second ACL target
  when needed. That keeps both the configured alias and the resolved
  object covered.
  - Windows ACLs do not consume Codex glob syntax directly, so glob
  deny-read entries are expanded to the concrete matches that exist before
  process launch.
  - Glob traversal deduplicates directory visits within each pattern walk
  to avoid cycles, without collapsing distinct lexical roots that happen
  to resolve to the same target.
  - Persistent deny-read ACL state is keyed by sandbox principal SID, so
  cleanup only removes ACEs owned by the same backend principal.
  - Deny-read ACEs are fail-closed on the elevated path: setup aborts if
  mandatory deny-read ACL application fails.
  - Unelevated restricted-token sessions reject deny-read overrides early
  instead of running with a silently unenforceable read policy.
  
  ## Verification
  
  - `cargo test -p codex-core
  windows_restricted_token_rejects_unreadable_split_carveouts`
  - `just fmt`
  - `just fix -p codex-core`
  - `just fix -p codex-windows-sandbox`
  - GitHub Actions rerun is in progress on the pushed head.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-05-11 23:04:28 -07:00
  46f30d0282
• [codex] Make handlers own parallel tool support (#22254)

  ## Why
  
  `ToolRouter::tool_supports_parallel()` was still consulting configured
  specs when a handler lookup missed, even though parallel schedulability
  is really a property of the executable handler. Keeping that metadata on
  `ConfiguredToolSpec` duplicated state between the model-visible spec
  layer and the runtime handler layer.
  
  This change makes handlers the sole source of truth for parallel tool
  support and removes the extra spec wrapper that only existed to carry
  duplicated metadata.
  
  ## What changed
  
  - removed `ConfiguredToolSpec` and store plain `ToolSpec` values in the
  registry/router builder path
  - changed `ToolRouter::tool_supports_parallel()` to consult only the
  handler registry and fall back to `false`
  - simplified spec collection and test helpers to operate directly on
  `ToolSpec`
  - updated router/spec tests to cover handler-owned parallel behavior and
  the no-handler fallback
  
  ## Validation
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core mcp_parallel_support_uses_handler_data`
  - `cargo test -p codex-core
  deferred_responses_api_tool_serializes_with_defer_loading`
  - `cargo test -p codex-core
  tools_without_handlers_do_not_support_parallel`
  - `cargo test -p codex-core
  request_plugin_install_can_be_registered_without_search_tool`
  
  ## Docs
  
  No documentation updates needed.

  pakrym-oai · 2026-05-11 22:26:33 -07:00
  c9e46ed639
• [codex] Filter legacy warning messages during compaction (#22243)

  ## Why
  
  Older sessions can contain model-warning records persisted as `user`
  messages, including the unified exec process-limit warning, the
  `apply_patch`-via-`exec_command` warning, and the model-mismatch
  high-risk cyber fallback warning. Those warnings are no longer produced
  as conversation history items, but when old sessions compact they should
  still be recognized as injected context rather than preserved as real
  user turns.
  
  ## What changed
  
  - Removed `record_model_warning` and the production paths that emitted
  these warning messages into conversation history.
  - Added `LegacyUnifiedExecProcessLimitWarning`,
  `LegacyApplyPatchExecCommandWarning`, and `LegacyModelMismatchWarning`
  contextual fragments that are used only for matching old persisted
  messages.
  - Registered the legacy fragments with contextual user message detection
  so compaction filters them through the existing fragment path.
  - Added focused compaction coverage for old warning messages being
  dropped during compacted-history processing.
  
  ## Testing
  
  - `cargo test -p codex-core warning`
  - `just fix -p codex-core`

  pakrym-oai · 2026-05-11 19:51:51 -07:00
  79c65f816c
• Support PreToolUse updatedInput rewrites (#20527)

  ## Why
  
  `PreToolUse` already exposes `updatedInput` in its hook output schema,
  but Codex currently rejects it instead of applying the rewrite. That
  leaves hook authors unable to make the documented pre-execution
  adjustment to a tool call before it runs.
  
  ## What
  
  - Accept `updatedInput` from `PreToolUse` hooks when paired with
  `permissionDecision: "allow"`.
  - Apply the rewritten input before dispatch so the tool executes the
  updated payload, not the original one.
  - Preserve the stable hook-facing compatibility shapes that
  participating tool handlers expose:
  - Bash-like tools (`shell`, `container.exec`, `local_shell`,
  `shell_command`, `exec_command`) use `{ "command": ... }`.
  - `apply_patch` exposes its patch body through the same command-shaped
  hook contract.
    - MCP tools expose their JSON argument object directly.
  - Keep each participating tool handler responsible for translating
  hook-facing `updatedInput` back into its concrete invocation shape.
  
  ## Verification
  
  Direct Bash-like rewrite coverage:
  
  - `pre_tool_use_rewrites_shell_before_execution`
  - `pre_tool_use_rewrites_container_exec_before_execution`
  - `pre_tool_use_rewrites_local_shell_before_execution`
  - `pre_tool_use_rewrites_shell_command_before_execution`
  - `pre_tool_use_rewrites_exec_command_before_execution`
  
  These cases assert that each supported Bash-like surface runs only the
  rewritten command while the hook still observes the original `{
  "command": ... }` input.
  
  `pre_tool_use_rewrites_apply_patch_before_execution`
  
  - Model emits one patch.
  - Hook swaps in a different patch.
  - Asserts only the rewritten file is created, and the hook saw the
  original patch.
  
  `pre_tool_use_rewrites_code_mode_nested_exec_command_before_execution`
  
  - Model runs one nested shell command from code mode.
  - Hook rewrites it.
  - Asserts only the rewritten command runs, and the hook saw the original
  nested input.
  
  `pre_tool_use_rewrites_mcp_tool_before_execution`
  
  - Model calls the RMCP echo tool.
  - Hook rewrites the MCP arguments.
  - Asserts the MCP server receives and returns the rewritten message, not
  the original one.

  Abhinav · 2026-05-11 22:27:24 -04:00
  d08906a944
• Apply sandbox context to local view_image reads (#21861)

  ## Summary
  - create a selected-cwd filesystem sandbox context for view_image
  metadata and file reads in both local and remote environments
  - add a local restricted-profile regression test for the previously
  unsandboxed read path
  
  ## Validation
  - just fmt
  - bazel test --bes_backend= --bes_results_url= --test_output=errors
  --test_filter=view_image::tests::handle_passes_sandbox_context_for_local_filesystem_reads
  //codex-rs/core:core-unit-tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-11 18:48:43 -07:00
  17ed5ad0b0
• Simplify MCP tool handler plumbing (#21595)

  ## Why
  The MCP tool path had accumulated a few core-owned special cases: a
  dedicated payload variant, resolver plumbing, a legacy `AfterToolUse`
  translation path, and a side channel for parallel-call metadata. That
  made `ToolRegistry` and the spec builder know more about MCP than they
  needed to.
  
  This change moves MCP-specific execution details back onto `ToolInfo`
  and `McpHandler` so `codex-core` can treat MCP calls like normal
  function calls while still preserving MCP-specific dispatch and
  telemetry behavior where it belongs.
  
  ## What changed
  - removed `resolve_mcp_tool_info`, `ToolPayload::Mcp`, `ToolKind`, and
  the remaining registry-side MCP resolver path
  - stored MCP routing metadata directly on `McpHandler` and `ToolInfo`,
  including `supports_parallel_tool_calls`
  - deleted the legacy `AfterToolUse` consumer in `core`, which removes
  the need for handler-specific `after_tool_use_payload` implementations
  - switched tool-result telemetry to handler-provided tags and kept
  MCP-specific dispatch payload construction inside the handler
  - simplified tool spec planning/building by passing `ToolInfo` directly
  and dropping the direct/deferred MCP wrapper structs and the
  parallel-server side table
  
  ## Testing
  - `cargo check -p codex-core -p codex-mcp -p codex-otel`
  - `cargo test -p codex-core
  mcp_parallel_support_uses_exact_payload_server`
  - `cargo test -p codex-core
  direct_mcp_tools_register_namespaced_handlers`
  - `cargo test -p codex-core
  search_tool_description_lists_each_mcp_source_once`
  - `cargo test -p codex-mcp
  list_all_tools_uses_startup_snapshot_while_client_is_pending`
  - `just fix -p codex-core -p codex-mcp -p codex-otel`

  pakrym-oai · 2026-05-12 00:11:31 +00:00
  ed5944ba1d
• Add production startup and TTFT telemetry (#22198)

  ## Why
  
  While investigating `codex exec hi` startup latency, the useful
  questions were not "is startup slow?" but "which durable bucket is slow
  in production?"
  
  The path we observed has a few distinct stages:
  
  1. `thread/start` creates the session
  2. startup prewarm builds the turn context, tools, and prompt
  3. startup prewarm warms the websocket
  4. the first real turn resolves the prewarm
  5. the model produces the first token
  
  Before this PR, production telemetry had some of the raw measurements
  already:
  
  - aggregate startup-prewarm duration / age-at-first-turn metrics
  - TTFT as a metric
  - websocket request telemetry
  
  But there was no coherent production event stream for the startup
  breakdown itself, and TTFT was metric-only. That made it hard to answer
  the same latency questions from OpenTelemetry-backed logs without adding
  one-off local instrumentation.
  
  ## What changed
  
  Add durable production telemetry on the existing `SessionTelemetry`
  path:
  
  - new `codex.startup_phase` OTel log/trace events plus
  `codex.startup.phase.duration_ms`
  - new `codex.turn_ttft` OTel log/trace events while preserving the
  existing TTFT metric
  
  The startup phase event is emitted for the coarse buckets we actually
  observed while running `exec hi`:
  
  - `thread_start_create_thread`
  - `startup_prewarm_total`
  - `startup_prewarm_create_turn_context`
  - `startup_prewarm_build_tools`
  - `startup_prewarm_build_prompt`
  - `startup_prewarm_websocket_warmup`
  - `startup_prewarm_resolve`
  
  These phases are intentionally low-cardinality so they remain safe as
  production telemetry tags.
  
  ## Why this shape
  
  This keeps the instrumentation on the same production path as the rest
  of the session telemetry instead of adding a local debug-only trace
  mode. It also avoids changing startup behavior:
  
  - prewarm still runs
  - no control flow changes
  - no extra remote calls
  - no user-visible behavior changes
  
  One boundary is intentional: very early process bootstrap that happens
  before a session exists is not included here, because this PR uses
  session-scoped production telemetry. The expensive buckets we were
  trying to understand after `thread/start` are now covered durably.
  
  ## Verification
  
  - `cargo test -p codex-otel`
  - `cargo test -p codex-core turn_timing`
  - `cargo test -p codex-core
  regular_turn_emits_turn_started_without_waiting_for_startup_prewarm`
  - `cargo test -p codex-core
  interrupting_regular_turn_waiting_on_startup_prewarm_emits_turn_aborted`
  - `cargo test -p codex-app-server thread_start`
  - `just fix -p codex-otel -p codex-core -p codex-app-server`
  
  I also ran `cargo test -p codex-core`; it built successfully and then
  hit an existing unrelated stack overflow in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`.

  Matthew Zeng · 2026-05-11 23:58:36 +00:00
  e15ecc9c35
• Support multi-environment apply_patch selection (#21617)

  ## Summary
  - add multi-environment apply_patch routing for both freeform and
  function-call tool flows
  - parse and reconcile the optional environment selector in the main
  apply_patch parser, then verify against the selected environment in the
  handler
  - carry environment_id through runtime and approval surfaces so
  remote-targeted patches stay explicit end to end
  
  ## Testing
  - just fmt
  - remote exec-server e2e: `cargo test -p codex-core --test all
  apply_patch_multi_environment_uses_remote_executor -- --nocapture` on
  dev via `scripts/test-remote-env.sh`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-11 16:33:44 -07:00
  22e84c49d0
• Add Windows hook command overrides (#22159)

  # Why
  
  Managed hook configs need a shared cross-platform shape without making
  the existing `command` field polymorphic. The common case is still one
  command string, with Windows needing a different entrypoint only when
  the runtime is actually Windows.
  
  Keeping `command` as the portable/default path and adding an optional
  Windows override keeps the config easier to read, preserves the existing
  scalar shape for non-Windows users, and avoids forcing every caller into
  a `{ unix, windows }` object when only one platform needs special
  handling.
  
  # What
  
  - Add optional `command_windows` / `commandWindows` alongside the
  existing hook `command` field.
  - Resolve `command_windows` only on Windows during hook discovery; other
  platforms continue to use `command` unchanged.
  - Keep trust hashing aligned to the effective command selected for the
  current runtime.
  
  # Docs
  
  The Codex hooks/config reference should document `command_windows` as
  the Windows-only override for command hooks.

  Abhinav · 2026-05-11 22:22:29 +00:00
  9ab7f4e6ac
• [codex-analytics] emit terminal review events (#18748)

  ## Why
  
  Review telemetry should describe reviews as first-class events, not only
  as counters denormalized onto terminal tool-item events. That lets us
  analyze guardian and user reviews consistently across command execution,
  file changes, permissions, and network access, while still preserving
  the terminal item summaries that existing tool analytics need.
  
  To make those review events accurate, analytics also needs the observed
  completion time for each review and enough command metadata to
  distinguish `shell` from `unified_exec` reviews.
  
  ## What changed
  
  - emit generic `codex_review_event` rows for completed user and guardian
  reviews, with review subjects, reviewer, trigger, terminal status,
  resolution, and observed duration
  - reduce approval request / response / abort facts into review events
  for command execution, file change, and permissions flows
  - keep denormalized review counts, final approval outcome, and
  permission-request flags on terminal tool-item events for
  item-associated reviews
  - plumb review completion timing so user-review responses and aborts use
  app-server-observed completion times, while guardian analytics reuse the
  same terminal timestamps emitted on guardian assessment events
  - carry command approval `source` through the protocol and app-server
  layers so review analytics can distinguish `shell` from `unified_exec`
  - add analytics coverage for user-review emission, guardian-review
  emission, permission reviews that should not denormalize onto tool
  items, item-summary isolation across threads, and the serialized
  review-event shape
  
  ## Verification
  
  - `cargo test -p codex-analytics`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18748).
  * __->__ #18748
  * #21434
  * #18747
  * #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-11 22:13:32 +00:00
  a175ddacc0
• 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