187 Commits

• [codex] Remove unused legacy shell tools (#22246)

  ## Why
  
  Recent session history showed no active use of the raw `shell`,
  `local_shell`, or `container.exec` execution surfaces. Keeping those
  handlers/specs wired into core leaves duplicate shell execution paths
  alongside the supported `shell_command` and unified exec tools.
  
  ## What changed
  
  - Removed the raw `shell` handler/spec and its `ShellToolCallParams`
  protocol helper.
  - Removed the legacy `local_shell` and `container.exec` handler/spec
  plumbing while preserving persisted-history compatibility for old
  response items.
  - Normalized model/config `default` and `local` shell selections to
  `shell_command`.
  - Pruned tests that exercised removed raw-shell/local-shell/apply-patch
  variants and kept coverage on `shell_command`, unified exec, and
  freeform `apply_patch`.
  
  ## Verification
  
  - `git diff --check`
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::handlers::shell`
  - `cargo test -p codex-core tools::spec`
  - `cargo test -p codex-core tools::router`
  - `cargo test -p codex-core
  active_call_preserves_triggering_command_context`
  - `cargo test -p codex-core guardian_tests`
  - `cargo test -p codex-core --test all shell_serialization`
  - `cargo test -p codex-core --test all apply_patch_cli`
  - `cargo test -p codex-core --test all shell_command_`
  - `cargo test -p codex-core --test all local_shell`
  - `cargo test -p codex-core --test all otel::`
  - `cargo test -p codex-core --test all hooks::`
  - `just fix -p codex-core`
  - `just fix -p codex-tools`

  pakrym-oai · 2026-05-13 16:43:25 +00:00
  83decfa300
• fix: main (#22503)

  Fix main due to conflicting merge

  jif-oai · 2026-05-13 17:28:37 +02:00
  441c2f818f
• feat: add config-change extension contributor (#22488)

  ## Why
  
  Extensions can observe thread and turn lifecycle events today, but there
  was no single host-owned hook for changes to the effective thread
  configuration. That makes features that need to react to model,
  permission, or tool-suggest updates either depend on individual mutation
  paths or risk going stale after runtime config refreshes.
  
  This adds a typed config-change contributor so extension-owned state can
  stay synchronized with the effective thread config while the host
  remains responsible for deciding when config changed.
  
  ## What Changed
  
  - Added `ConfigContributor<C>` to `codex_extension_api`, with
  before/after immutable snapshots of the effective config plus
  session/thread extension stores.
  - Added registry builder/accessor support through `config_contributor`
  and `config_contributors`.
  - Emits config-change callbacks after committed updates from session
  settings, per-turn setting updates, and `refresh_runtime_config`.
  - Builds effective config snapshots only when config contributors are
  registered, and suppresses no-op callbacks when the before/after
  snapshots are equal.
  - Added a core session regression test that verifies contributors
  observe both model changes and user-layer runtime config changes,
  including access to session and thread extension stores.
  
  ## Validation
  
  Added `config_change_contributor_observes_effective_config_changes` in
  `codex-rs/core/src/session/tests.rs` to cover the new contributor path.

  jif-oai · 2026-05-13 17:13:34 +02:00
  34bb85519f
• Make context contributors async (#22491)

  ## Summary
  - make ContextContributor return a boxed Send future
  - await context contributors during initial context assembly
  - update existing contributors and extension-api examples for the async
  contract
  
  ## Testing
  - cargo test -p codex-extension-api --examples
  - cargo test -p codex-git-attribution
  - cargo test -p codex-core
  build_initial_context_includes_git_attribution_from_extensions --
  --nocapture
  - cargo test -p codex-core
  build_initial_context_omits_git_attribution_when_feature_is_disabled --
  --nocapture
  - cargo test -p codex-core (fails in unrelated
  agent::control::tests::spawn_agent_fork_last_n_turns_keeps_only_recent_turns
  stack overflow)
  - just fix -p codex-extension-api
  - just fix -p codex-git-attribution
  - just fix -p codex-core
  - cargo clippy -p codex-extension-api --examples

  jif-oai · 2026-05-13 16:43:28 +02:00
  68e045a631
• feat: move extension scope ids into ExtensionData (#22490)

  ## Summary
  - add a scoped level_id to ExtensionData and expose it through
  level_id()
  - remove thread_id/turn_id parameters from extension contributor inputs
  where the scoped ExtensionData already carries that identity
  - move turn-scoped extension data onto TurnContext so token usage and
  lifecycle contributors can share the same turn store
  
  ## Testing
  - cargo check -p codex-extension-api -p codex-core --tests
  - cargo test -p codex-extension-api
  - cargo test -p codex-guardian
  - cargo test -p codex-core --lib
  record_token_usage_info_notifies_extension_contributors
  - cargo test -p codex-core --lib
  submission_loop_channel_close_emits_thread_stop_lifecycle
  - cargo test -p codex-core --lib
  submission_loop_channel_close_aborts_active_turn_before_thread_stop_lifecycle
  - just fix -p codex-extension-api
  - just fix -p codex-guardian
  - just fix -p codex-core
  - just fmt
  
  ## Note
  - Attempted cargo test -p codex-core; it aborted in
  agent::control::tests::spawn_agent_fork_last_n_turns_keeps_only_recent_turns
  with the existing stack overflow before the full suite completed.

  jif-oai · 2026-05-13 16:13:16 +02:00
  1dcc89f1d4
• feat: add token usage contributor hook (#22485)

  ## Why
  
  Extensions need a stable place to observe token accounting after Codex
  folds model-provider usage into the session's cached `TokenUsageInfo`.
  Without a contributor hook, extension-owned features that need last-turn
  or cumulative token usage have to duplicate session plumbing or infer
  state from client-facing `TokenCount` notifications.
  
  ## What changed
  
  - Added `TokenUsageContributor` to `codex-extension-api`, passing
  session/thread `ExtensionData`, `ThreadId`, turn id, and the current
  `TokenUsageInfo`.
  - Added registry builder/storage support for token-usage contributors.
  - Invoked registered contributors from
  `Session::record_token_usage_info` after the session token cache is
  updated and before the client `TokenCount` notification is emitted.
  
  ## Testing
  
  - Added `record_token_usage_info_notifies_extension_contributors`,
  covering cumulative token usage updates and access to both extension
  stores.

  jif-oai · 2026-05-13 14:32:23 +02:00
  083c1962f9
• fix: emit thread stop lifecycle on implicit shutdown (#22482)

  ## Why
  
  The thread lifecycle contributor hooks from #22476 should observe every
  session teardown. The explicit `Op::Shutdown` path already emitted
  `on_thread_stop`, but when `submission_loop` exited because its
  submission channel closed, it only tore down runtime services. That
  meant extensions could miss the thread-stop lifecycle signal on implicit
  runtime shutdown.
  
  ## What Changed
  
  - Split shared runtime teardown into `shutdown_runtime_services(...)`.
  - Split thread-stop lifecycle emission into
  `emit_thread_stop_lifecycle(...)`.
  - Reused those helpers from both explicit shutdown and the channel-close
  shutdown path.
  - Tracked whether `Op::Shutdown` was received so the explicit path does
  not double-emit lifecycle events after it exits the loop.
  - Added a regression test that closes the submission channel and asserts
  `ThreadLifecycleContributor::on_thread_stop` runs once with the expected
  thread/session stores.
  
  ## Testing
  
  - `cargo test -p codex-core
  submission_loop_channel_close_emits_thread_stop_lifecycle`

  jif-oai · 2026-05-13 14:19:57 +02:00
  fcc2a92743
• feat: add thread lifecycle contributor hooks (#22476)

  ## Why
  
  Extensions that need thread-scoped state currently only get a start-time
  callback. That is enough for seeding stores, but it leaves the host
  without a shared extension seam for later thread rehydrate and flush
  work as thread ownership evolves. This PR turns that start-only seam
  into a host-owned thread lifecycle contributor contract so
  extension-private state can stay behind the extension API instead of
  leaking extra orchestration through core.
  
  ## What changed
  
  - Replaced `ThreadStartContributor` with `ThreadLifecycleContributor`
  and added typed lifecycle inputs for thread start, resume, and stop. The
  contract lives in
  [`contributors/thread_lifecycle.rs`](https://github.com/openai/codex/blob/d0e9211f70e58d6b07ef07e84f359d1b9aa25955/codex-rs/ext/extension-api/src/contributors/thread_lifecycle.rs#L1-L64).
  - Kept the existing start-time behavior intact by routing session
  construction through `on_thread_start`.
  - Invoked `on_thread_stop` during session shutdown before thread-scoped
  extension state is dropped, while isolating contributor failures behind
  warning logs.
  - Migrated `git-attribution` and `guardian` onto the lifecycle
  registration path.
  - Renamed the extension registry plumbing from start-specific
  contributors to lifecycle-specific contributors.
  
  ## Notes
  
  `on_thread_resume` is introduced at the API boundary here so extensions
  can target the final lifecycle shape; host resume dispatch can be wired
  where that runtime path is finalized.

  jif-oai · 2026-05-13 13:11:30 +02:00
  5ab7e6b4c6
• Refactor extension tools onto shared ToolExecutor (#22369)

  ## Why
  
  Extension tools were split across two public runtime contracts:
  `codex-tool-api` exposed `ToolBundle` plus its own call/spec/error
  types, while core native tools used `codex_tools::ToolExecutor`. That
  made contributed tool specs and execution behavior easy to drift apart
  and added another crate boundary for what should be one executable-tool
  seam.
  
  This PR makes `ToolExecutor` the single runtime contract and keeps
  extension-specific pinning in `codex-extension-api`.
  
  ## Remaining todo
  
  https://github.com/openai/codex/pull/22369/changes#diff-b935ea8245c3ce568a30cff660175fa6390b66b872ae409e1e2e965738250741R5
  Either generic `Invocation` or sub-extract the `ToolCall` and clean
  `ToolInvocation`
  
  ## What changed
  
  - Removed the `codex-tool-api` workspace crate and its dependencies from
  core and `codex-extension-api`.
  - Made `codex_tools::ToolExecutor` object-safe with `async_trait` so
  extension contributors can return a dyn executor.
  - Added the extension-facing aliases under
  `ext/extension-api/src/contributors/tools.rs`, including
  `ExtensionToolExecutor = dyn ToolExecutor<ToolCall, Output =
  ExtensionToolOutput>`.
  - Changed `ToolContributor::tools` to return extension executors
  directly instead of `ToolBundle`s.
  - Updated core’s extension tool handler/registry/router path to adapt
  those extension executors into the existing native `ToolInvocation`
  runtime path.
  - Added focused coverage for extension tools being registered,
  model-visible, dispatchable, and not replacing built-in tools.
  
  ## Verification
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-extension-api`

  jif-oai · 2026-05-13 12:12:06 +02:00
  9c5dfa7b1a
• feat: extract shared tool executor interface (#22359)

  ## Why
  
  Codex still models model-visible tools and executable behavior largely
  inside `codex-core`, which makes it harder to evolve the tool system
  toward a single reusable abstraction for built-ins, MCP-backed tools,
  dynamic tools, and later tools injected from outside core.
  
  This PR takes the next incremental step in that direction by moving the
  common execution-facing pieces out of core and separating them from
  core-only orchestration. The intent is to let shared tool abstractions
  improve in one place, while `codex-core` keeps the parts that are still
  inherently host-specific today, such as `ToolInvocation`, dispatch
  wiring, and hook integration.
  
  This PR is mostly moving things around. The only interesting piece is
  this abstraction:
  https://github.com/openai/codex/pull/22359/changes#diff-81af519002548ba51ed102bdaaf77e081d40a1e73a6e5f9b104bbbc96a6f1b3dR13
  
  ## What changed
  
  - Added `codex_tools::ToolExecutor<Invocation>` as the shared execution
  trait for model-visible tools.
  - Moved the reusable execution support types from `codex-core` into
  `codex-tools`:
    - `FunctionCallError`
    - `ToolPayload`
    - `ToolOutput`
  - Refactored core tool implementations so that execution behavior lives
  on `ToolExecutor<ToolInvocation>`, while `ToolHandler` remains the
  core-local extension point for hook payloads, telemetry tags, diff
  consumers, and other orchestration concerns.
  - Kept the registry and dispatch flow behaviorally unchanged while
  making the shared/extracted boundary explicit across built-in, MCP,
  dynamic, extension-backed, shell, and multi-agent tool handlers.
  
  ## Verification
  
  - `cargo test -p codex-tools`
  - `just fix -p codex-tools`
  - `just fix -p codex-core`
  - `cargo test -p codex-core` progressed through the updated tool
  surfaces and then hit the existing unrelated multi-agent stack overflow
  in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`.

  jif-oai · 2026-05-13 11:31:27 +02:00
  1824685a00
• add --dangerously-bypass-hook-trust CLI flag (#21768)

  # Why
  
  Hook trust happens through the TUI in `/hooks` so it can block
  non-interactive use cases. This flag will allow users that are using
  codex headlessly to bypass hooks when they want to.
  
  # What
  
  This adds one invocation-scoped escape hatch.
  
  - the CLI flag sets a runtime-only `bypass_hook_trust` override; there
  is no durable `config.toml` setting
  - hook discovery still respects normal enablement, so explicitly
  disabled hooks remain disabled
  - we show a `--dangerously-bypass-hook-trust is enabled. Enabled hooks
  may run without review for this invocation.` message on startup so
  accidental use is visible in both interactive and exec flows
  
  This keeps “enabled” and “trusted” as separate concepts in the normal
  path, while giving CI/E2E callers a stable way to opt into the
  exceptional path when they already control the hook set.

  Abhinav · 2026-05-13 07:13:57 +00:00
  392e94e9ea
• Remove unavailable MCP placeholder tool backfill (#22439)

  ## Why
  
  `UnavailableDummyTools` kept synthetic placeholder tools alive for
  historical tool calls whose backing MCP tool was no longer available.
  That path adds stale model-visible tool specs and special routing at the
  point where unavailable MCP calls should use ordinary current-tool
  handling. This removes the runtime backfill instead of preserving a
  second compatibility lane.
  
  ## Is it safe to remove?
  
  The unavailable tools were added in #17853 after a CS issue when a
  previously-called MCP tool failed to load and was omitted from the CS
  spec. Now that we have tool search, I think this is resolved:
  - API merges tools from previous TST output into effective tool set so
  theyre always in CS spec
  - if an MCP tool surfaced by TST later becomes unavailable, the model
  can still call it and it will just return model-visible error
  - both TST output and function call output are dropped on compaction so
  model will not remember old calls to MCP post compaction
  
  ## What changed
  
  - Delete unavailable-tool collection, placeholder handler, router/spec
  plumbing, and obsolete placeholder coverage.
  - Keep `features.unavailable_dummy_tools` as a removed no-op feature
  tombstone so existing configs still parse cleanly.
  - Add an integration-style `tool_search` regression test showing that a
  deferred MCP tool surfaced through `tool_search` still routes through
  MCP and returns a model-visible tool-call error rather than `unsupported
  call`.
  
  ## Verification
  
  - `cargo test -p codex-core tool_search`

  sayan-oai · 2026-05-12 23:30:13 -07:00
  2304ec45ca
• 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
• 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
• 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
• 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
• [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
• 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 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
• [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
• 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
• 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
• 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
• [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
• 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
• [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
• [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
• 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
• [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
• 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
• Make turn diff tracking operation backed (#21180)

  ## Summary
  - replace filesystem-based turn diff tracking with an operation-backed
  accumulator
  - preserve enough verified apply_patch state to render move-overwrite
  cases correctly
  - keep the turn/diff/updated contract intact while removing remote-only
  turn-diff test skips
  
  This takes the assumption that no 3P services rely on the output format
  of `apply_patch`
  
  ## Why
  For the CCA file system isolation push
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-07 11:33:47 +02:00
  f7e8ff8e50
• feat: make built-in MCPs first-class runtime servers (#21356)

  ## DISCLAIMER
  This is experimental and no production service must rely on this
  
  ## Why
  
  Built-in MCPs are product-owned runtime capabilities, but they were
  previously flattened into the same config-backed stdio path as
  user-configured servers. That made them depend on a hidden `codex
  builtin-mcp` re-exec path, exposed them through config-oriented CLI
  flows, and erased distinctions the runtime needs to preserve—most
  notably whether an MCP call should count as external context for
  memory-mode pollution.
  
  ## What changed
  
  - Model product-owned built-ins separately from config-backed MCP
  servers via `BuiltinMcpServer` and `EffectiveMcpServer`.
  - Launch built-ins in process through a reusable async transport instead
  of the hidden `builtin-mcp` stdio subcommand.
  - Keep config-oriented CLI operations such as `codex mcp
  list/get/login/logout` scoped to configured servers, while merging
  built-ins only into the effective runtime server set.
  - Retain server metadata after launch so parallel-tool support and
  context classification come from the live server set; built-in
  `memories` is now classified as local Codex state rather than external
  context.
  
  ## Test plan
  
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-core --test suite
  builtin_memories_mcp_call_does_not_mark_thread_memory_mode_polluted_when_configured`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-07 10:36:32 +02:00
  b2268999fe
• Revert state DB injection and agent graph store (#21481)

  ## Why
  
  Reverts #20689 to restore the previous optional state DB plumbing. The
  conflict resolution keeps the newer installation ID and session/thread
  identity changes that landed after #20689, while removing the mandatory
  state DB and agent graph store dependency from ThreadManager
  construction.
  
  ## What changed
  
  - Restored `Option<StateDbHandle>` through app-server, MCP server,
  prompt debug, and test entry points.
  - Removed the `codex-core` dependency on `codex-agent-graph-store` and
  reverted descendant lookup back to the existing state DB path when
  available.
  - Kept newer `installation_id` forwarding by passing it beside the
  optional DB handle.
  - Kept local thread-name updates working when the optional state DB
  handle is absent.
  
  ## Validation
  
  - `git diff --check`
  - `cargo test -p codex-thread-store`
  - `cargo test -p codex-state -p codex-rollout -p
  codex-app-server-protocol`
  - Attempted `env CARGO_INCREMENTAL=0 cargo test -p codex-core -p
  codex-app-server -p codex-app-server-client -p codex-mcp-server -p
  codex-thread-manager-sample -p codex-tui`; blocked locally by a rustc
  ICE while compiling `v8 v146.4.0` with `rustc 1.93.0 (254b59607
  2026-01-19)` on `aarch64-apple-darwin`.

  pakrym-oai · 2026-05-06 22:48:29 -07:00
  a8488fec5e
• Revert "Move skills watcher to app-server" (#21460)

  Reverts openai/codex#21287

  pakrym-oai · 2026-05-07 02:24:20 +00:00
  103dc2b6ae
• Move skills watcher to app-server (#21287)

  ## Why
  
  Skills update notifications are app-server API behavior, but the watcher
  lived in `codex-core` and surfaced through
  `EventMsg::SkillsUpdateAvailable`. Moving the watcher out keeps core
  focused on thread execution and lets app-server own both cache
  invalidation and the `skills/changed` notification.
  
  ## What changed
  
  - Added an app-server-owned skills watcher that watches local skill
  roots, clears the shared skills cache, and emits `skills/changed`
  directly.
  - Registers skill watches from the common app-server thread listener
  attach path, including direct starts, resumes, and app-server-observed
  child or forked threads.
  - Stores the `WatchRegistration` on `ThreadState`, so listener
  replacement, thread teardown, idle unload, and app-server shutdown
  deregister by dropping the RAII guard.
  - Removed `EventMsg::SkillsUpdateAvailable`, the core watcher, and the
  old core live-reload test.
  - Extended the app-server skills change test to verify a cached skills
  list is refreshed after a filesystem change without forcing reload.
  
  ## Validation
  
  - `cargo check -p codex-core -p codex-app-server -p codex-mcp-server -p
  codex-rollout -p codex-rollout-trace`
  - `cargo test -p codex-app-server
  skills_changed_notification_is_emitted_after_skill_change`

  pakrym-oai · 2026-05-06 15:38:11 -07:00
  d5eea229cc
• Avoid hard-coded environment context shell (#21390)

  ## Summary
  - make resolved turn environment shell metadata optional instead of
  hard-coding bash
  - render environment context shells from explicit environment metadata
  when present, falling back to the existing session shell
  - update environment context tests for inherited PowerShell-style
  fallback and explicit per-environment shell override
  
  ## Testing
  - Not run (not requested; formatted with `just fmt`).
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-06 19:54:26 +00:00
  63a27ad6c6
• Route opted-in MCP elicitations through Guardian (#19431)

  # Motivation
  
  Browser Use origin-access prompts are MCP elicitations, not direct
  tool-call approval prompts, so they were bypassing the Guardian approval
  path. We need a generic opt-in that lets eligible MCP elicitations use
  Guardian when the current turn already routes approvals there.
  
  # Description
  
  Add a generic elicitation reviewer hook in codex-mcp and wire codex-core
  to pass a Guardian reviewer callback when creating the MCP connection
  manager. The reviewer validates explicit mcp_tool_call opt-in metadata,
  builds a Guardian MCP tool-call review request from
  server/tool/connector metadata and tool params, and maps Guardian
  approval, denial, timeout, and cancellation decisions back to MCP
  elicitation responses.
  
  The new option to trigger this in the `_meta` object is:
  ```
  "codex_request_type": "approval_request",
  ```
  
  # Testing
  
  - RUST_MIN_STACK=8388608 NEXTEST_STATUS_LEVEL=leak cargo nextest run
  --no-fail-fast --cargo-profile ci-test --test-threads 2
  - cargo clippy --tests -- -D warnings
  - cargo fmt -- --config imports_granularity=Item --check
  - cargo shear
  - pnpm run format
  - python3 .github/scripts/verify_cargo_workspace_manifests.py
  - python3 .github/scripts/verify_tui_core_boundary.py
  - python3 .github/scripts/verify_bazel_clippy_lints.py
  - git diff --check

  Clark DuVall · 2026-05-06 19:42:45 +00:00
  346070a424
• Remove core MCP list tools op (#21281)

  ## Why
  
  The core `Op::ListMcpTools` request path is no longer needed. Keeping it
  around left a dead request/response surface alongside the app-server MCP
  inventory APIs that own current server status listing.
  
  ## What Changed
  
  - Removed `Op::ListMcpTools`, `EventMsg::McpListToolsResponse`, and the
  core handler that built the MCP snapshot response.
  - Removed the now-unused `codex-mcp` snapshot wrapper/export and passive
  event handling arms in rollout and MCP-server consumers.
  - Updated tests that used the old op as a synchronization hook to wait
  on existing startup/skills events, and deleted the plugin test that only
  exercised the removed listing op.
  
  ## Validation
  
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-rollout -p codex-rollout-trace -p
  codex-mcp-server`
  - `cargo test -p codex-core --test all
  pending_input::queued_inter_agent_mail`
  - `cargo test -p codex-core --test all
  rmcp_client::stdio_mcp_tool_call_includes_sandbox_state_meta`
  - `cargo test -p codex-core --test all
  rmcp_client::stdio_image_responses`
  - `just fix -p codex-core -p codex-protocol -p codex-mcp -p
  codex-rollout -p codex-rollout-trace -p codex-mcp-server`

  pakrym-oai · 2026-05-06 11:20:34 -07:00
  712305be47
• [codex] Add response.processed websocket request (#21284)

  ## Summary
  
  - Add a `response.processed` websocket request payload and sender for
  Responses API websockets.
  - Send `response.processed` from `try_run_sampling_request` after a
  response completes, local turn processing succeeds, and the
  session-owned feature flag is enabled.
  - Add websocket coverage for both enabled and disabled feature-flag
  behavior.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-core response_processed`
  - `cargo test -p codex-api responses_websocket`
  - `cargo test -p codex-features
  responses_websocket_response_processed_is_under_development`
  - `git diff --check`
  - `just fix -p codex-api -p codex-core -p codex-features`
  - `git diff --check origin/main...HEAD`

  pakrym-oai · 2026-05-06 09:58:46 -07:00
  2070d5bfd3
• Move message history out of core (#21278)

  ## Why
  
  Message history was implemented inside `codex-core` and surfaced through
  core protocol ops and `SessionConfiguredEvent` fields even though the
  current consumer is TUI-local prompt recall. That made core own UI
  history persistence and exposed `history_log_id` / `history_entry_count`
  through surfaces that app-server and other clients do not need.
  
  This change moves message history persistence out of core and keeps the
  recall plumbing local to the TUI.
  
  ## What changed
  
  - Added a new `codex-message-history` crate for appending, looking up,
  trimming, and reading metadata from `history.jsonl`.
  - Removed core protocol history ops/events: `AddToHistory`,
  `GetHistoryEntryRequest`, and `GetHistoryEntryResponse`.
  - Removed `history_log_id` and `history_entry_count` from
  `SessionConfiguredEvent` and updated exec/MCP/test fixtures accordingly.
  - Updated the TUI to dispatch local app events for message-history
  append/lookup and keep its persistent-history metadata in TUI session
  state.
  
  ## Validation
  
  - `cargo test -p codex-message-history -p codex-protocol`
  - `cargo test -p codex-exec event_processor_with_json_output`
  - `cargo test -p codex-mcp-server outgoing_message`
  - `cargo test -p codex-tui`
  - `just fix -p codex-message-history -p codex-protocol -p codex-core -p
  codex-tui -p codex-exec -p codex-mcp-server`

  pakrym-oai · 2026-05-06 08:35:42 -07:00
  2004173cd7
• 2- Use string service tiers in session protocol (#20971)

  ## Summary
  - break service tier session/op/app-server protocol fields from the
  closed enum to string tier ids
  - send the service tier string directly through model requests, prewarm,
  compaction, memories, and TUI/app-server turn starts
  - regenerate app-server protocol JSON/TypeScript schemas, removing the
  standalone ServiceTier TS enum
  
  ## Verification
  - just fmt
  - cargo check -p codex-core -p codex-app-server -p codex-tui
  - just write-app-server-schema
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-06 18:00:21 +03:00
  be1d3cff93