6252 Commits

This Branch

This Branch

All Branches

• 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
• Show plugin hooks in plugin details (#21447)

  Supersedes the abandoned #19859, rebuilt on latest `main`.
  
  # Why
  
  PR #19705 adds discovery for hooks bundled with plugins, but `/plugins`
  still only shows skills, apps, and MCP servers. This follow-up makes
  bundled hooks visible in the same plugin detail view so users can
  inspect the full plugin surface in one place.
  
  We also need `PluginHookSummary` to populate Plugin Hooks in the app;
  `hooks/list` is not enough there because plugin detail needs to show
  hooks for disabled plugins too.
  
  # What
  
  - extend `plugin/read` with `PluginHookSummary` entries for bundled
  hooks
  - summarize plugin hooks while loading plugin details
  - render a `Hooks` row in the `/plugins` detail popup
  
  <img width="3456" height="848" alt="CleanShot 2026-04-27 at 11 45 34@2x"
  src="https://github.com/user-attachments/assets/fe3a38d6-a260-4351-8513-fb04c93d725b"
  />

  Abhinav · 2026-05-07 00:21:14 -07:00
  40e282849c
• [codex] fix PluginListParams test initializer (#21494)

  ## Summary
  - update the app-server protocol test fixture to include the required
  `marketplace_kinds` field on `PluginListParams`
  
  ## Why
  `PluginListParams` now requires `marketplace_kinds`, but a later-added
  test fixture in `common.rs` still constructed the older shape with only
  `cwds`. That stale initializer breaks the main build with `missing field
  marketplace_kinds`.
  
  ## Impact
  This is a test-only repair. It restores compilation without changing the
  JSON-RPC schema or runtime behavior.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`

  xli-oai · 2026-05-06 23:58:26 -07:00
  898f5bfeaa
• 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
• [codex] Parallelize skills list cwd loading (#21441)

  ## Summary
  - process `skills/list` cwd entries with bounded concurrency of 5
  - preserve the caller's requested cwd order in the response
  - add coverage that verifies response ordering remains stable
  
  ## Why
  Cold-start desktop traces showed that `skills/list` can dominate the
  shared config queue when it scans many workspace roots serially. The
  expensive work is largely independent per cwd, so the request was paying
  the sum of all cwd costs instead of the cost of the slowest bounded
  batch.
  
  ## Impact
  This keeps current request semantics intact while reducing the
  wall-clock time of large multi-root `skills/list` calls. That should
  also reduce how long later config-family requests, such as
  `plugin/list`, wait behind `skills/list` during startup.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-app-server
  skills_list_preserves_requested_cwd_order`

  xli-oai · 2026-05-06 21:25:24 -07:00
  5bc33fe31f
• [codex] allow shared config reads in app-server queue (#21340)

  ## Summary
  - add a shared-read serialization mode for global app-server request
  families
  - let consecutive leading shared reads for the same family run together
  while keeping exclusive requests ordered
  - mark only `skills/list`, `config/read` and `plugin/list` as shared
  reads for now
  
  ## Why
  `skills/list` and `plugin/list` are read-only config-family requests,
  but the app-server queue currently treats every config request as
  exclusive. That means one long `skills/list` can make a later
  `plugin/list` wait even though the two requests do not mutate config.
  
  This change keeps the existing queue order but lets adjacent reads
  overlap. If a write is already waiting, later reads still stay behind
  it, so writes do not starve.
  
  ## Scope
  This intentionally keeps the first pass narrow:
  - shared reads: `skills/list`, `plugin/list`
  - still exclusive: `plugin/install`, `marketplace/*`,
  `skills/config/write`, `config/*write`, `config/read`, and the rest of
  the config family
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  
  ## Desktop verification
  I ran the dev desktop app against this branch's built binary with the
  existing UI timing logs enabled. The app did use
  `/Users/xli/code/codex_6/codex-rs/target/debug/codex`.
  
  The new scheduler behavior works, but this narrow change does not remove
  every cold-start delay: in the observed trace, an earlier exclusive
  `config/read` was already queued ahead of the later `skills/list` and
  `plugin/list` requests, so the page-open plugin requests still waited
  behind that earlier exclusive config-family request before they could
  run together.
  
  That means this PR is the scheduler primitive needed for shared reads,
  not the complete end-to-end latency fix by itself.
  
  ## Not run
  - full workspace test suite, because repo policy requires explicit
  approval before running it after touching `app-server-protocol`

  xli-oai · 2026-05-06 21:16:31 -07:00
  05cd5c313e
• [codex] Add OpenAI Developers to tool suggest allowlist (#21423)

  ## Summary
  
  Add `openai-developers@openai-curated` to
  `TOOL_SUGGEST_DISCOVERABLE_PLUGIN_ALLOWLIST` so the OpenAI Developers
  plugin can be surfaced through tool suggestions once it is available in
  the Built by OpenAI marketplace.
  
  Update the discoverable plugin test fixture to assert the plugin is
  returned from the curated marketplace allowlist path.
  
  ## Validation
  
  - `cargo fmt --check` passed; rustfmt emitted the existing
  stable-channel warnings about `imports_granularity`.
  - `cargo test -p codex-core
  list_tool_suggest_discoverable_plugins_returns_uninstalled_curated_plugins`
  passed.

  mifan-oai · 2026-05-06 23:49:15 -04:00
  001363188a
• [codex] Delete tool handler plan indirection (#21427)

  ## Why
  
  The spec split in the parent PR still left an intermediate registry plan
  that recorded `ToolHandlerKind` values and translated them into concrete
  handlers later. That kept tool registration dependent on static enum
  bookkeeping instead of registering handlers from the same code that
  assembles their specs.
  
  ## What Changed
  
  - Make `build_tool_registry_builder` register concrete handlers directly
  while adding specs.
  - Add small `ToolRegistryBuilder` helpers for spec augmentation and
  nested code-mode inspection.
  - Remove `ToolHandlerKind`, `ToolHandlerSpec`, and `ToolRegistryPlan`.
  - Update spec-plan tests to assert against the built `ToolRegistry`
  instead of static handler descriptors.
  
  ## Validation
  
  - `cargo check -p codex-core`
  - `cargo test -p codex-core tools::spec_plan::tests`
  - `cargo test -p codex-core tools::spec::tests`
  - `just fix -p codex-core`

  pakrym-oai · 2026-05-06 20:36:24 -07:00
  e394625ea2
• fix(tui): clear first inline viewport render (#21450)

  ## Why
  
  The alpha TUI can render the initial trust-directory prompt with stale
  terminal text showing through spaces when startup begins below existing
  shell output. The first inline viewport transition can happen while the
  previous viewport is still empty, so the old clear path no-ops before
  Ratatui draws the prompt. Ratatui then skips blank cells because its
  previous buffer also thinks those cells are blank, leaving old terminal
  contents visible inside the prompt.
  
  ## What Changed
  
  - Clear from the new inline viewport top when the previous viewport is
  empty during a viewport transition.
  - Keep the existing clear-from-old-viewport behavior for normal viewport
  updates.
  - Add a VT100-backed regression test that pre-fills terminal contents,
  performs the first viewport clear, and verifies stale text inside the
  new viewport is removed while shell content above the viewport remains.
  
  ## How to Test
  
  1. Start Codex alpha in a terminal that already has visible shell output
  above the cursor.
  2. Use a fresh untrusted project directory so the trust-directory prompt
  appears.
  3. Confirm the prompt text renders cleanly, with spaces staying blank
  instead of showing fragments of previous shell output.
  4. As a regression check, confirm content above the inline viewport is
  still preserved in terminal scrollback.
  
  Targeted tests:
  - `cargo test -p codex-tui
  first_viewport_change_clears_from_new_viewport_when_old_viewport_is_empty
  -- --nocapture`
  - `cargo test -p codex-tui`

  Felipe Coury · 2026-05-07 02:48:49 +00:00
  5a4b2702f2
• Revert "Move skills watcher to app-server" (#21460)

  Reverts openai/codex#21287

  pakrym-oai · 2026-05-07 02:24:20 +00:00
  103dc2b6ae
• Add compact lifecycle hooks (started by vincentkoc - external contrib) (#19905)

  Based on work from Vincent K -
  https://github.com/openai/codex/pull/19060
  
  <img width="1836" height="642" alt="CleanShot 2026-04-29 at 20 47 40@2x"
  src="https://github.com/user-attachments/assets/b647bb89-65fe-40c8-80b0-7a6b7c984634"
  />
  
  ## Why
  
  Compaction rewrites the conversation context that future model turns
  receive, but hooks currently have no deterministic lifecycle point
  around that rewrite. This adds compact lifecycle hooks so users can
  audit manual and automatic compaction, surface hook messages in the UI,
  and run post-compaction follow-up without overloading tool or prompt
  hooks.
  
  ## What Changed
  
  - Added `PreCompact` and `PostCompact` hook events across hook config,
  discovery, dispatch, generated schemas, app-server notifications,
  analytics, and TUI hook rendering.
  - Added trigger matching for compact hooks with the documented `manual`
  and `auto` matcher values.
  - Wired `PreCompact` before both local and remote compaction, and
  `PostCompact` after successful local or remote compaction.
  - Kept compact hook command input to lifecycle metadata: session id,
  Codex turn id, transcript path, cwd, hook event name, model, and
  trigger.
  - Made compact stdout handling consistent with other hooks: plain stdout
  is ignored as debug output, while malformed JSON-looking stdout is
  reported as failed hook output.
  - Added integration coverage for compact hook dispatch, trigger
  matching, post-compact execution, and the audited behavior that
  `decision:"block"` does not block compaction.
  
  ## Out of Scope
  
  - Hook-specific compaction blocking is not implemented;
  `decision:"block"` and exit-code-2 blocking semantics are intentionally
  unsupported for `PreCompact`.
  - Custom compaction instructions are not exposed to compact hooks in
  this PR.
  - Compact summaries, summary character counts, and summary previews are
  not exposed to compact hooks in this PR.
  
  ## Verification
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-core
  manual_pre_compact_block_decision_does_not_block_compaction`
  - `cargo test -p codex-app-server hooks_list`
  - `cargo test -p codex-core config_schema_matches_fixture`
  - `cargo test -p codex-tui hooks_browser`
  
  ## Docs
  
  The developer documentation for Codex hooks should be updated alongside
  this feature to document `PreCompact` and `PostCompact`, the
  `manual`/`auto` matcher values, and the compact hook payload fields.
  
  ---------
  
  Co-authored-by: Vincent Koc <vincentkoc@ieee.org>

  Andrei Eternal · 2026-05-06 18:08:31 -07:00
  527d52df03
• feat: Add marketplace source filtering and plugin share context (#21419)

  Adds marketplaceKinds to plugin/list for local, workspace-directory, and
  shared-with-me; omitted params keep default local plus gated global
  behavior, while explicit kinds are exact.
  
  Exposes shareContext on plugin summaries from local share mappings and
  remote workspace/shared responses, including remotePluginId and nullable
  creator metadata.
  
  Adds shared-with-me listing through /ps/plugins/workspace/shared,
  renames the workspace remote namespace to workspace-directory, and keeps
  direct remote read/share/install/update/delete paths gated by plugins
  rather than remote_plugin.

  xl-openai · 2026-05-06 16:12:23 -07:00
  11106016ff
• [codex] Move tool specs into core handlers (#21416)

  ## Why
  
  This is the first mechanical slice of moving tool spec ownership toward
  the handlers. `codex-tools` should keep shared primitives and conversion
  helpers, while builtin tool specs and registration planning live in
  `codex-core` with the handlers that own those tools.
  
  Keeping this PR to relocation and import updates isolates the copy/move
  review from the later logic change that wires specs through registered
  handlers.
  
  ## What changed
  
  - Moved builtin tool spec constructors from `codex-rs/tools/src` into
  `codex-rs/core/src/tools/handlers/*_spec.rs` or nearby core tool
  modules.
  - Moved the registry planning code into
  `codex-rs/core/src/tools/spec_plan.rs` and its associated types/tests
  into core.
  - Kept shared primitives in `codex-tools`, including `ToolSpec`,
  schema/types, discovery/config primitives, dynamic/MCP conversion
  helpers, and code-mode collection helpers.
  - Updated handlers that referenced moved argument types or tool-name
  constants to use the core spec modules.
  - Moved spec tests next to the moved spec modules.
  
  ## Verification
  
  - `cargo check -p codex-tools`
  - `cargo check -p codex-core`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core _spec::tests`
  - `cargo test -p codex-core tools::spec_plan::tests`
  - `just fix -p codex-tools`
  - `just fix -p codex-core`
  
  Note: I also tried the broader `cargo test -p codex-core tools::`; it
  reached the moved spec-plan/spec tests successfully, then aborted with a
  stack overflow in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`,
  which is outside this spec relocation.

  pakrym-oai · 2026-05-06 15:40:50 -07:00
  9417cf9696
• 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
• Document Codex git commit attribution config (#21379)

  ## Summary
  - document that commit attribution for generated git commit messages is
  gated by the `codex_git_commit` feature flag
  - add an example `config.toml` snippet showing `commit_attribution` with
  `[features].codex_git_commit = true`
  - update the config schema description so the reference docs explain
  that `commit_attribution` only takes effect when the feature is enabled
  
  Fixes #19799.
  
  ## Validation
  - `cargo run -p codex-core --bin codex-write-config-schema`
  - `cargo test -p codex-config`
  - `cargo test -p codex-features`
  - `cargo fmt --check`
  - `git diff --check`
  
  ## Notes
  - `cargo test -p codex-core config_schema_matches_fixture` currently
  fails before reaching the schema test because `core_test_support`
  imports `similar` without a linked crate in this checkout. The narrower
  package checks above avoid that unrelated test-support build failure.

  Brian Henzelmann · 2026-05-06 16:14:50 -05:00
  8f5d68f9d2
• [codex] Fix Windows sandbox git safe.directory for worktrees (#21409)

  ## Why
  
  Windows sandboxed commands run as a sandbox user, while workspace
  repositories are usually owned by the real user. The sandbox compensates
  by injecting a temporary Git `safe.directory` entry into the child
  environment.
  
  That injection was still broken for linked worktrees because the helper
  followed the `.git` file's `gitdir:` pointer and injected the internal
  `.git/worktrees/...` location. Git's dubious-ownership check expects the
  worktree root instead, so sandboxed Git commands still failed in
  worktree-based Codex checkouts.
  
  ## What changed
  
  - Treat any `.git` marker, directory or file, as the worktree root for
  `safe.directory` injection.
  - Keep the safe-directory logic in
  `windows-sandbox-rs/src/sandbox_utils.rs` and have the one-shot elevated
  path reuse it.
  - Add regression coverage for both normal `.git` directories and
  gitfile-based worktrees.
  
  ## Validation
  
  - `cargo test -p codex-windows-sandbox sandbox_utils::tests`
  - `cargo test -p codex-windows-sandbox` built and ran; the new
  `sandbox_utils` tests passed, while two pre-existing legacy sandbox
  tests failed locally with `Access is denied`:
  `session::tests::legacy_non_tty_cmd_emits_output` and
  `spawn_prep::tests::legacy_spawn_env_applies_offline_network_rewrite`.

  iceweasel-oai · 2026-05-06 14:08:45 -07:00
  123e78b97b
• [codex-analytics] emit tool item events from item lifecycle (#17090)

  ## Why
  
  After the tool-item schemas are in place, analytics needs to emit them
  from the app-server item lifecycle rather than requiring bespoke
  tracking at each callsite. The reducer should also reuse the shared
  thread analytics context introduced below it in the stack so later event
  families do not repeat the same reducer joins or missing-state ladder.
  
  ## What changed
  
  - Tracks tool-item completion notifications and emits the matching tool
  analytics event when a terminal item arrives.
  - Derives event-specific payload details for command execution, file
  changes, MCP calls, dynamic tools, collaboration tools, web search, and
  image generation.
  - Denormalizes thread, app-server client, runtime, and subagent
  provenance metadata through the shared thread analytics context.
  - Adds reducer coverage for item lifecycle emission and subagent
  metadata inheritance.
  
  ## Duration semantics
  
  `duration_ms` is computed from the app-server item lifecycle timestamps:
  `completed_at_ms - started_at_ms`. That makes it the duration of the
  lifecycle Codex observed locally, not necessarily the upstream
  provider's full execution time.
  
  - Web search usually has a meaningful observed lifecycle because
  Responses can send `response.output_item.added` before
  `response.output_item.done`; in that case `started_at_ms` comes from the
  added event and `completed_at_ms` comes from the done event.
  - Image generation can be much less precise. In the current observed
  stream, image generation often arrives only as a completed
  `response.output_item.done`; when there is no earlier added event, Codex
  synthesizes the started item immediately before completion, so
  `duration_ms` can be `0` even though upstream image generation took
  longer.
  - Standalone web search and standalone image generation work is expected
  to land after this stack. Those paths may introduce more direct
  lifecycle events or timing points, so the current
  web-search/image-generation duration semantics should be treated as the
  best available item-lifecycle approximation, not the final latency
  contract for those tool families.
  - `execution_duration_ms` is populated only where the completed item
  already carries a native execution duration; otherwise it remains `null`
  while `duration_ms` still reflects the local lifecycle interval.
  
  ## Currently placeholder / partial fields
  
  Some fields are included in the schema for the intended steady-state
  contract, but this PR does not yet populate them from real
  approval/review state:
  
  - `review_count`, `guardian_review_count`, and `user_review_count`
  currently default to `0`.
  - `final_approval_outcome` currently defaults to `unknown`.
  - `requested_additional_permissions` and `requested_network_access`
  currently default to `false`.
  
  ## 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/17090).
  * #18748
  * #18747
  * __->__ #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-06 20:27:41 +00:00
  fbdbc6b2fe
• [codex-tui] pass thread source for tui threads (#21401)

  ## Summary
  - mark TUI-created thread starts and forks with explicit `thread_source
  = user`
  - add focused coverage for embedded and remote lifecycle request
  builders
  
  ## Why
  Thread analytics now consume an explicit thread-level source
  classification instead of inferring it from `session_source`. The TUI
  still omitted that field, so TUI-created interactive threads would
  continue to land as `null` even after the new analytics plumbing
  shipped.
  
  ## Validation
  - `cargo test -p codex-tui app_server_session --lib`

  rhan-oai · 2026-05-06 13:18:41 -07:00
  21295f47e2
• [codex] Split tool handlers into separate files (#21395)

  ## Why
  
  Several tool handler modules still bundled multiple `ToolHandler`
  implementations in one file. That made the handler directory harder to
  navigate and made otherwise local handler edits land in large shared
  modules.
  
  ## What
  
  - Split grouped tool handlers into one handler file each for agent jobs,
  goals, MCP resources, shell tools, and unified exec.
  - Kept shared parsing, payload, and runtime helpers in the existing
  parent modules, with re-exports preserving the existing handler import
  paths.
  - Updated the shell handler tests to construct `ShellCommandHandler`
  through the existing `ShellCommandBackendConfig` conversion now that the
  backend detail lives with the shell-command handler.
  
  ## Validation
  
  - `cargo check -p codex-core`
  - `cargo clippy -p codex-core --lib -- -D warnings`
  - `git diff --check -- codex-rs/core/src/tools/handlers`
  
  Targeted `codex-core` handler tests did not run locally because
  `core_test_support` currently fails to compile before reaching these
  tests due to an unresolved `similar` import.

  pakrym-oai · 2026-05-06 13:12:24 -07:00
  b9c50a53d7
• [codex] Dedupe fallback model metadata warnings (#21090)

  Fixes #21070.
  
  This is a small cleanup around model metadata handling for
  gateway/provider model names. It follows the report and proposed
  direction from @dkbush by keeping the fallback metadata warning useful
  without repeating it every turn, and by tightening the existing
  provider-prefix lookup path.
  
  - Track fallback metadata warning slugs in session state so each
  unresolved model warns once per session.
  - Keep warning emission outside the session-state lock and preserve the
  existing warning text.
  - Allow one-segment provider prefixes with hyphenated provider IDs,
  while preserving the multi-segment rejection behavior.
  - Add focused coverage for warning dedupe and hyphenated provider-prefix
  metadata matching.
  
  Testing:
  
  - Ran `just fmt`.
  - Ran `git diff --check`.
  - Added tests for the new warning dedupe and provider-prefix lookup
  behavior.

  canvrno-oai · 2026-05-06 13:11:44 -07:00
  d5f0b6d63a
• 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
• Avoid noisy OTEL diagnostics in codex exec (#21107)

  `codex exec` should not print OpenTelemetry exporter self-diagnostics to
  stderr by default. Suppress the SDK and OTLP exporter targets unless
  callers
  explicitly opt in with `RUST_LOG`.
  
  Also stop defaulting the trace exporter to the log exporter, since OTLP
  HTTP
  endpoints are signal-specific and a logs endpoint is not valid for
  spans.
  
  Co-authored-by: Codex <noreply@openai.com>
  
  Co-authored-by: Codex <noreply@openai.com>

  Christoph Paasch (OpenAI) · 2026-05-06 12:49:13 -07:00
  f9063045e1
• 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
• fix(tui): persist ctrl-c draft via app event (#21397)

  ## Why
  
  The main branch started failing after #21351 merged because the merge
  commit kept calling `AppCommand::add_to_history` from
  `BottomPane::clear_composer_for_ctrl_c`, but main had already removed
  that helper as part of the history persistence refactor. The PR head
  passed because it was based on an older main commit where the helper
  still existed.
  
  This restores the Ctrl+C draft-stashing behavior using the current
  app-event path instead of the removed command helper.
  
  ## What Changed
  
  - Store the active `ThreadId` in `BottomPane` when history metadata is
  provided.
  - Emit `AppEvent::AppendMessageHistoryEntry` for Ctrl+C-cleared drafts.
  - Update the slash-clear regression test to assert the current history
  event shape.
  
  ## How to Test
  
  Targeted tests:
  - `cargo test -p codex-tui
  slash_clear_after_ctrl_c_keeps_stashed_draft_recallable`
  
  Broader local checks:
  - `just fix -p codex-tui`
  - `just argument-comment-lint -p codex-tui`
  - `git diff --check origin/main...HEAD`
  - `cargo test -p codex-tui` reached completion; the fixed test passed,
  and the only local failures were
  `status::tests::status_permissions_full_disk_managed_*`, blocked by this
  machine config rejecting `DangerFullAccess` via
  `/etc/codex/requirements.toml`.

  Felipe Coury · 2026-05-06 19:03:11 +00:00
  6b7d6cafa0
• [codex] Handle git pagination flags by position (#21381)

  ## Why
  
  This is a follow-up to the Windows Git safe-command bypass fix for
  BUGB-15601. Git's global `--paginate` / `-p` flags can route output
  through a configured pager, so they should not be auto-approved as safe
  before the subcommand. At the same time, `-p` after read-only
  subcommands like `log`, `diff`, and `show` is the common patch-output
  flag, so treating every `-p` as unsafe would make ordinary read-only
  inspection commands prompt unnecessarily.
  
  ## What Changed
  
  - Split Git option safety matching into explicit global-option and
  subcommand-option lists.
  - Treat global `git --paginate ...` and `git -p ...` as unsafe.
  - Keep post-subcommand patch usage such as `git log -p`, `git diff -p`,
  and `git show -p HEAD` safe.
  - Keep the pagination coverage with the shared Git safe-command
  implementation rather than the Windows wrapper tests.
  - Remove the stale `git_global_option_requires_prompt` helper now that
  safe-command Git option matching owns the prompt-required lists.
  
  ## Testing
  
  - `cargo test -p codex-shell-command`

  iceweasel-oai · 2026-05-06 11:53:26 -07:00
  f32c496144
• 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
• vendor: update bubblewrap to 0.11.2 (#21389)

  ## Why
  
  `codex-rs/vendor/bubblewrap` had fallen behind upstream, and upstream
  `v0.11.2` is the current Bubblewrap release. The release is a security
  update for `CVE-2026-41163`, affecting setuid Bubblewrap builds, and
  deprecates setuid support in favor of the default non-setuid build mode.
  
  ## What changed
  
  - Refreshed the vendored Bubblewrap sources under
  `codex-rs/vendor/bubblewrap` to upstream `v0.11.2`.
  - Brought in the upstream `-Dsupport_setuid` build option, which
  defaults setuid support off.
  - Updated vendored release notes and documentation files included with
  Bubblewrap.
  
  ## Verification
  
  Not run locally; this PR only refreshes the vendored upstream Bubblewrap
  source snapshot.
  
  Upstream release:
  https://github.com/containers/bubblewrap/releases/tag/v0.11.2

  Michael Bolin · 2026-05-06 18:10:30 +00:00
  123ec8b035
• fix(tui): keep Ctrl-C stashed drafts after /clear (#21351)

  ## Why
  
  When a user stashes a draft with Ctrl+C, then runs `/clear`, the fresh
  chat session loses the in-memory composer history that held the stashed
  draft. Pressing Up after `/clear` can then recall an older submitted
  prompt instead of the draft the user explicitly saved for later.
  
  ## What Changed
  
  - Record Ctrl+C-cleared composer text through the existing message
  history path, so it survives the fresh session created by `/clear`.
  - Keep `/clear` itself out of local slash-command recall so it does not
  sit ahead of the stashed draft.
  - Add regression coverage for the full flow: submit a prompt, stash a
  later draft with Ctrl+C, run `/clear`, then recall the stashed draft
  before the older prompt.
  
  ## How to Test
  
  1. Start Codex with `just c`.
  2. Submit a short prompt such as `ok` and wait for the turn to complete.
  3. Type a new draft, press Ctrl+C, then run `/clear`.
  4. Press Up and confirm the stashed draft is restored.
  5. Press Up again and confirm the older submitted prompt is still
  reachable after the stashed draft.
  
  Targeted tests:
  
  - `cargo test -p codex-tui
  slash_clear_after_ctrl_c_keeps_stashed_draft_recallable`
  
  Manual verification:
  
  - Reproduced the issue in tmux with `RUST_LOG=trace just c -c
  log_dir=...`: before the fix, Up after `/clear` recalled the older
  submitted prompt.
  - Re-tested the same tmux flow after the fix: Up after `/clear` restored
  the Ctrl+C-stashed draft.

  Felipe Coury · 2026-05-06 14:46:18 -03:00
  e97610cf3b
• [codex] Coordinate OpenAI docs sample with API key setup (#21263)

  ## Summary
  - Add the same API key setup coordination guidance to the embedded
  OpenAI Docs sample skill in `codex-rs/skills`.
  - Keep the skill description/frontmatter unchanged; the coordination
  lives only in the body.
  - Preserve direct OpenAI Docs routing for docs-only questions,
  citations, model/API guidance, conceptual explanations, and non-building
  examples.
  
  ## Why
  The Codex repo carries its own OpenAI Docs skill variant under
  `codex-rs/skills/src/assets/samples`. This keeps that embedded sample
  aligned with the other OpenAI Docs variants patched in the related PRs.
  
  ## Validation
  - `cargo test -p codex-skills`
  - `git diff --check`

  mifan-oai · 2026-05-06 13:46:15 -04:00
  f2f5d6f6c7
• feat: move auto vaccum (#21378)

  The initial vaccum is not needed anymore. We can consider all the DBs
  have been reclaimed by now

  jif-oai · 2026-05-06 19:32:28 +02:00
  ab43db44a2
• rollout: coalesce thread updated_at touches (#21367)

  ## Why
  
  Metadata-irrelevant rollout events currently refresh
  `threads.updated_at` on every flush. That keeps thread recency accurate,
  but it also turns high-frequency agent output into unnecessary SQLite
  writes. Recency only needs to advance periodically during an active
  session, while the final suppressed touch still needs to be persisted
  before shutdown.
  
  ## What changed
  
  - coalesce touch-only `updated_at` writes in the rollout writer, with a
  short production interval between persisted touches
  - retain the latest suppressed touch and flush it during shutdown so the
  thread is not left stale
  - extend rollout recorder coverage for coalesced touches, delayed
  refresh, shutdown flushing, and the existing missing-thread fallback
  path
  
  ## Verification
  
  - Added regression coverage in `rollout/src/recorder_tests.rs` for
  coalescing and shutdown flushing behavior.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 19:32:24 +02:00
  0e821b380a
• [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
• [codex] fix builtin MCP Windows path test (#21350)

  ## Summary
  - make the builtin MCP config test derive the expected `--codex-home`
  argument from `AbsolutePathBuf`
  
  ## Why
  `AbsolutePathBuf::try_from("/tmp/codex-home")` is rendered as
  `D:\\tmp\\codex-home` on Windows, but the test asserted the Unix literal
  `"/tmp/codex-home"`. That made the Windows Bazel job fail even though
  the production code was behaving correctly.
  
  ## Impact
  This keeps the test cross-platform while preserving the same transport
  assertion on Unix and Windows.
  
  ## Validation
  - `cargo test -p codex-builtin-mcps`
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 16:06:21 +02:00
  ebd9ec05b4
• feat(app-server): move v2 sessionId onto Thread (#21336)

  ## Why
  
  `session_id` and `thread_id` are separate identities after #20437, but
  app-server only surfaced `sessionId` on the `thread/start`,
  `thread/resume`, and `thread/fork` response envelopes. Other
  thread-bearing surfaces such as `thread/list`, `thread/read`,
  `thread/started`, `thread/rollback`, `thread/metadata/update`, and
  `thread/unarchive` either lacked the grouping key or forced clients to
  special-case those three responses.
  
  Making `sessionId` part of the reusable `Thread` payload gives every v2
  API surface one place to expose session-tree identity.
  
  ## Mental model
    1. thread.sessionId lives on `Thread`
  2. It is a view/runtime identity for the current live session tree, not
  durable stored lineage metadata
  3. When app-server has a live loaded thread, it copies the real value
  from core’s session_configured.session_id
  4. When it only has stored/unloaded data, it falls back to
  thread.sessionId = thread.id
  
  ## What changed
  
  - Added `sessionId` to the v2
  [`Thread`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server-protocol/src/protocol/v2/thread_data.rs#L105-L109).
  - Removed the duplicate top-level `sessionId` fields from
  `thread/start`, `thread/resume`, and `thread/fork`; clients should now
  read `response.thread.sessionId`.
  - Populated `thread.sessionId` when building live thread responses,
  replaying loaded threads, and returning stored-thread summaries so the
  field is present across start, resume, fork, list, read, rollback,
  metadata-update, unarchive, and `thread/started` paths. See
  [`load_thread_from_resume_source_or_send_internal`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server/src/request_processors/thread_processor.rs#L2824-L2918)
  and
  [`thread_from_stored_thread`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server/src/request_processors/thread_processor.rs#L3671-L3719).
  - Preserved the stored-thread fallback: if a thread has not been loaded
  into a live session tree yet, `thread.sessionId` falls back to
  `thread.id`; once the thread is live again, the field reports the active
  session tree root.
  - Regenerated the JSON/TypeScript schemas and updated the app-server
  README examples to show
  [`thread.sessionId`](https://github.com/openai/codex/blob/8fc9e9b4cf81b6f61d432e71f1eb266f6f104b63/codex-rs/app-server/README.md#L306-L310)
  on the thread object.

  jif-oai · 2026-05-06 15:23:25 +02:00
  5ecff05196
• chore: spawn MCP for memories (#21214)

  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 15:05:54 +02:00
  ca257b6ce5
• Move installation ID resolution out of core startup (#21182)

  ## Summary
  
  - resolve or inject the installation ID before core startup and pass it
  through `ThreadManager`, `CodexSpawnArgs`, and `Session` as a plain
  `String`
  - keep child sessions on the parent installation ID instead of
  rediscovering it inside core
  - propagate installation ID startup failures in `mcp-server` instead of
  panicking
  
  ## Why
  
  Core was still touching the filesystem on the session startup path to
  discover `installation_id`. This moves that work to the outer host
  boundary so core no longer depends on `codex_home` reads during session
  construction.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 10:48:54 +00:00
  8f3bb355f4
• Propagate cache key and service tiers in compact (#21249)

  ## Why
  
  `/responses/compact` should preserve the request-affinity fields that
  apply to the active auth mode. ChatGPT-auth compact requests need the
  effective `service_tier`, and compact requests for every auth mode need
  the stable `prompt_cache_key`, so compaction does not quietly lose
  routing or cache behavior that normal sampling already has.
  
  This follows the request-parity direction from #20719, but keeps the net
  change focused on the compact payload fields needed here.
  
  ## What changed
  
  - Add `service_tier` and `prompt_cache_key` to the compact endpoint
  input payload.
  - Build the remote compact payload from the existing responses request
  builder output so `Fast` still maps to `priority` when compact sends a
  service tier.
  - Pass the turn service tier into remote compaction, but only include it
  in compact payloads for ChatGPT-backed auth.
  - Keep `prompt_cache_key` on compact payloads for all auth modes.
  - Add request-body diff snapshot coverage in
  `core/tests/suite/compact_remote.rs` for:
  - API-key auth reusing `prompt_cache_key` while omitting `service_tier`
  even when `Fast` is configured.
    - ChatGPT auth reusing both `service_tier` and `prompt_cache_key`.
  - Drive the snapshot coverage through five varied turns: plain text,
  multi-part text, tool-call continuation, image+text input, local-shell
  continuation, and final-turn reasoning output.
  
  ## Verification
  
  - Added insta snapshots for compact request-body parity against the last
  normal `/responses` request after five varied turns.
  - Not run locally per repo guidance; relying on GitHub CI for test
  execution.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-06 13:38:43 +03:00
  5d6f23a27b
• Revert "feat: support template interpolation in multi-agent usage hints" (#21337)

  Reverts openai/codex#20973

  jif-oai · 2026-05-06 12:33:37 +02:00
  cc84e6bc6d
• feat: return session ID from thread/fork (#21332)

  ## Why
  
  `thread/start` and `thread/resume` already return `sessionId`, but
  `thread/fork` only returned the new thread. That left clients to infer
  the forked thread's session identity from `thread.id`, which kept the
  new `session_id` / `thread_id` split implicit at one lifecycle boundary.
  Follow-up to #20437.
  
  ## What changed
  
  - Add `sessionId` to `ThreadForkResponse`.
  - Populate it from the forked session configuration.
  - Regenerate the v2 JSON/TypeScript schema fixtures and update the
  app-server docs/example.
  - Extend the fork integration test to assert the returned `sessionId`.
  
  ## Verification
  
  - Added coverage in `thread_fork_creates_new_thread_and_emits_started`
  for the new response field.

  jif-oai · 2026-05-06 12:04:27 +02:00
  06e5dfa4dd
• feat: include thread ID in MCP turn metadata (#21329)

  ## Why
  
  MCP tool calls already include `session_id` in `x-codex-turn-metadata`,
  but descendant threads intentionally share that value with the root
  thread. Consumers that need to correlate work at the concrete thread
  level also need the current `thread_id`.
  
  ## What changed
  
  - add `thread_id` to `x-codex-turn-metadata` while preserving
  `session_id` as the shared session identity
  - thread the two identities separately through normal turns and spawned
  review threads
  - add regression coverage for resumed sessions, reserved metadata
  fields, and deferred MCP tool calls
  
  ## Verification
  
  - added focused coverage in `core/src/session/tests.rs`,
  `core/src/turn_metadata_tests.rs`, and `core/tests/suite/search_tool.rs`

  jif-oai · 2026-05-06 11:36:15 +02:00
  fe24a180ab
• test: isolate app-server-client in-process test state (#21328)

  ## Why
  
  The in-process `app-server-client` tests were still building their
  configs from the ambient `codex_home` and letting the embedded app
  server create its own state DB when `state_db` was absent. That matters
  because in-process startup falls back to
  `init_state_db_from_config(...)` in that case, so tests can otherwise
  share persisted state instead of getting isolated fixtures:
  [`app-server/src/in_process.rs`](https://github.com/openai/codex/blob/a98623511ba433154ec811fc63091617f5945438/codex-rs/app-server/src/in_process.rs#L368-L373).
  
  ## What changed
  
  - Give each in-process test client its own temporary `codex_home`.
  - Initialize the matching state DB from that per-client config and pass
  it into the client explicitly.
  - Keep the temp directory alive for the lifetime of the test client
  through a small `TestClient` wrapper.
  - Add `tempfile` as a dev dependency for the new harness.
  
  The updated setup lives in
  [`app-server-client/src/lib.rs`](https://github.com/openai/codex/blob/35c1133d45d10931914dbb88a1246a195d025ff6/codex-rs/app-server-client/src/lib.rs#L982-L1055).
  
  ## Testing
  
  - Existing `codex-app-server-client` tests continue to exercise the
  updated in-process client path through the isolated helper.

  jif-oai · 2026-05-06 09:21:22 +00:00
  b5e965e1d7
• feat: add session_id (#20437)

  ## Summary
  
  Related to
  https://openai.slack.com/archives/C095U48JNL9/p1777537279707449
  TLDR:
  We update the meaning of session ids and thread ids:
  * thread_id stays as now
  * session_id become a shared id between every thread under a /root
  thread (i.e. every sub-agent share the same session id)
  
  This PR introduces an explicit `SessionId` and threads it through the
  protocol/client boundary so `session_id` and `thread_id` can diverge
  when they need to, while preserving compatibility for older serialized
  `session_configured` events.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 10:48:37 +02:00
  a98623511b
• Support Codex Apps auth elicitations (#19193)

  ## Summary
  
  - request URL-mode MCP elicitations when Codex Apps tool calls fail with
  connector auth metadata
  - route Codex Apps auth URL elicitations into the TUI app-link flow
  
  ## Test plan
  
  - `just fmt`
  - `cargo test -p codex-core mcp_tool_call::tests`
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-tui bottom_pane::app_link_view::tests`
  - `just fix -p codex-core`
  - `just fix -p codex-mcp`
  - `just fix -p codex-tui`
  
  Also attempted broader local runs:
  
  - `cargo test -p codex-core` fails in unrelated
  config/request-permission/proxy-sensitive tests under the current Codex
  Desktop environment.
  - `cargo test -p codex-tui` fails in unrelated status
  snapshots/trust-default tests because the ambient environment renders
  workspace-write/network permission defaults.

  Matthew Zeng · 2026-05-06 07:18:00 +00:00
  f9a907aebe
• release: bundle bwrap with Linux codex DotSlash artifact (#21312)

  ## Why
  
  #21255 changed the Linux sandbox fallback so Codex can use a bundled
  `codex-resources/bwrap` executable when no suitable system `bwrap` is
  available. That lookup is relative to the native Codex executable
  returned by
  `std::env::current_exe()`, as implemented in
  [`bundled_bwrap.rs`](https://github.com/openai/codex/blob/9766d3d51cec885114b6d6c53a02e9efbaf87171/codex-rs/linux-sandbox/src/bundled_bwrap.rs#L83-L93).
  
  The release already publishes a separate `bwrap` DotSlash output, but
  the Linux `codex` DotSlash output still pointed at a single-binary
  `.zst` payload. Running the `codex` DotSlash manifest only materializes
  the native `codex` executable; it does not also create sibling files
  from the separate `bwrap` manifest. The fallback path therefore needs
  the Linux `codex` DotSlash artifact itself to include the real `bwrap`
  executable at `codex-resources/bwrap`.
  
  ## What changed
  
  - stage a Linux primary `codex-<target>-bundle.tar.zst` release artifact
  containing `codex` and `codex-resources/bwrap`
  - point the Linux `codex` DotSlash outputs at that bundle tarball
  - leave the standalone `bwrap` DotSlash output in place for consumers
  that want to fetch `bwrap` directly
  
  ## Verification
  
  - `jq . .github/dotslash-config.json`
  - Ruby YAML parse of `.github/workflows/rust-release.yml`

  Michael Bolin · 2026-05-05 23:33:13 -07:00
  22326e263c
• fix(bwrap): emit libcap after standalone archive (#21285)

  ## Why
  
  #21255 added the standalone `codex-bwrap` binary. In the Cargo build,
  [`pkg_config::probe("libcap")`](https://github.com/openai/codex/blob/a736cb55a2bce57b4c8e5a4fe56f70c2b2ad892b/codex-rs/bwrap/build.rs#L37-L39)
  emits `-lcap` before
  [`cc::Build::compile("standalone_bwrap")`](https://github.com/openai/codex/blob/a736cb55a2bce57b4c8e5a4fe56f70c2b2ad892b/codex-rs/bwrap/build.rs#L50-L67)
  adds the static bwrap archive. The Linux musl link then sees `-lcap
  -lstandalone_bwrap`; because static archives are resolved left-to-right,
  `cap_from_name` is still undefined once `standalone_bwrap` introduces
  that reference.
  
  The musl setup already builds `libcap.a` and exposes it through
  [`libcap.pc`](https://github.com/openai/codex/blob/a736cb55a2bce57b4c8e5a4fe56f70c2b2ad892b/.github/scripts/install-musl-build-tools.sh#L78-L88),
  so the failure is link ordering rather than a missing dependency.
  
  ## What changed
  
  - probe `libcap` with `cargo_metadata(false)` so `pkg-config` does not
  emit its link flags early
  - emit the discovered `libcap` search paths and libraries after
  `standalone_bwrap` is compiled, preserving the needed static-link order
  
  ## Verification
  
  - `cargo test -p codex-bwrap`
  - `cargo clippy -p codex-bwrap --all-targets`
  
  The affected Linux musl release link is exercised by CI, which is the
  path this fix targets.

  viyatb-oai · 2026-05-05 22:22:01 -07:00
  9766d3d51c
• [mcp] Return Accept early per feedback. (#21277)

  - [x] Return Accept early when auto_deny is enabled per feedback.

  Matthew Zeng · 2026-05-05 21:23:42 -07:00
  41505bcea2
• Preserve session MCP config on refresh (#21055)

  # Overview
  MCP refreshes were rebuilding active threads from fresh disk-backed
  config only, which dropped thread-start session overlays such as
  app-injected MCP servers. This keeps refreshes current with disk config
  while preserving the thread-local config that only the active thread
  knows about.
  
  # Changes
  - Rebuild refreshed config per active thread using that thread's current
  `cwd`, rather than fanning out one app-server config to every thread.
  - Preserve each thread's `SessionFlags` layer while replacing reloadable
  config layers with freshly loaded config, then derive the MCP refresh
  payload from the rebuilt result.
  - Move MCP refresh orchestration into app-server so manual refreshes
  fail loudly while background refreshes remain best-effort, and route
  plugin-triggered refreshes through the same per-thread reload path.
  - Add regression coverage for session overlays, fresh project config,
  plugin-derived MCP config, current requirements, and strict vs
  best-effort refresh behavior.
  
  # Verification
  - Passed focused Rust coverage for the thread-config rebuild behavior
  and deferred MCP refresh flow, plus `cargo test -p codex-app-server
  --lib`.
  - Verified end to end in the Codex dev app against the locally built
  CLI: registered an MCP via thread config, verified that it could be used
  successfully before refresh, manually triggered MCP refresh, and
  verified that it continued to be available afterward.

  aaronl-openai · 2026-05-05 21:09:28 -07:00
  9f06d171e2