32 Commits

• [connectors] Ignore synthetic links for app accessibility (#28770)

  Summary
  - Stop treating Codex Apps MCP tools with
  `_meta._codex_apps.synthetic_link: true` as evidence that a connector is
  accessible in `app/list`.
  - Preserve synthetic tools in the agent-facing MCP connector set so they
  remain available for install/auth flows.
  - Keep the app-list accessibility cache limited to connectors backed by
  at least one non-synthetic tool.
  - Add focused regression coverage for both sides of the boundary.
  
  Validation
  - `just fmt`
  - `just test -p codex-core
  synthetic_links_are_exposed_to_the_agent_but_not_accessible_in_app_list`
  - `git diff --check`
  - A crate-wide `just test -p codex-core` run completed with 2,699
  passing and 51 unrelated local sandbox/state failures, primarily state
  DB migration races (`UNIQUE constraint failed:
  _sqlx_migrations.version`).

  Alex Daley · 2026-06-18 17:19:24 -04:00
  4af7762f01
• [codex] Reuse Apps policy evaluation across MCP tool exposure (#27813)

  ## Summary
  
  - move `AppToolPolicyEvaluator` and the Apps config/requirements policy
  logic from `codex-core` into `codex-connectors`
  - resolve one immutable policy snapshot per exposure build and reuse it
  across every Codex Apps MCP tool
  - keep core as a thin adapter from MCP metadata to connector-owned
  policy input while preserving the call-time defense-in-depth check
  
  ## Why
  
  `build_mcp_tool_exposure` evaluates every Codex Apps tool on each
  sampling request. The old path rebuilt effective Apps configuration for
  every tool, and the policy implementation lived in the already-large
  core crate even though it is connector-specific.
  
  The connector-owned evaluator keeps the expensive config merge/decode
  out of the loop and gives core only the effective policy result it
  needs.
  
  ## Performance
  
  With the real 557-tool Apps corpus, `build_mcp_tool_exposure` measured
  3.74 ms and 3.33 ms after the extraction (3.54 ms mean). The original
  path measured 807 ms mean, so the final result retains the 99.6%
  reduction.
  
  ## Validation
  
  - `cargo check -p codex-connectors -p codex-core`
  - `just test -p codex-connectors` — 15 passed
  - `just test -p codex-core --lib connectors` — 35 passed
  - `just test -p codex-core --lib mcp_tool_exposure` — 5 passed
  - `just test -p codex-core --lib mcp_tool_call` — 72 passed
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fix -p codex-connectors`
  - `just fix -p codex-core`
  - `just fmt`

  Matthew Zeng · 2026-06-15 15:24:33 -07:00
  1fbaac1e50
• [ez][codex-rs] Support approvals reviewer in app defaults (#27075)

  [from codex]
  
  ## Summary
  
  - add `approvals_reviewer` support to `[apps._default]`
  - resolve connected-app reviewers in per-app, app-default, then global
  order
  - expose the setting through the v2 config API and regenerate schema
  fixtures
  
  ## Context
  
  PR #25167 added `apps.<connector_id>.approvals_reviewer`, but the shared
  app defaults table could not specify the reviewer. This extends the same
  behavior to `[apps._default]` while preserving per-app overrides.
  
  Managed `allowed_approvals_reviewers` requirements still constrain both
  default and per-app values. A disallowed app value falls back to the
  global reviewer, and non-app MCP servers continue using the global
  reviewer.
  
  ## Testing
  
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `just fmt`
  - `just test -p codex-config`
  - `just test -p codex-core app_approvals_reviewer`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server config_read_includes_apps`

  Alex Zamoshchin · 2026-06-12 09:06:58 -07:00
  3cac2e0d3f
• Switch runtime to cloud config bundle (#24622)

  ## Summary
  
  - Adapts the moved `codex-cloud-config` crate from the legacy cloud
  requirements endpoint to the new config bundle endpoint.
  - Switches runtime consumers from `CloudRequirementsLoader` to
  `CloudConfigBundleLoader` so one shared bundle supplies cloud-delivered
  config and requirements.
  - Removes the legacy cloud requirements domain loader path.
  
  ## Details
  
  This intentionally keeps `codex-cloud-config` monolithic for review
  lineage: the previous PR establishes the crate move, and this PR shows
  the behavior change against that moved implementation. A follow-up PR
  splits the module back into focused files.
  
  The new bundle path preserves the important cloud requirements loader
  semantics where intended: account-scoped signed cache, 30 minute TTL, 5
  minute refresh cadence, retry/backoff, auth recovery, and fail-closed
  startup loading. The cached payload changes from a single requirements
  TOML string to the backend-delivered bundle, and validation rejects
  malformed config or requirements fragments before cache write/use.

  joeflorencio-openai · 2026-06-02 13:18:59 -07:00
  d45cd26248
• [app-server][core] Add connector-level Guardian reviewer overrides (#25167)

  Context: https://openai.slack.com/archives/C0B4JAF0Q2C/p1779912328647229
  
  ```
  approvals_reviewer = "auto_review"
  
  [apps.connector_5f3c8c41a1e54ad7a76272c89e2554fa]
  enabled = true
  approvals_reviewer = "user"
  default_tools_approval_mode = "prompt"
  ```
  
  <img width="230" height="84" alt="Screenshot 2026-05-31 at 11 56 34 AM"
  src="https://github.com/user-attachments/assets/e319f8f7-0983-42a7-98cd-3302732fa406"
  />
  
  <img width="841" height="233" alt="Screenshot 2026-05-31 at 11 52 42 AM"
  src="https://github.com/user-attachments/assets/7ac76645-4e90-4d00-8242-f031146a22a5"
  />
  
  -------
  
  ```
  approvals_reviewer = "user"
  
  [apps.connector_5f3c8c41a1e54ad7a76272c89e2554fa]
  enabled = true
  approvals_reviewer = "auto_review"
  default_tools_approval_mode = "prompt"
  ```
  <img width="195" height="83" alt="Screenshot 2026-05-31 at 12 02 27 PM"
  src="https://github.com/user-attachments/assets/3d374dc8-8aa2-466f-a13f-e4ed8567aa2e"
  />
  <img width="771" height="207" alt="Screenshot 2026-05-31 at 12 05 42 PM"
  src="https://github.com/user-attachments/assets/105c2575-68d6-4ca6-8e69-dc8c82da36a2"
  />
  
  
  
  ## Summary
  - add `apps.<connector_id>.approvals_reviewer` to override Guardian or
  user review routing per connected app
  - apply overrides across direct app MCP calls, delegated MCP prompts,
  and app-server MCP elicitation review while preserving global behavior
  for non-app MCP servers
  - expose and document the config through app-server v2 and generated
  schemas, while honoring global managed reviewer requirements
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Alex Zamoshchin · 2026-06-02 17:04:11 +02:00
  4d80d808b4
• [codex] Cache remote plugin catalog for suggestions (#25457)

  ## Summary
  - cache the global remote plugin catalog when remote plugin listing runs
  and warm it during startup
  - use the cached remote catalog in plugin install recommendations with
  canonical `plugin@openai-curated-remote` ids
  - reuse the session `PluginsManager` for plugin recommendations so
  remote cache state is visible on the recommend path
  - skip core installed-state verification for remote plugin install
  suggestions while leaving local plugin and connector verification
  unchanged
  
  ## Testing
  - `just fmt`
  - `git diff --check`
  - `cargo test -p codex-core
  list_tool_suggest_discoverable_plugins_includes_cached_remote_global_plugins`
  - `cargo test -p codex-core
  remote_plugin_install_suggestions_skip_core_installed_verification`
  - `cargo test -p codex-app-server
  plugin_list_includes_remote_marketplaces_when_remote_plugin_enabled`
  
  Earlier focused checks during the same branch: codex-tools TUI filter
  test, request_plugin_install tests, and codex-app-server build.

  xl-openai · 2026-06-01 22:10:52 -07:00
  f2b725102b
• [codex] Update remote connector suggestions (#25172)

  ## Summary
  
  - Use the session-loaded plugin app IDs as the source of connector
  suggestion candidates.
  - Remove the redundant plugin reload from
  `tool_suggest_connector_ids()`.
  - Add regression coverage for connectors declared by a loaded remote
  plugin, using the Databricks app case.
  
  ## Context
  
  Loaded remote plugins can declare app connector IDs in `.app.json`. The
  session-owned `PluginsManager` already loads those plugins and exposes
  their effective app IDs.
  
  The connector suggestion path was creating a separate `PluginsManager`
  and recomputing plugin app IDs. That new manager does not share the
  session manager’s remote installed plugin cache, so app IDs from loaded
  remote plugins were missing from connector suggestions.
  
  ## Fix
  
  Pass the already-loaded effective app IDs into connector suggestion
  generation and use them directly as the plugin-derived connector
  candidate set.
  
  Connector candidates are now built from:
  
  - App IDs declared by loaded plugins
  - Explicitly configured connector discoverables
  - Existing disabled-suggestion filtering
  
  This avoids a second plugin-manager lookup and keeps connector
  suggestions aligned with the plugins actually loaded for the turn.
  
  ## Behavior
  
  For example, when a plugin is loaded and its `.app.json` declares data
  apps, `list_available_plugins_to_install` can now return those data
  connectors.
  
  This does not create plugin suggestions from the plugin itself. Plugin
  suggestions still come from eligible uninstalled entries in the
  marketplace catalog and require existing matching/filtering rules.
  
  ## Validation
  
  - `just fmt`
  - Added regression coverage for a loaded-plugin connector ID appearing
  in discoverable tools
  - Attempted `just test -p codex-core`; the command exited unsuccessfully
  in the local test environment without useful failure detail captured in
  the run output

  Eric Ning · 2026-05-29 17:57:34 -07:00
  e929bb5c88
• Filter plugin install suggestions by installed apps (#24996)

  ## Summary
  
  - Keep the original `TOOL_SUGGEST_DISCOVERABLE_PLUGIN_ALLOWLIST` as a
  fallback seed list, so users with no installed plugins still get initial
  install suggestions.
  - Allow additional install suggestions from trusted marketplaces:
  `openai-curated` and `openai-bundled`.
  - Require non-fallback, non-configured marketplace candidates to share
  `.app.json` connector IDs with already installed plugins.
  - Preserve explicit configured plugin discoverables as an override,
  while still omitting installed, disabled, and `NOT_AVAILABLE` plugins.
  
  ## Context
  
  `list_available_plugins_to_install` controls which plugins the model can
  trigger via `request_plugin_install`. We want a small starter set for
  empty/new users, but we also want installed workflow plugins to unlock
  relevant source plugins without maintaining every source plugin ID by
  hand.
  
  This keeps the legacy plugin ID allowlist only as the starter fallback.
  For everything else, the trusted marketplace is the candidate boundary,
  and installed app connector overlap is the relevance filter. For
  example, an installed Sales plugin can make HubSpot and Granola
  suggestible when those source plugins are in `openai-curated` and share
  Sales app connector IDs, while an unrelated test-source plugin with an
  app connector not declared by Sales stays hidden.
  
  ## Test Coverage
  
  - Empty/no-installed-plugin case: returns the fallback seed plugins from
  the original allowlist.
  - Installed-app expansion: returns non-fallback marketplace plugins only
  when their app connector IDs overlap with an installed plugin.
  - Sales workflow case: installed Sales declares HubSpot and Granola
  apps, so `hubspot@openai-curated` and `granola@openai-curated` are
  returned.
  - Sales negative case: `test-source@openai-curated` has an app connector
  not declared by Sales, so it is not returned.
  - Existing guardrails: installed plugins, disabled suggestions, and
  `NOT_AVAILABLE` plugins remain omitted; explicit configured
  discoverables still work as an override.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-core plugins::discoverable::tests`
  - `just test -p codex-core` was attempted earlier, but current `main` /
  local env failed with unrelated existing failures around missing
  `test_stdio_server`, CLI/code-mode MCP tool setup, and
  unified_exec/shell snapshot flakes/timeouts. The touched discoverable
  tests pass.

  Noah MacCallum · 2026-05-29 15:32:04 -07:00
  8e5f561697
• Update rmcp to 1.7.0 (#24763)

  WIll make it easier to uprev when the new draft spec is supported.
  
  Also updates reqwest where needed for compatibility but doesn't update
  it everywhere since this is already a large diff.
  
  The new version of rmcp handles certain kinds of authentication failures
  differently, this patch includes support for identifying the failing scope
  in a WWW-Authenticate header.

  Adam Perry @ OpenAI · 2026-05-27 14:52:06 -07:00
  910578792f
• Remove connector_openai prefix filtering (#22555)

  Remove unnecessary prefix filtering from codex
  
  ## Test Plan
  
  Test local cli build + make sure backend returns appropriate apps 
  
  ```
  cd ~/code/codex/codex-rs
  cargo build -p codex-cli --bin codex
  ./target/debug/codex
  ```
  
  Appropriate apps show up in my list

  Eric Ning · 2026-05-13 16:59:22 -07:00
  64d8f387f9
• Simplify MCP tool handler plumbing (#21595)

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

  pakrym-oai · 2026-05-12 00:11:31 +00:00
  ed5944ba1d
• feat(connectors): support managed app tool approval requirements (#21061)

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

  viyatb-oai · 2026-05-11 19:08:26 +00:00
  d0fa2d81d8
• Using cached connector directory for discoverable tools list (#21497)

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

  Matthew Zeng · 2026-05-08 14:14:11 -07:00
  2f3a2d7a86
• [codex] Remove string-keyed MCP tool maps (#21454)

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

  pakrym-oai · 2026-05-07 10:16:10 -07:00
  857e731478
• Use MCP server instructions in deferred namespace descriptions (#21053)

  ## Why
  
  MCP servers can provide `instructions` that explain what their tools are
  for. Directly exposed MCP namespaces already use those instructions when
  a connector description is not available, but deferred `tool_search`
  results did not preserve that fallback. The direct path falls back from
  connector metadata to server instructions, while the deferred path only
  carried `connector_description` and otherwise fell back to generic
  namespace text.
  
  That meant a plain MCP server could provide useful model-facing guidance
  and still appear as `Tools in the X namespace.` whenever it was
  discovered lazily through `tool_search`.
  
  ## What changed
  
  - Store one model-facing `namespace_description` on `ToolInfo`, using
  connector descriptions for connector-backed tools and server
  instructions for plain MCP servers.
  - Thread that namespace description through the `tool_search` source
  list, search indexing, and returned namespace metadata.
  - Add an end-to-end regression test for deferred non-app MCP search
  results exposing server instructions as the namespace description.
  
  ## Verification
  
  - `cargo test -p codex-tools
  search_tool_description_lists_each_mcp_source_once --lib`
  - `cargo test -p codex-core --test all
  tool_search_uses_non_app_mcp_server_instructions_as_namespace_description`

  sayan-oai · 2026-05-04 19:36:07 +00:00
  b9e8df47da
• Support disabling tool suggest for specific tools. (#20072)

  ## Summary
  - Add `disable_tool_suggest` to app and plugin config, schema, and
  TypeScript output
  - Exclude disabled connectors and plugins from tool suggestion discovery
  - Persist "never show again" tool-suggestion choices back into
  `config.toml`
  - Update config docs and add coverage for connector and plugin
  suppression
  
  ## Testing
  - Added and updated unit tests for config persistence and tool-suggest
  filtering
  - Not run (not requested)

  Matthew Zeng · 2026-04-29 00:19:34 +00:00
  ebdf3a878c
• [codex] Move config loading into codex-config (#19487)

  ## Why
  
  Config loading had become split across crates: `codex-config` owned the
  config types and merge logic, while `codex-core` still owned the loader
  that assembled the layer stack. This change consolidates that
  responsibility in `codex-config`, so the crate that defines config
  behavior also owns how configs are discovered and loaded.
  
  To make that move possible without reintroducing the old dependency
  cycle, the shell-environment policy types and helpers that
  `codex-exec-server` needs now live in `codex-protocol` instead of
  flowing through `codex-config`.
  
  This also makes the migrated loader tests more deterministic on machines
  that already have managed or system Codex config installed by letting
  tests override the system config and requirements paths instead of
  reading the host's `/etc/codex`.
  
  ## What Changed
  
  - moved the config loader implementation from `codex-core` into
  `codex-config::loader` and deleted the old `core::config_loader` module
  instead of leaving a compatibility shim
  - moved shell-environment policy types and helpers into
  `codex-protocol`, then updated `codex-exec-server` and other downstream
  crates to import them from their new home
  - updated downstream callers to use loader/config APIs from
  `codex-config`
  - added test-only loader overrides for system config and requirements
  paths so loader-focused tests do not depend on host-managed config state
  - cleaned up now-unused dependency entries and platform-specific cfgs
  that were surfaced by post-push CI
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core config_loader_tests::`
  - `cargo test -p codex-protocol -p codex-exec-server -p
  codex-cloud-requirements -p codex-rmcp-client --lib`
  - `cargo test --lib -p codex-app-server-client -p codex-exec`
  - `cargo test --no-run --lib -p codex-app-server`
  - `cargo test -p codex-linux-sandbox --lib`
  - `cargo shear`
  - `just bazel-lock-check`
  
  ## Notes
  
  - I did not chase unrelated full-suite failures outside the migrated
  loader surface.
  - `cargo test -p codex-core --lib` still hits unrelated proxy-sensitive
  failures on this machine, and Windows CI still shows unrelated
  long-running/timeouting test noise outside the loader migration itself.

  pakrym-oai · 2026-04-26 15:10:53 -07:00
  9c3abcd46c
• Make app tool hint defaults pessimistic for app policies (#17232)

  ## Summary
  - default missing app tool destructive/open-world hints to true for app
  policies
  - add regression tests for missing MCP annotations under restrictive app
  config

  colby-oai · 2026-04-17 13:27:49 -04:00
  ea84537369
• Move more connector logic into connectors crate (#18158)

  Reduce the size of core

  pakrym-oai · 2026-04-16 11:16:44 -07:00
  206dd13c32
• Refactor plugin loading to async (#17747)

  Simplifies skills migration.

  pakrym-oai · 2026-04-13 21:52:56 -07:00
  3b24a9a532
• [mcp] Expand tool search to custom MCPs. (#16944)

  - [x] Expand tool search to custom MCPs.
  - [x] Rename several variables/fields to be more generic.
  
  Updated tool & server name lifecycles:
  
  **Raw Identity**
  
  ToolInfo.server_name is raw MCP server name.
  ToolInfo.tool.name is raw MCP tool name.
  MCP calls route back to raw via parse_tool_name() returning
  (tool.server_name, tool.tool.name).
  mcpServerStatus/list now groups by raw server and keys tools by
  Tool.name: mod.rs:599
  App-server just forwards that grouped raw snapshot:
  codex_message_processor.rs:5245
  
  **Callable Names**
  
  On list-tools, we create provisional callable_namespace / callable_name:
  mcp_connection_manager.rs:1556
  For non-app MCP, provisional callable name starts as raw tool name.
  For codex-apps, provisional callable name is sanitized and strips
  connector name/id prefix; namespace includes connector name.
  Then qualify_tools() sanitizes callable namespace + name to ASCII alnum
  / _ only: mcp_tool_names.rs:128
  Note: this is stricter than Responses API. Hyphen is currently replaced
  with _ for code-mode compatibility.
  
  **Collision Handling**
  
  We do initially collapse example-server and example_server to the same
  base.
  Then qualify_tools() detects distinct raw namespace identities behind
  the same sanitized namespace and appends a hash to the callable
  namespace: mcp_tool_names.rs:137
  Same idea for tool-name collisions: hash suffix goes on callable tool
  name.
  Final list_all_tools() map key is callable_namespace + callable_name:
  mcp_connection_manager.rs:769
  
  **Direct Model Tools**
  
  Direct MCP tool declarations use the full qualified sanitized key as the
  Responses function name.
  The raw rmcp Tool is converted but renamed for model exposure.
  
  **Tool Search / Deferred**
  
  Tool search result namespace = final ToolInfo.callable_namespace:
  tool_search.rs:85
  Tool search result nested name = final ToolInfo.callable_name:
  tool_search.rs:86
  Deferred tool handler is registered as "{namespace}:{name}":
  tool_registry_plan.rs:248
  When a function call comes back, core recombines namespace + name, looks
  up the full qualified key, and gets the raw server/tool for MCP
  execution: codex.rs:4353
  
  **Separate Legacy Snapshot**
  
  collect_mcp_snapshot_from_manager_with_detail() still returns a map
  keyed by qualified callable name.
  mcpServerStatus/list no longer uses that; it uses
  McpServerStatusSnapshot, which is raw-inventory shaped.

  Matthew Zeng · 2026-04-09 13:34:52 -07:00
  d7f99b0fa6
• Render namespace description for tools (#16879)
  Vivian Fang · 2026-04-08 02:39:40 -07:00
  d47b755aa2
• [codex] reduce module visibility (#16978)

  ## Summary
  - reduce public module visibility across Rust crates, preferring private
  or crate-private modules with explicit crate-root public exports
  - update external call sites and tests to use the intended public crate
  APIs instead of reaching through module trees
  - add the module visibility guideline to AGENTS.md
  
  ## Validation
  - `cargo check --workspace --all-targets --message-format=short` passed
  before the final fix/format pass
  - `just fix` completed successfully
  - `just fmt` completed successfully
  - `git diff --check` passed

  pakrym-oai · 2026-04-07 08:03:35 -07:00
  413c1e1fdf
• [codex] Remove codex-core config type shim (#16529)

  ## Why
  
  This finishes the config-type move out of `codex-core` by removing the
  temporary compatibility shim in `codex_core::config::types`. Callers now
  depend on `codex-config` directly, which keeps these config model types
  owned by the config crate instead of re-expanding `codex-core` as a
  transitive API surface.
  
  ## What Changed
  
  - Removed the `codex-rs/core/src/config/types.rs` re-export shim and the
  `core::config::ApprovalsReviewer` re-export.
  - Updated `codex-core`, `codex-cli`, `codex-tui`, `codex-app-server`,
  `codex-mcp-server`, and `codex-linux-sandbox` call sites to import
  `codex_config::types` directly.
  - Added explicit `codex-config` dependencies to downstream crates that
  previously relied on the `codex-core` re-export.
  - Regenerated `codex-rs/core/config.schema.json` after updating the
  config docs path reference.

  Michael Bolin · 2026-04-02 01:19:44 -07:00
  c1d18ceb6f
• core: remove cross-crate re-exports from lib.rs (#16512)

  ## Why
  
  `codex-core` was re-exporting APIs owned by sibling `codex-*` crates,
  which made downstream crates depend on `codex-core` as a proxy module
  instead of the actual owner crate.
  
  Removing those forwards makes crate boundaries explicit and lets leaf
  crates drop unnecessary `codex-core` dependencies. In this PR, this
  reduces the dependency on `codex-core` to `codex-login` in the following
  files:
  
  ```
  codex-rs/backend-client/Cargo.toml
  codex-rs/mcp-server/tests/common/Cargo.toml
  ```
  
  ## What
  
  - Remove `codex-rs/core/src/lib.rs` re-exports for symbols owned by
  `codex-login`, `codex-mcp`, `codex-rollout`, `codex-analytics`,
  `codex-protocol`, `codex-shell-command`, `codex-sandboxing`,
  `codex-tools`, and `codex-utils-path`.
  - Delete the `default_client` forwarding shim in `codex-rs/core`.
  - Update in-crate and downstream callsites to import directly from the
  owning `codex-*` crate.
  - Add direct Cargo dependencies where callsites now target the owner
  crate, and remove `codex-core` from `codex-rs/backend-client`.

  Michael Bolin · 2026-04-01 23:06:24 -07:00
  aa2403e2eb
• core: use codex-mcp APIs directly (#16510)

  ## Why
  
  `codex-mcp` already owns the shared MCP API surface, including `auth`,
  `McpConfig`, `CODEX_APPS_MCP_SERVER_NAME`, and tool-name helpers in
  [`codex-rs/codex-mcp/src/mcp/mod.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/codex-mcp/src/mcp/mod.rs#L1-L35).
  Re-exporting that surface from `codex_core::mcp` gives downstream crates
  two import paths for the same API and hides the real crate dependency.
  
  This PR keeps `codex_core::mcp` focused on the local `McpManager`
  wrapper in
  [`codex-rs/core/src/mcp.rs`](https://github.com/openai/codex/blob/f61e85dbfb5373cde6827d232ac8ea447c237e81/codex-rs/core/src/mcp.rs#L13-L40)
  and makes consumers import shared MCP APIs from `codex_mcp` directly.
  
  ## What
  
  - Remove the `codex_mcp::mcp` re-export surface from `core/src/mcp.rs`.
  - Update `codex-core` internals plus `codex-app-server`, `codex-cli`,
  and `codex-tui` test code to import MCP APIs from `codex_mcp::mcp`
  directly.
  - Add explicit `codex-mcp` dependencies where those crates now use that
  API surface, and refresh `Cargo.lock`.
  
  ## Verification
  
  - `just bazel-lock-check`
  - `cargo test -p codex-core -p codex-cli -p codex-tui`
    - `codex-cli` passed.
  - `codex-core` still fails five unrelated config tests in
  `core/src/config/config_tests.rs` (`approvals_reviewer_*` and
  `smart_approvals_alias_*`).
  - A broader `cargo test -p codex-core -p codex-app-server -p codex-cli
  -p codex-tui` run previously hung in `codex-app-server` test
  `in_process_start_uses_requested_session_source_for_thread_start`.

  Michael Bolin · 2026-04-01 21:55:22 -07:00
  cc97982bbb
• 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
• Split features into codex-features crate (#15253)

  - Split the feature system into a new `codex-features` crate.
  - Cut `codex-core` and workspace consumers over to the new config and
  warning APIs.
  
  Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-19 20:12:07 -07:00
  2e22885e79
• [plugins] Support configuration tool suggest allowlist. (#15022)

  - [x] Support configuration tool suggest allowlist.
  
  Supports both plugins and connectors.

  Matthew Zeng · 2026-03-17 23:58:27 -07:00
  40a7d1d15b
• [plugins] Support plugin installation elicitation. (#14896)

  It now supports:
  
  - Connectors that are from installed and enabled plugins that are not
  installed yet
  - Plugins that are on the allowlist that are not installed yet.

  Matthew Zeng · 2026-03-17 13:19:28 -07:00
  683c37ce75
• Override local apps settings with requirements.toml settings (#14304)

  This PR changes app and connector enablement when `requirements.toml` is
  present locally or via remote configuration.
  
  For apps.* entries:
  - `enabled = false` in `requirements.toml` overrides the user’s local
  `config.toml` and forces the app to be disabled.
  - `enabled = true` in `requirements.toml` does not re-enable an app the
  user has disabled in config.toml.
  
  This behavior applies whether or not the user has an explicit entry for
  that app in `config.toml`. It also applies to cloud-managed policies and
  configurations when the admin sets the override through
  `requirements.toml`.
  
  Scenarios tested and verified:
  - Remote managed, user config (present) override
  - Admin-defined policies & configurations include a connector override:
    `[apps.<appID>]
  enabled = false`
  - User's config.toml has the same connector configured with `enabled =
  true`
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
    
  - Remote managed, user config (absent) override
  - Admin-defined policies & configurations include a connector override:
    `[apps.<appID>]
  enabled = false`
    - User's config.toml has no entry for the the same connector
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
    
  - Locally managed, user config (present) override
    - Local requirements.toml includes a connector override:
    `[apps.<appID>]
  enabled = false`
  - User's config.toml has the same connector configured with `enabled =
  true`
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
  
  - Locally managed, user config (absent) override
    - Local requirements.toml includes a connector override:
    `[apps.<appID>]
  enabled = false`
    - User's config.toml has no entry for the the same connector
    - TUI/App should show connector as disabled
    - Connector should be unavailable for use in the composer
  
  
  
  
  <img width="1446" height="753" alt="image"
  src="https://github.com/user-attachments/assets/61c714ca-dcca-4952-8ad2-0afc16ff3835"
  />
  <img width="595" height="233" alt="image"
  src="https://github.com/user-attachments/assets/7c8ab147-8fd7-429a-89fb-591c21c15621"
  />

  canvrno-oai · 2026-03-13 12:40:24 -07:00
  914f7c7317
• fix: move inline codex-rs/core unit tests into sibling files (#14444)

  ## Why
  PR #13783 moved the `codex.rs` unit tests into `codex_tests.rs`. This
  applies the same extraction pattern across the rest of `codex-rs/core`
  so the production modules stay focused on runtime code instead of large
  inline test blocks.
  
  Keeping the tests in sibling files also makes follow-up edits easier to
  review because product changes no longer have to share a file with
  hundreds or thousands of lines of test scaffolding.
  
  ## What changed
  - replaced each inline `mod tests { ... }` in `codex-rs/core/src/**`
  with a path-based module declaration
  - moved each extracted unit test module into a sibling `*_tests.rs`
  file, using `mod_tests.rs` for `mod.rs` modules
  - preserved the existing `cfg(...)` guards and module-local structure so
  the refactor remains structural rather than behavioral
  
  ## Testing
  - `cargo test -p codex-core --lib` (`1653 passed; 0 failed; 5 ignored`)
  - `just fix -p codex-core`
  - `cargo fmt --check`
  - `cargo shear`

  Michael Bolin · 2026-03-12 08:16:36 -07:00
  0c8a36676a