2248 Commits

• Extract built-in tool spec constructors into codex-tools (#16493)

  ## Why
  
  `core/src/tools/spec.rs` still had a few built-in tool specs assembled
  inline even though those definitions are pure metadata and already live
  conceptually in `codex-tools`. Keeping that construction in `codex-core`
  makes `spec.rs` do more than registry orchestration and slows the
  migration toward a right-sized `codex-tools` crate.
  
  This continues the extraction stack from #16379, #16471, #16477, #16481,
  and #16482.
  
  ## What Changed
  
  - added `create_local_shell_tool()`, `create_web_search_tool(...)`, and
  `create_image_generation_tool(...)` to `codex-rs/tools/src/tool_spec.rs`
  - exported those helpers from `codex-rs/tools/src/lib.rs`
  - switched `codex-rs/core/src/tools/spec.rs` to call those helpers
  instead of constructing `ToolSpec::LocalShell`, `ToolSpec::WebSearch`,
  and `ToolSpec::ImageGeneration` inline
  - removed the remaining core-local web-search content-type constant and
  made the affected spec test assert the literal expected values directly
  
  This is intended to be a straight refactor: tool behavior and wire shape
  should not change.
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`

  Michael Bolin · 2026-04-01 19:31:24 -07:00
  5a2f3a8102
• Remove client_common tool re-exports (#16482)

  ## Why
  
  `codex-rs/core/src/client_common.rs` still had a `tools` re-export
  module that forwarded `codex_tools` types back into `codex-core`. After
  the earlier extraction work in #16379, #16471, #16477, and #16481, that
  extra layer no longer adds value.
  
  Removing it keeps dependencies explicit: the `codex-core` modules that
  actually use `ToolSpec` and related types now depend on `codex_tools`
  directly instead of reaching through `client_common`.
  
  ## What Changed
  
  - removed the `client_common::tools` re-export module from
  `core/src/client_common.rs`
  - updated the remaining `codex-core` consumers to import `codex_tools`
  directly
  - adjusted the affected test code to reference
  `codex_tools::ResponsesApiTool` directly as well
  
  This is a mechanical cleanup only. It does not change tool behavior or
  runtime logic.
  
  ## Testing
  
  - `cargo test -p codex-core client_common::tests`
  - `cargo test -p codex-core tools::router::tests`
  - `cargo test -p codex-core tools::context::tests`
  - `cargo test -p codex-core tools::spec::tests`

  Michael Bolin · 2026-04-01 19:15:15 -07:00
  d4464125c5
• Extract MCP into codex-mcp crate (#15919)

  - Split MCP runtime/server code out of `codex-core` into the new
  `codex-mcp` crate. New/moved public structs/types include `McpConfig`,
  `McpConnectionManager`, `ToolInfo`, `ToolPluginProvenance`,
  `CodexAppsToolsCacheKey`, and the `McpManager` API
  (`codex_mcp::mcp::McpManager` plus the `codex_core::mcp::McpManager`
  wrapper/shim). New/moved functions include `with_codex_apps_mcp`,
  `configured_mcp_servers`, `effective_mcp_servers`,
  `collect_mcp_snapshot`, `collect_mcp_snapshot_from_manager`,
  `qualified_mcp_tool_name_prefix`, and the MCP auth/skill-dependency
  helpers. Why: this creates a focused MCP crate boundary and shrinks
  `codex-core` without forcing every consumer to migrate in the same PR.
  
  - Move MCP server config schema and persistence into `codex-config`.
  New/moved structs/enums include `AppToolApproval`,
  `McpServerToolConfig`, `McpServerConfig`, `RawMcpServerConfig`,
  `McpServerTransportConfig`, `McpServerDisabledReason`, and
  `codex_config::ConfigEditsBuilder`. New/moved functions include
  `load_global_mcp_servers` and
  `ConfigEditsBuilder::replace_mcp_servers`/`apply`. Why: MCP TOML
  parsing/editing is config ownership, and this keeps config
  validation/round-tripping (including per-tool approval overrides and
  inline bearer-token rejection) in the config crate instead of
  `codex-core`.
  
  - Rewire `codex-core`, app-server, and plugin call sites onto the new
  crates. Updated `Config::to_mcp_config(&self, plugins_manager)`,
  `codex-rs/core/src/mcp.rs`, `codex-rs/core/src/connectors.rs`,
  `codex-rs/core/src/codex.rs`,
  `CodexMessageProcessor::list_mcp_server_status_task`, and
  `utils/plugins/src/mcp_connector.rs` to build/pass the new MCP
  config/runtime types. Why: plugin-provided MCP servers still merge with
  user-configured servers, and runtime auth (`CodexAuth`) is threaded into
  `with_codex_apps_mcp` / `collect_mcp_snapshot` explicitly so `McpConfig`
  stays config-only.

  Ahmed Ibrahim · 2026-04-01 19:03:26 -07:00
  59b68f5519
• Extract update_plan tool spec into codex-tools (#16481)

  ## Why
  
  `codex-rs/core/src/tools/handlers/plan.rs` still owned both the
  `update_plan` runtime handler and the static tool definition. The tool
  definition is pure metadata, so keeping it in `codex-core` works against
  the ongoing effort to move tool-spec code into `codex-tools` and keep
  `codex-core` focused on orchestration and execution paths.
  
  This continues the extraction work from #16379, #16471, and #16477.
  
  ## What Changed
  
  - added `codex-rs/tools/src/plan_tool.rs` with
  `create_update_plan_tool()`
  - re-exported that constructor from `codex-rs/tools/src/lib.rs`
  - updated `codex-rs/core/src/tools/spec.rs` and
  `codex-rs/core/src/tools/spec_tests.rs` to use the `codex-tools` export
  instead of a core-local static
  - removed the old `PLAN_TOOL` definition from
  `codex-rs/core/src/tools/handlers/plan.rs`; the `PlanHandler` runtime
  logic still stays in `codex-core`
  - tightened two `codex-core` aliases to `#[cfg(test)]` now that
  production code no longer needs them
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16481).
  * #16482
  * __->__ #16481

  Michael Bolin · 2026-04-01 15:51:52 -07:00
  6cf832fc63
• fix(guardian): make GuardianAssessmentEvent.action strongly typed (#16448)

  ## Description
  
  Previously the `action` field on `EventMsg::GuardianAssessment`, which
  describes what Guardian is reviewing, was typed as an arbitrary JSON
  blob. This PR cleans it up and defines a sum type representing all the
  various actions that Guardian can review.
  
  This is a breaking change (on purpose), which is fine because:
  - the Codex app / VSCE does not actually use `action` at the moment
  - the TUI code that consumes `action` is updated in this PR as well
  - rollout files that serialized old `EventMsg::GuardianAssessment` will
  just silently drop these guardian events
  - the contract is defined as unstable, so other clients have a fair
  warning :)
  
  This will make things much easier for followup Guardian work.
  
  ## Why
  
  The old guardian review payloads worked, but they pushed too much shape
  knowledge into downstream consumers. The TUI had custom JSON parsing
  logic for commands, patches, network requests, and MCP calls, and the
  app-server protocol was effectively just passing through an opaque blob.
  
  Typing this at the protocol boundary makes the contract clearer.

  Owen Lin · 2026-04-01 15:42:18 -07:00
  30f6786d62
• login: treat provider auth refresh_interval_ms=0 as no auto-refresh (#16480)

  ## Why
  
  Follow-up to #16288: the new dynamic provider auth token flow currently
  defaults `refresh_interval_ms` to a non-zero value and rejects `0`
  entirely.
  
  For command-backed bearer auth, `0` should mean "never auto-refresh".
  That lets callers keep using the cached token until the backend actually
  returns `401 Unauthorized`, at which point Codex can rerun the auth
  command as part of the existing retry path.
  
  ## What changed
  
  - changed `ModelProviderAuthInfo.refresh_interval_ms` to accept `0` and
  documented that value as disabling proactive refresh
  - updated the external bearer token refresher to treat
  `refresh_interval_ms = 0` as an indefinitely reusable cached token,
  while still rerunning the auth command during unauthorized recovery
  - regenerated `core/config.schema.json` so the schema minimum is `0` and
  the new behavior is described in the field docs
  - added coverage for both config deserialization and the no-auto-refresh
  plus `401` recovery behavior
  
  ## How tested
  
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-login`
  - `cargo test -p codex-core test_deserialize_provider_auth_config_`

  Michael Bolin · 2026-04-01 15:30:10 -07:00
  f83f3fa2a6
• Extract tool discovery helpers into codex-tools (#16477)

  ## Why
  
  Follow-up to #16379 and #16471.
  
  `codex-rs/core/src/tools/spec.rs` still owned the pure discovery-shaping
  helpers that turn app metadata and discoverable tool metadata into the
  inputs used by `tool_search` and `tool_suggest`. Those helpers do not
  need `codex-core` runtime state, so keeping them in `codex-core`
  continued to blur the crate boundary this migration is trying to
  tighten.
  
  This change keeps pushing spec-only logic behind the `codex-tools` API
  so `codex-core` can focus on wiring runtime handlers to the resulting
  tool definitions.
  
  ## What Changed
  
  - Added `collect_tool_search_app_infos` and
  `collect_tool_suggest_entries` to
  `codex-rs/tools/src/tool_discovery.rs`.
  - Added a small `ToolSearchAppSource` adapter type in `codex-tools` so
  `codex-core` can pass app metadata into that shared helper logic without
  exposing `ToolInfo` across the crate boundary.
  - Re-exported the new discovery helpers from
  `codex-rs/tools/src/lib.rs`, which remains exports-only.
  - Updated `codex-rs/core/src/tools/spec.rs` to use those `codex-tools`
  helpers instead of maintaining local `tool_search_app_infos` and
  `tool_suggest_entries` functions.
  - Removed the now-redundant helper implementations from `codex-core`.
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`

  Michael Bolin · 2026-04-01 14:41:20 -07:00
  1b711a5501
• Extract tool spec helpers into codex-tools (#16471)

  ## Why
  
  Follow-up to #16379.
  
  `codex-rs/core/src/tools/spec.rs` and the corresponding handlers still
  owned several pure tool-definition helpers even though they do not need
  `codex-core` runtime state. Keeping that spec-only logic in `codex-core`
  keeps the crate boundary blurry and works against the guidance in
  `AGENTS.md` to keep shared tooling out of `codex-core` when possible.
  
  This change takes another step toward a dedicated `codex-tools` crate by
  moving more metadata and schema-building code behind the `codex-tools`
  API while leaving the actual tool execution paths in `codex-core`.
  
  ## What Changed
  
  - Added `codex-rs/tools/src/apply_patch_tool.rs` to own
  `ApplyPatchToolArgs`, the freeform/json `apply_patch` tool specs, and
  the moved `tool_apply_patch.lark` grammar.
  - Updated `codex-rs/tools/BUILD.bazel` so Bazel exposes the moved
  grammar file to `codex-tools`.
  - Moved the `request_user_input` availability and description helpers
  into `codex-rs/tools/src/request_user_input_tool.rs`, with the related
  unit tests moved alongside that business logic.
  - Moved `request_permissions_tool_description()` into
  `codex-rs/tools/src/local_tool.rs`.
  - Rewired `codex-rs/core/src/tools/spec.rs`,
  `codex-rs/core/src/tools/handlers/apply_patch.rs`, and
  `codex-rs/core/src/tools/handlers/request_user_input.rs` to consume the
  new `codex-tools` exports instead of local helper code.
  - Removed the now-redundant helper implementations and tests from
  `codex-core`, plus a couple of stale `client_common` re-exports that
  became unused after the move.
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tools::spec::tests`
  - `cargo test -p codex-core tools::handlers::apply_patch::tests`

  Michael Bolin · 2026-04-01 14:06:04 -07:00
  e6f5451a2c
• Extract tool config into codex-tools (#16379)

  ## Why
  
  `codex-core` already owns too much of the tool stack, and `AGENTS.md`
  explicitly pushes us to move shared code out of `codex-core` instead of
  letting it keep growing. This PR takes the next incremental step in
  moving `core/src/tools` toward `codex-rs/tools` by extracting
  low-coupling tool configuration and image-detail gating logic into
  `codex-tools`.
  
  That gives later extraction work a cleaner boundary to build on without
  trying to move the entire tools subtree in one shot.
  
  ## What changed
  
  - moved `ToolsConfig`, `ToolsConfigParams`, shell backend config, and
  unified-exec session selection from `core/src/tools/spec.rs` into
  `codex-tools`
  - moved original image-detail gating and normalization into
  `codex-tools`
  - updated `codex-core` to consume the new `codex-tools` exports and pass
  a rendered agent-type description instead of raw role config
  - kept `codex-rs/tools/src/lib.rs` exports-only, with extracted unit
  tests living in sibling `*_tests.rs` modules
  
  ## Testing
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`

  Michael Bolin · 2026-04-01 13:21:50 -07:00
  a99d4845e3
• fix(core) rm execute_exec_request sandbox_policy (#16422)

  ## Summary
  In #11871 we started consolidating on ExecRequest.sandbox_policy instead
  of passing in a separate policy object that theoretically could differ
  (but did not). This finishes the some parameter cleanup.
  
  This should be a simple noop, since all 3 callsites of this function
  already used a cloned object from the ExecRequest value.
  
  ## Testing
  - [x] Existing tests pass

  Dylan Hurd · 2026-04-01 11:03:48 -04:00
  d3b99ef110
• nit: deny field v2 (#16427)
  jif-oai · 2026-04-01 12:26:40 +02:00
  5bbfee69b6
• feat: tasks can't be assigned to root agent (#16424)
  jif-oai · 2026-04-01 12:18:50 +02:00
  0c776c433b
• Use message string in v2 assign_task (#16419)

  Fix assign task and clean everything
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-01 11:40:19 +02:00
  3152d1a557
• Use message string in v2 send_message (#16409)

  ## Summary
  - switch MultiAgentV2 send_message to accept a single message string
  instead of items
  - keep the old assign_task item parser in place for the next branch
  - update send_message schema/spec and focused handler tests
  
  ## Verification
  - cargo test -p codex-tools
  send_message_tool_requires_message_and_uses_submission_output
  - cargo test -p codex-core multi_agent_v2_send_message
  - just fix -p codex-tools
  - just fix -p codex-core
  - just argument-comment-lint
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-01 11:26:22 +02:00
  23d638a573
• Use message string in v2 spawn_agent (#16406)

  ## Summary
  - switch MultiAgentV2 spawn_agent to accept a single message string
  instead of items
  - update v2 spawn tool schema and focused handler/spec tests
  
  ## Verification
  - cargo test -p codex-tools
  spawn_agent_tool_v2_requires_task_name_and_lists_visible_models
  - cargo test -p codex-core multi_agent_v2_spawn
  - just fix -p codex-tools
  - just fix -p codex-core
  - just argument-comment-lint
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-01 11:26:12 +02:00
  d0474f2bc1
• Refactor chatwidget tests into topical modules (#16361)

  Problem: `chatwidget/tests.rs` had grown into a single oversized test
  blob that was hard to maintain and exceeded the repo's blob size limit.
  
  Solution: split the chatwidget tests into topical modules with a thin
  root `tests.rs`, shared helper utilities, preserved snapshot naming, and
  hermetic test config so the refactor stays stable and passes the
  `codex-tui` test suite.

  Eric Traut · 2026-03-31 16:45:58 -06:00
  424e532a6b
• Fix Windows external bearer refresh test (#16366)

  ## Why
  
  https://github.com/openai/codex/pull/16287 introduced a change to
  `codex-rs/login/src/auth/auth_tests.rs` that uses a PowerShell helper to
  read the next token from `tokens.txt` and rewrite the remainder back to
  disk. On Windows, `Get-Content` can return a scalar when the file has
  only one remaining line, so `$lines[0]` reads the first character
  instead of the full token. That breaks the external bearer refresh test
  once the token list is nearly exhausted.
  
  https://github.com/openai/codex/pull/16288 introduced similar changes to
  `codex-rs/core/src/models_manager/manager_tests.rs` and
  `codex-rs/core/tests/suite/client.rs`.
  
  These went unnoticed because the failures showed up when the test was
  run via Cargo on Windows, but not in our Bazel harness. Figuring out
  that Cargo-vs-Bazel delta will happen in a follow-up PR.
  
  ## Verification
  
  On my Windows machine, I verified `cargo test` passes when run in
  `codex-rs/login` and `codex-rs/core`. Once this PR is merged, I will
  keep an eye on
  https://github.com/openai/codex/actions/workflows/rust-ci-full.yml to
  verify it goes green.
  
  ## What changed
  
  - Wrap `Get-Content -Path tokens.txt` in `@(...)` so the script always
  gets array semantics before counting, indexing, and rewriting the
  remaining lines.

  Michael Bolin · 2026-03-31 14:44:54 -07:00
  04ec9ef8af
• [codex-analytics] thread events (#15690)

  - add event for thread initialization
  - thread/start, thread/fork, thread/resume
  - feature flagged behind `FeatureFlag::GeneralAnalytics`
  - does not yet support threads started by subagents
  
  PR stack:
  - --> [[telemetry] thread events
  #15690](https://github.com/openai/codex/pull/15690)
  - [[telemetry] subagent events
  #15915](https://github.com/openai/codex/pull/15915)
  - [[telemetry] turn events
  #15591](https://github.com/openai/codex/pull/15591)
  - [[telemetry] steer events
  #15697](https://github.com/openai/codex/pull/15697)
  - [[telemetry] queued prompt data
  #15804](https://github.com/openai/codex/pull/15804)
  
  
  Sample extracted logs in Codex-backend
  ```
  INFO     | 2026-03-29 16:39:37 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3bf7-9f5f-7f82-9877-6d48d1052531 product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=new subagent_source=None parent_thread_id=None created_at=1774827577 | 
  INFO     | 2026-03-29 16:45:46 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3b84-5731-79d0-9b3b-9c6efe5f5066 product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=resumed subagent_source=None parent_thread_id=None created_at=1774820022 | 
  INFO     | 2026-03-29 16:45:49 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3bfd-4cd6-7c12-a13e-48cef02e8c4d product_surface=codex product_client_id=CODEX_CLI client_name=codex-tui client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=forked subagent_source=None parent_thread_id=None created_at=1774827949 | 
  INFO     | 2026-03-29 17:20:29 | codex_backend.routers.analytics_events | analytics_events.track_analytics_events:398 | Tracked analytics event codex_thread_initialized thread_id=019d3c1d-0412-7ed2-ad24-c9c0881a36b0 product_surface=codex product_client_id=CODEX_SERVICE_EXEC client_name=codex_exec client_version=0.0.0 rpc_transport=in_process experimental_api_enabled=True codex_rs_version=0.0.0 runtime_os=macos runtime_os_version=26.4.0 runtime_arch=aarch64 model=gpt-5.3-codex ephemeral=False thread_source=user initialization_mode=new subagent_source=None parent_thread_id=None created_at=1774830027 | 
  ```
  
  Notes
  - `product_client_id` gets canonicalized in codex-backend
  - subagent threads are addressed in a following pr

  rhan-oai · 2026-03-31 12:16:44 -07:00
  e8de4ea953
• chore: drop interrupt from send_message (#16324)
  jif-oai · 2026-03-31 16:02:45 +02:00
  b09b58ce2d
• feat: restrict spawn_agent v2 to messages (#16325)
  jif-oai · 2026-03-31 14:52:55 +02:00
  285f4ea817
• fix: update fork boundaries computation (#16322)
  jif-oai · 2026-03-31 14:10:43 +02:00
  4c72e62d0b
• feat: fork pattern v2 (#15771)

  Adds this:
  ```
  properties.insert(
              "fork_turns".to_string(),
              JsonSchema::String {
                  description: Some(
                      "Optional MultiAgentV2 fork mode. Use `none`, `all`, or a positive integer string such as `3` to fork only the most recent turns."
                          .to_string(),
                  ),
              },
          );
          ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-03-31 13:06:08 +02:00
  1fc8aa0e16
• nit: update aborted line (#16318)
  jif-oai · 2026-03-31 13:06:00 +02:00
  2b8d29ac0d
• chore: clean wait v2 (#16317)
  jif-oai · 2026-03-31 12:18:10 +02:00
  ec21e1fd01
• fix: ma2 (#16238)
  jif-oai · 2026-03-31 11:22:38 +02:00
  25fbd7e40e
• fix: one shot end of turn (#16308)

  Fix the death of the end of turn watcher

  jif-oai · 2026-03-31 11:11:33 +02:00
  873e466549
• core: support dynamic auth tokens for model providers (#16288)

  ## Summary
  
  Fixes #15189.
  
  Custom model providers that set `requires_openai_auth = false` could
  only use static credentials via `env_key` or
  `experimental_bearer_token`. That is not enough for providers that mint
  short-lived bearer tokens, because Codex had no way to run a command to
  obtain a bearer token, cache it briefly in memory, and retry with a
  refreshed token after a `401`.
  
  This PR adds that provider config and wires it through the existing auth
  design: request paths still go through `AuthManager.auth()` and
  `UnauthorizedRecovery`, with `core` only choosing when to use a
  provider-backed bearer-only `AuthManager`.
  
  ## Scope
  
  To keep this PR reviewable, `/models` only uses provider auth for the
  initial request in this change. It does **not** add a dedicated `401`
  retry path for `/models`; that can be follow-up work if we still need it
  after landing the main provider-token support.
  
  ## Example Usage
  
  ```toml
  model_provider = "corp-openai"
  
  [model_providers.corp-openai]
  name = "Corp OpenAI"
  base_url = "https://gateway.example.com/openai"
  requires_openai_auth = false
  
  [model_providers.corp-openai.auth]
  command = "gcloud"
  args = ["auth", "print-access-token"]
  timeout_ms = 5000
  refresh_interval_ms = 300000
  ```
  
  The command contract is intentionally small:
  
  - write the bearer token to `stdout`
  - exit `0`
  - any leading or trailing whitespace is trimmed before the token is used
  
  ## What Changed
  
  - add `model_providers.<id>.auth` to the config model and generated
  schema
  - validate that command-backed provider auth is mutually exclusive with
  `env_key`, `experimental_bearer_token`, and `requires_openai_auth`
  - build a bearer-only `AuthManager` for `ModelClient` and
  `ModelsManager` when a provider configures `auth`
  - let normal Responses requests and realtime websocket connects use the
  provider-backed bearer source through the same `AuthManager.auth()` path
  - allow `/models` online refresh for command-auth providers and attach
  the provider token to the initial `/models` request
  - keep `auth.cwd` available as an advanced escape hatch and include it
  in the generated config schema
  
  ## Testing
  
  - `cargo test -p codex-core provider_auth_command`
  - `cargo test -p codex-core
  refresh_available_models_uses_provider_auth_token`
  - `cargo test -p codex-core
  test_deserialize_provider_auth_config_defaults`
  
  ## Docs
  
  - `developers.openai.com/codex` should document the new
  `[model_providers.<id>.auth]` block and the token-command contract

  Michael Bolin · 2026-03-31 01:37:27 -07:00
  20f43c1e05
• fix: close Bazel argument-comment-lint CI gaps (#16253)

  ## Why
  
  The Bazel-backed `argument-comment-lint` CI path had two gaps:
  
  - Bazel wildcard target expansion skipped inline unit-test crates from
  `src/` modules because the generated `*-unit-tests-bin` `rust_test`
  targets are tagged `manual`.
  - `argument-comment-mismatch` was still only a warning in the Bazel and
  packaged-wrapper entrypoints, so a typoed `/*param_name*/` comment could
  still pass CI even when the lint detected it.
  
  That left CI blind to real linux-sandbox examples, including the missing
  `/*local_port*/` comment in
  `codex-rs/linux-sandbox/src/proxy_routing.rs` and typoed argument
  comments in `codex-rs/linux-sandbox/src/landlock.rs`.
  
  ## What Changed
  
  - Added `tools/argument-comment-lint/list-bazel-targets.sh` so Bazel
  lint runs cover `//codex-rs/...` plus the manual `rust_test`
  `*-unit-tests-bin` targets.
  - Updated `just argument-comment-lint`, `rust-ci.yml`, and
  `rust-ci-full.yml` to use that helper.
  - Promoted both `argument-comment-mismatch` and
  `uncommented-anonymous-literal-argument` to errors in every strict
  entrypoint:
    - `tools/argument-comment-lint/lint_aspect.bzl`
    - `tools/argument-comment-lint/src/bin/argument-comment-lint.rs`
    - `tools/argument-comment-lint/wrapper_common.py`
  - Added wrapper/bin coverage for the stricter lint flags and documented
  the behavior in `tools/argument-comment-lint/README.md`.
  - Fixed the now-covered callsites in
  `codex-rs/linux-sandbox/src/proxy_routing.rs`,
  `codex-rs/linux-sandbox/src/landlock.rs`, and
  `codex-rs/core/src/shell_snapshot_tests.rs`.
  
  This keeps the Bazel target expansion narrow while making the Bazel and
  prebuilt-linter paths enforce the same strict lint set.
  
  ## Verification
  
  - `python3 -m unittest discover -s tools/argument-comment-lint -p
  'test_*.py'`
  - `cargo +nightly-2025-09-18 test --manifest-path
  tools/argument-comment-lint/Cargo.toml`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-30 11:59:50 -07:00
  9313c49e4c
• codex-tools: extract discoverable tool models (#16254)

  ## Why
  
  `#16193` moved the pure `tool_search` and `tool_suggest` spec builders
  into `codex-tools`, but `codex-core` still owned the shared
  discoverable-tool model that those builders and the `tool_suggest`
  runtime both depend on. This change continues the migration by moving
  that reusable model boundary out of `codex-core` as well, so the
  discovery/suggestion stack uses one shared set of types and
  `core/src/tools` no longer needs its own `discoverable.rs` module.
  
  ## What changed
  
  - Moved `DiscoverableTool`, `DiscoverablePluginInfo`, and
  `filter_tool_suggest_discoverable_tools_for_client()` into
  `codex-rs/tools/src/tool_discovery.rs` alongside the extracted
  discovery/suggestion spec builders.
  - Added `codex-app-server-protocol` as a `codex-tools` dependency so the
  shared discoverable-tool model can own the connector-side `AppInfo`
  variant directly.
  - Updated `core/src/tools/handlers/tool_suggest.rs`,
  `core/src/tools/spec.rs`, `core/src/tools/router.rs`,
  `core/src/connectors.rs`, and `core/src/codex.rs` to consume the shared
  `codex-tools` model instead of the old core-local declarations.
  - Changed `core/src/plugins/discoverable.rs` to return
  `DiscoverablePluginInfo` directly, moved the pure client-filter coverage
  into `tool_discovery_tests.rs`, and deleted the old
  `core/src/tools/discoverable.rs` module.
  - Updated `codex-rs/tools/README.md` so the crate boundary documents
  that `codex-tools` now owns the discoverable-tool models in addition to
  the discovery/suggestion spec builders.
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discoverable-model cargo test -p
  codex-core --lib tools::handlers::tool_suggest::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discoverable-model cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discoverable-model cargo test -p
  codex-core --lib plugins::discoverable::`
  - `just bazel-lock-check`
  - `just argument-comment-lint`
  
  ## References
  
  - #16193
  - #16154
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138
  - #16141

  Michael Bolin · 2026-03-30 10:48:49 -07:00
  258ba436f1
• codex-tools: extract discovery tool specs (#16193)

  ## Why
  
  `core/src/tools/spec.rs` still owned the pure `tool_search` and
  `tool_suggest` spec builders even though that logic no longer needed
  `codex-core` runtime state. This change continues the `codex-tools`
  migration by moving the reusable discovery and suggestion spec
  construction out of `codex-core` so `spec.rs` is left with the
  core-owned policy decisions about when these tools are exposed and what
  metadata is available.
  
  ## What changed
  
  - Added `codex-rs/tools/src/tool_discovery.rs` with the shared
  `tool_search` and `tool_suggest` spec builders, plus focused unit tests
  in `tool_discovery_tests.rs`.
  - Moved the shared `DiscoverableToolAction` and `DiscoverableToolType`
  declarations into `codex-tools` so the `tool_suggest` handler and the
  extracted spec builders use the same wire-model enums.
  - Updated `core/src/tools/spec.rs` to translate `ToolInfo` and
  `DiscoverableTool` values into neutral `codex-tools` inputs and delegate
  the actual spec building there.
  - Removed the old template-based description rendering helpers from
  `core/src/tools/spec.rs` and deleted the now-dead helper methods in
  `core/src/tools/discoverable.rs`.
  - Updated `codex-rs/tools/README.md` to document that discovery and
  suggestion models/spec builders now live in `codex-tools`.
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discovery-specs cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-discovery-specs cargo test -p
  codex-core --lib tools::handlers::tool_suggest::`
  - `just argument-comment-lint`
  
  ## References
  
  - #16154
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138
  - #16141

  Michael Bolin · 2026-03-30 08:15:12 -07:00
  716f7b0428
• fix: ma1 (#16237)
  jif-oai · 2026-03-30 15:42:17 +02:00
  c74190a622
• feat: add mailbox concept for wait (#16010)

  Add a mailbox we can use for inter-agent communication
  `wait` is now based on it and don't take target anymore

  jif-oai · 2026-03-30 11:47:20 +02:00
  213756c9ab
• codex-tools: extract utility tool specs (#16154)

  ## Why
  
  The previous `codex-tools` migration steps moved the shared schema
  models, local-host specs, collaboration specs, and related adapters out
  of `codex-core`, but `core/src/tools/spec.rs` still contained a grab bag
  of pure utility tool builders. Those specs do not need session state or
  handler logic; they only describe wire shapes for tools that
  `codex-core` already knows how to execute.
  
  Moving that remaining low-coupling layer into `codex-tools` keeps the
  migration moving in meaningful chunks and trims another large block of
  passive tool-spec construction out of `codex-core` without touching the
  runtime-coupled handlers.
  
  ## What changed
  
  - extended `codex-tools` to own the pure spec builders for:
    - code-mode `exec` / `wait`
    - `js_repl` / `js_repl_reset`
  - MCP resource tools `list_mcp_resources`,
  `list_mcp_resource_templates`, and `read_mcp_resource`
    - utility tools `list_dir` and `test_sync_tool`
  - split those builders across small module files with sibling
  `*_tests.rs` coverage, keeping `src/lib.rs` exports-only
  - rewired `core/src/tools/spec.rs` to call the extracted builders and
  deleted the duplicated core-local implementations
  - moved the direct JS REPL grammar seam test out of
  `core/src/tools/spec_tests.rs` so it now lives with the extracted
  implementation in `codex-tools`
  - updated `codex-rs/tools/README.md` so the documented crate boundary
  matches the new utility-spec surface
  
  ## Test plan
  
  - `CARGO_TARGET_DIR=/tmp/codex-tools-utility-specs cargo test -p
  codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-utility-specs cargo test -p
  codex-core --lib tools::spec::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138
  - #16141

  Michael Bolin · 2026-03-29 14:34:36 -07:00
  af568afdd5
• codex-tools: extract collaboration tool specs (#16141)

  ## Why
  
  The recent `codex-tools` migration steps have moved shared tool models
  and low-coupling spec helpers out of `codex-core`, but
  `core/src/tools/spec.rs` still owned a large block of pure
  collaboration-tool spec construction. Those builders do not need session
  state or runtime behavior; they only need a small amount of core-owned
  configuration injected at the seam.
  
  Moving that cohesive slice into `codex-tools` makes the crate boundary
  more honest and removes a substantial amount of passive tool-spec logic
  from `codex-core` without trying to move the runtime-coupled multi-agent
  handlers at the same time.
  
  ## What changed
  
  - added `agent_tool.rs`, `request_user_input_tool.rs`, and
  `agent_job_tool.rs` to `codex-tools`, with sibling `*_tests.rs` coverage
  and an exports-only `lib.rs`
  - moved the pure `ToolSpec` builders for:
  - collaboration tools such as `spawn_agent`, `send_input`,
  `send_message`, `assign_task`, `resume_agent`, `wait_agent`,
  `list_agents`, and `close_agent`
    - `request_user_input`
    - agent-job specs `spawn_agents_on_csv` and `report_agent_job_result`
  - rewired `core/src/tools/spec.rs` to call the extracted builders while
  still supplying the core-owned inputs, such as spawn-agent role
  descriptions and wait timeout bounds
  - updated the `core/src/tools/spec.rs` seam tests to build expected
  collaboration specs through `codex-tools`
  - updated `codex-rs/tools/README.md` so the crate documentation reflects
  the broader collaboration-tool boundary
  
  ## Test plan
  
  - `CARGO_TARGET_DIR=/tmp/codex-tools-collab-specs cargo test -p
  codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-collab-specs cargo test -p
  codex-core --lib tools::spec::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132
  - #16138

  Michael Bolin · 2026-03-28 20:39:47 -07:00
  7880414a27
• [mcp] Increase MCP startup timeout. (#16080)

  - [x] Increase MCP startup timeout to 30s, as the current 10s causes a
  lot of local MCPs to timeout.

  Matthew Zeng · 2026-03-28 19:58:00 -07:00
  3807807f91
• codex-tools: extract local host tool specs (#16138)

  ## Why
  
  `core/src/tools/spec.rs` still bundled a set of pure local-host tool
  builders with the orchestration that actually decides when those tools
  are exposed and which handlers back them. That made `codex-core`
  responsible for JSON/tool-shape construction that does not depend on
  session state, and it kept the `codex-tools` migration from taking a
  meaningfully larger bite out of `spec.rs`.
  
  This PR moves that reusable spec-building layer into `codex-tools` while
  leaving feature gating, handler registration, and runtime-coupled
  descriptions in `codex-core`.
  
  ## What changed
  
  - added `codex-rs/tools/src/local_tool.rs` for the pure builders for
  `exec_command`, `write_stdin`, `shell`, `shell_command`, and
  `request_permissions`
  - added `codex-rs/tools/src/view_image.rs` for the `view_image` tool
  spec and output schema so the extracted modules stay right-sized
  - rewired `codex-rs/core/src/tools/spec.rs` to call those extracted
  builders instead of constructing these specs inline
  - kept the `request_permissions` description source in `codex-core`,
  with `codex-tools` taking the description as input so the crate boundary
  does not grow a dependency on handler/runtime code
  - moved the direct constructor coverage for this slice from
  `codex-rs/core/src/tools/spec_tests.rs` into
  `codex-rs/tools/src/local_tool_tests.rs` and
  `codex-rs/tools/src/view_image_tests.rs`
  - updated `codex-rs/tools/README.md` to reflect that `codex-tools` now
  owns this local-host spec layer
  
  ## Test plan
  
  - `CARGO_TARGET_DIR=/tmp/codex-tools-local-host cargo test -p
  codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-local-tools cargo test -p codex-core
  --lib tools::spec::`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129
  - #16132

  Michael Bolin · 2026-03-28 16:33:58 -07:00
  4e119a3b38
• codex-tools: extract code mode tool spec adapters (#16132)

  ## Why
  
  The longer-term `codex-tools` migration is to move pure tool-definition
  and tool-spec plumbing out of `codex-core` while leaving session- and
  runtime-coupled orchestration behind.
  
  The remaining code-mode adapter layer in
  `core/src/tools/code_mode_description.rs` was a good next extraction
  seam because it only transformed `ToolSpec` values for code mode and
  already delegated the low-level description rendering to
  `codex-code-mode`.
  
  ## What Changed
  
  - added `codex-rs/tools/src/code_mode.rs` with
  `augment_tool_spec_for_code_mode()` and
  `tool_spec_to_code_mode_tool_definition()`
  - added focused unit coverage in `codex-rs/tools/src/code_mode_tests.rs`
  - rewired `core/src/tools/spec.rs` and `core/src/tools/code_mode/mod.rs`
  to use the extracted adapters from `codex-tools`
  - removed the old `core/src/tools/code_mode_description.rs` shim and its
  test file from `codex-core`
  - added the `codex-code-mode` dependency to `codex-tools`, updated
  `Cargo.lock`, and refreshed the `codex-tools` README to reflect the
  expanded boundary
  
  ## Test Plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-code-mode-adapters cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-code-mode-adapters cargo test -p
  codex-core --lib tools::code_mode::`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047
  - #16129

  Michael Bolin · 2026-03-28 15:32:35 -07:00
  2238c16a91
• core: fix stale curated plugin cache refresh races (#16126)

  ## Why
  
  The `plugin/list` force-sync path can race app-server startup's curated
  plugin cache refresh.
  
  Startup was capturing the configured curated plugin IDs from the initial
  config snapshot. If `plugin/list` with `forceRemoteSync` removed curated
  plugin entries from `config.toml` while that background refresh was
  still in flight, the startup task could recreate cache directories for
  plugins that had just been uninstalled.
  
  That leaves the `plugin/list` response logically correct but the on-disk
  cache stale, which matches the flaky Ubuntu arm failure seen in
  `codex-app-server::all
  suite::v2::plugin_list::plugin_list_force_remote_sync_reconciles_curated_plugin_state`
  while validating [#16047](https://github.com/openai/codex/pull/16047).
  
  ## What
  
  - change `codex-rs/core/src/plugins/manager.rs` so startup curated-repo
  refresh rereads the current user `config.toml` before deciding which
  curated plugin cache entries to refresh
  - factor the configured-plugin parsing so the same logic can be reused
  from either the config layer stack or the persisted user config value
  - add a regression test that verifies curated plugin IDs are read from
  the latest user config state before cache refresh runs
  
  ## Testing
  
  - `cargo test -p codex-core
  configured_curated_plugin_ids_from_codex_home_reads_latest_user_config
  -- --nocapture`
  - `cargo test -p codex-app-server
  suite::v2::plugin_list::plugin_list_force_remote_sync_reconciles_curated_plugin_state
  -- --nocapture`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-28 15:00:39 -07:00
  c25c0d6e9e
• codex-tools: extract configured tool specs (#16129)

  ## Why
  
  This continues the `codex-tools` migration by moving another passive
  tool-spec layer out of `codex-core`.
  
  After `ToolSpec` moved into `codex-tools`, `codex-core` still owned
  `ConfiguredToolSpec` and `create_tools_json_for_responses_api()`. Both
  are data-model and serialization helpers rather than runtime
  orchestration, so keeping them in `core/src/tools/registry.rs` and
  `core/src/tools/spec.rs` left passive tool-definition code coupled to
  `codex-core` longer than necessary.
  
  ## What changed
  
  - moved `ConfiguredToolSpec` into `codex-rs/tools/src/tool_spec.rs`
  - moved `create_tools_json_for_responses_api()` into
  `codex-rs/tools/src/tool_spec.rs`
  - re-exported the new surface from `codex-rs/tools/src/lib.rs`, which
  remains exports-only
  - updated `core/src/client.rs`, `core/src/tools/registry.rs`, and
  `core/src/tools/router.rs` to consume the extracted types and serializer
  from `codex-tools`
  - moved the tool-list serialization test into
  `codex-rs/tools/src/tool_spec_tests.rs`
  - added focused unit coverage for `ConfiguredToolSpec::name()`
  - simplified `core/src/tools/spec_tests.rs` to use the extracted
  `ConfiguredToolSpec::name()` directly and removed the now-redundant
  local `tool_name()` helper
  - updated `codex-rs/tools/README.md` so the crate boundary reflects the
  newly extracted tool-spec wrapper and serialization helper
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `CARGO_TARGET_DIR=/tmp/codex-core-configured-spec cargo test -p
  codex-core --lib tools::spec::`
  - `CARGO_TARGET_DIR=/tmp/codex-core-configured-spec cargo test -p
  codex-core --lib client::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031
  - #16047

  Michael Bolin · 2026-03-28 14:24:14 -07:00
  4e27a87ec6
• codex-tools: extract tool spec models (#16047)

  ## Why
  
  This continues the `codex-tools` migration by moving another passive
  tool-definition layer out of `codex-core`.
  
  After `ResponsesApiTool` and the lower-level schema adapters moved into
  `codex-tools`, `core/src/client_common.rs` was still owning `ToolSpec`
  and the web-search request wire types even though they are serialized
  data models rather than runtime orchestration. Keeping those types in
  `codex-core` makes the crate boundary look smaller than it really is and
  leaves non-runtime tool-shape code coupled to core.
  
  ## What changed
  
  - moved `ToolSpec`, `ResponsesApiWebSearchFilters`, and
  `ResponsesApiWebSearchUserLocation` into
  `codex-rs/tools/src/tool_spec.rs`
  - added focused unit tests in `codex-rs/tools/src/tool_spec_tests.rs`
  for:
    - `ToolSpec::name()`
    - web-search config conversions
    - `ToolSpec` serialization for `web_search` and `tool_search`
  - kept `codex-rs/tools/src/lib.rs` exports-only by re-exporting the new
  module from `lib.rs`
  - reduced `core/src/client_common.rs` to a compatibility shim that
  re-exports the extracted tool-spec types for current core call sites
  - updated `core/src/tools/spec_tests.rs` to consume the extracted
  web-search types directly from `codex-tools`
  - updated `codex-rs/tools/README.md` so the crate contract reflects that
  `codex-tools` now owns the passive tool-spec request models in addition
  to the lower-level Responses API structs
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`
  - `cargo test -p codex-core --lib client_common::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - #15923
  - #15928
  - #15944
  - #15953
  - #16031

  Michael Bolin · 2026-03-28 13:37:00 -07:00
  bc53d42fd9
• Remove remaining custom prompt support (#16115)

  ## Summary
  - remove protocol and core support for discovering and listing custom
  prompts
  - simplify the TUI slash-command flow and command popup to built-in
  commands only
  - delete obsolete custom prompt tests, helpers, and docs references
  - clean up downstream event handling for the removed protocol events

  Eric Traut · 2026-03-28 13:49:37 -06:00
  48144a7fa4
• chore: clean up argument-comment lint and roll out all-target CI on macOS (#16054)

  ## Why
  
  `argument-comment-lint` was green in CI even though the repo still had
  many uncommented literal arguments. The main gap was target coverage:
  the repo wrapper did not force Cargo to inspect test-only call sites, so
  examples like the `latest_session_lookup_params(true, ...)` tests in
  `codex-rs/tui_app_server/src/lib.rs` never entered the blocking CI path.
  
  This change cleans up the existing backlog, makes the default repo lint
  path cover all Cargo targets, and starts rolling that stricter CI
  enforcement out on the platform where it is currently validated.
  
  ## What changed
  
  - mechanically fixed existing `argument-comment-lint` violations across
  the `codex-rs` workspace, including tests, examples, and benches
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` and
  `tools/argument-comment-lint/run.sh` so non-`--fix` runs default to
  `--all-targets` unless the caller explicitly narrows the target set
  - fixed both wrappers so forwarded cargo arguments after `--` are
  preserved with a single separator
  - documented the new default behavior in
  `tools/argument-comment-lint/README.md`
  - updated `rust-ci` so the macOS lint lane keeps the plain wrapper
  invocation and therefore enforces `--all-targets`, while Linux and
  Windows temporarily pass `-- --lib --bins`
  
  That temporary CI split keeps the stricter all-targets check where it is
  already cleaned up, while leaving room to finish the remaining Linux-
  and Windows-specific target-gated cleanup before enabling
  `--all-targets` on those runners. The Linux and Windows failures on the
  intermediate revision were caused by the wrapper forwarding bug, not by
  additional lint findings in those lanes.
  
  ## Validation
  
  - `bash -n tools/argument-comment-lint/run.sh`
  - `bash -n tools/argument-comment-lint/run-prebuilt-linter.sh`
  - shell-level wrapper forwarding check for `-- --lib --bins`
  - shell-level wrapper forwarding check for `-- --tests`
  - `just argument-comment-lint`
  - `cargo test` in `tools/argument-comment-lint`
  - `cargo test -p codex-terminal-detection`
  
  ## Follow-up
  
  - Clean up remaining Linux-only target-gated callsites, then switch the
  Linux lint lane back to the plain wrapper invocation.
  - Clean up remaining Windows-only target-gated callsites, then switch
  the Windows lint lane back to the plain wrapper invocation.

  Michael Bolin · 2026-03-27 19:00:44 -07:00
  61dfe0b86c
• Remove the legacy TUI split (#15922)

  This is the part 1 of 2 PRs that will delete the `tui` /
  `tui_app_server` split. This part simply deletes the existing `tui`
  directory and marks the `tui_app_server` feature flag as removed. I left
  the `tui_app_server` feature flag in place for now so its presence
  doesn't result in an error. It is simply ignored.
  
  Part 2 will rename the `tui_app_server` directory `tui`. I did this as
  two parts to reduce visible code churn.

  Eric Traut · 2026-03-27 22:56:44 +00:00
  d65deec617
• don't include redundant write roots in apply_patch (#16030)

  apply_patch sometimes provides additional parent dir as a writable root
  when it is already writable. This is mostly a no-op on Mac/Linux but
  causes actual ACL churn on Windows that is best avoided. We are also
  seeing some actual failures with these ACLs in the wild, which I haven't
  fully tracked down, but it's safe/best to avoid doing it altogether.

  iceweasel-oai · 2026-03-27 15:41:51 -07:00
  307e427a9b
• [mcp] Bypass read-only tool checks. (#16044)

  - [x] Auto / unspecified approval mode: read-only tools now skip before
  guardian routing.
  - [x] Approve / always-allow mode: read-only tools still skip, now via
  the shared early return.
  - [x] Prompt mode: read-only tools no longer skip; they continue to
  approval.

  Matthew Zeng · 2026-03-27 15:22:04 -07:00
  5b71e5104f
• codex-tools: extract responses API tool models (#16031)

  ## Why
  
  The previous extraction steps moved shared tool-schema parsing into
  `codex-tools`, but `codex-core` still owned the generic Responses API
  tool models and the last adapter layer that turned parsed tool
  definitions into `ResponsesApiTool` values.
  
  That left `core/src/tools/spec.rs` and `core/src/client_common.rs`
  holding a chunk of tool-shaping code that does not need session state,
  runtime plumbing, or any other `codex-core`-specific dependency. As a
  result, `codex-tools` owned the parsed tool definition, but `codex-core`
  still owned the generic wire model that those definitions are converted
  into.
  
  This change moves that boundary one step further. `codex-tools` now owns
  the reusable Responses/tool wire structs and the shared conversion
  helpers for dynamic tools, MCP tools, and deferred MCP aliases.
  `codex-core` continues to own `ToolSpec` orchestration and the remaining
  web-search-specific request shapes.
  
  ## What changed
  
  - added `tools/src/responses_api.rs` to own `ResponsesApiTool`,
  `FreeformTool`, `ToolSearchOutputTool`, namespace output types, and the
  shared `ToolDefinition -> ResponsesApiTool` adapter helpers
  - added `tools/src/responses_api_tests.rs` for deferred-loading
  behavior, adapter coverage, and namespace serialization coverage
  - rewired `core/src/tools/spec.rs` to use the extracted dynamic/MCP
  adapter helpers instead of defining those conversions locally
  - rewired `core/src/tools/handlers/tool_search.rs` to use the extracted
  deferred MCP adapter and namespace output types directly
  - slimmed `core/src/client_common.rs` so it now keeps `ToolSpec` and the
  web-search-specific wire types, while reusing the extracted tool models
  from `codex-tools`
  - moved the extracted seam tests out of `core` and updated
  `codex-rs/tools/README.md` plus `tools/src/lib.rs` to reflect the
  expanded `codex-tools` boundary
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`
  - `cargo test -p codex-core --lib tools::handlers::tool_search::`
  - `just fix -p codex-tools -p codex-core`
  - `just argument-comment-lint`
  
  ## References
  
  - [#15923](https://github.com/openai/codex/pull/15923) `codex-tools:
  extract shared tool schema parsing`
  - [#15928](https://github.com/openai/codex/pull/15928) `codex-tools:
  extract MCP schema adapters`
  - [#15944](https://github.com/openai/codex/pull/15944) `codex-tools:
  extract dynamic tool adapters`
  - [#15953](https://github.com/openai/codex/pull/15953) `codex-tools:
  introduce named tool definitions`

  Michael Bolin · 2026-03-27 14:26:54 -07:00
  16d4ea9ca8
• Add usage-based business plan types (#15934)

  ## Summary
  - add `self_serve_business_usage_based` and `enterprise_cbp_usage_based`
  to the public/internal plan enums and regenerate the app-server + Python
  SDK artifacts
  - map both plans through JWT login and backend rate-limit payloads, then
  bucket them with the existing Team/Business entitlement behavior in
  cloud requirements, usage-limit copy, tooltips, and status display
  - keep the earlier display-label remap commit on this branch so the new
  Team-like and Business-like plans render consistently in the UI
  
  ## Testing
  - `just write-app-server-schema`
  - `uv run --project sdk/python python
  sdk/python/scripts/update_sdk_artifacts.py generate-types`
  - `just fix -p codex-protocol -p codex-login -p codex-core -p
  codex-backend-client -p codex-cloud-requirements -p codex-tui -p
  codex-tui-app-server -p codex-backend-openapi-models`
  - `just fmt`
  - `just argument-comment-lint`
  - `cargo test -p codex-protocol
  usage_based_plan_types_use_expected_wire_names`
  - `cargo test -p codex-login usage_based`
  - `cargo test -p codex-backend-client usage_based`
  - `cargo test -p codex-cloud-requirements usage_based`
  - `cargo test -p codex-core usage_limit_reached_error_formats_`
  - `cargo test -p codex-tui plan_type_display_name_remaps_display_labels`
  - `cargo test -p codex-tui remapped`
  - `cargo test -p codex-tui-app-server
  plan_type_display_name_remaps_display_labels`
  - `cargo test -p codex-tui-app-server remapped`
  - `cargo test -p codex-tui-app-server
  preserves_usage_based_plan_type_wire_name`
  
  ## Notes
  - a broader multi-crate `cargo test` run still hits unrelated existing
  guardian-approval config failures in
  `codex-rs/core/src/config/config_tests.rs`

  bwanner-oai · 2026-03-27 14:25:13 -07:00
  82e8031338
• plugins: Clean up stale curated plugin sync temp dirs and add sync metrics (#16035)

  1. Keep curated plugin staging directories under TempDir ownership until
  activation succeeds, so failed git/HTTP sync attempts do not leak
  plugins-clone-*.
  2. Best-effort clean up stale plugins-clone-* directories before
  creating a new staged repo, using a conservative age threshold.
  3. Emit OTEL counters for curated plugin startup sync transport attempts
  and final outcome across git and HTTP paths.

  xl-openai · 2026-03-27 14:21:18 -07:00
  81abb44f68
• Normalize /mcp tool grouping for hyphenated server names (#15946)

  Fix display for servers with special characters.

  pakrym-oai · 2026-03-27 14:58:29 -06:00
  8002594ee3
• fix: fix Windows CI regression introduced in #15999 (#16027)

  #15999 introduced a Windows-only `\r\n` mismatch in review-exit template
  handling. This PR normalizes those template newlines and separates that
  fix from [#16014](https://github.com/openai/codex/pull/16014) so it can
  be reviewed independently.

  Michael Bolin · 2026-03-27 12:06:07 -07:00
  15fbf9d4f5