115 Commits

• [codex] Gate plugin MCP servers by auth route (#27459)

  ## Context
  
  Some plugins expose both Apps and MCP servers. This PR moves auth-aware
  surface projection into `core-plugins::PluginsManager`, so callers get a
  consistent effective plugin view. Later PRs narrow the conflict rule and
  update listing/install paths.
  
  The high level goal of this PR is to set up the plumbing to
  conditionally filter App/MCP in the plugin manager layer. We start by
  removing MCP servers when using SIWC/Codex-backend auth, and removing
  Apps when using API-key-style auth.
  
  This PR is now stacked on #27652, which contains only the constructor
  plumbing for seeding `PluginsManager` with the current auth mode.
  
  ## Stack
  
  - PR1: #27652 seed plugin manager auth at construction.
  - PR2: #27459 route plugin surfaces by auth mode.
  - PR3: #27607 dedupe plugin MCP servers by App declaration name.
  - PR4: #27602 preserve plugin Apps in connector listings.
  - PR5: #27461 skip install-time plugin MCP OAuth for matching App
  routes.
  
  ## Summary
  
  - API-key/non-ChatGPT routes hide plugin Apps and keep plugin MCPs.
  - ChatGPT/SIWC with Apps enabled keeps plugin Apps and suppresses MCPs
  for dual-surface plugins.
  - MCP-only plugins stay available for ChatGPT/SIWC sessions.
  - Cached plugin load outcomes are re-projected when auth mode changes.
  
  ## Validation
  
  ```bash
  cargo test -p codex-core-plugins plugin_auth_projection
  cargo test -p codex-core list_tool_suggest_discoverable_plugins
  git diff --check
  ```

  felixxia-oai · 2026-06-12 19:42:11 -07:00
  5d7db08b61
• [codex] Limit app-based plugin suggestions to remote catalogs (#27988)

  ## Summary
  
  - Keep local plugin suggestions bounded to fallback and explicitly
  configured plugins.
  - Preserve app-overlap recommendations for remote plugins using cached
  catalog metadata.
  - Remove the WSL-specific local discovery exception and move
  manager-owned discovery tests into `codex-core-plugins`.
  
  ## Why
  
  Local curated marketplaces were allowlisted before plugin detail
  loading, so every uninstalled candidate could be deep-read before its
  app IDs were checked. That caused per-turn reads of candidate plugin
  manifests, skills, app configs, hooks, and MCP configs, which is
  especially expensive on slow disks.
  
  Remote discovery does not need those local candidate reads because app
  IDs are already available in the cached remote catalog. Installed local
  plugins are still loaded when needed to determine the user's installed
  app IDs.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-core-plugins discoverable::tests` (13 passed)
  - `just test -p codex-core plugins::discoverable::tests` (4 passed)
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `git diff --check`

  xl-openai · 2026-06-12 17:51:09 -07:00
  044c1420a1
• [codex] add latency tracing spans (#27710)

  ## Why
  
  We have some large gaps in our thread start, resume, and pre-sampling
  traces that make it hard to tell where latency is coming from.
  
  ## What Changed
  
  - Added coarse spans around thread start/resume, turn context
  construction, rollout reconstruction, skill/plugin loading, and tool
  preparation.
  - Added a breakdown of discoverable-tool preparation across connector
  loading, plugin discovery, and local plugin details.
  
  ## Testing
  
  - `cargo check -p codex-app-server -p codex-core -p codex-core-skills -p
  codex-core-plugins`
  - Built the app-server locally and exercised thread start, first turn,
  follow-up turn, server restart, thread resume, and a resumed turn.

  rphilizaire-openai · 2026-06-12 17:11:32 -07:00
  bacfc5e4c0
• fix(plugins) rm plugin descriptions (#23254)

  ## Summary
  Removes Plugin descriptions from the dev message, since descriptions of
  skills and MCPs cover the capabilities offered by the plugin.
  
  ## Testing
  - [x] Updates unit tests

  Dylan Hurd · 2026-06-12 13:31:11 -07:00
  3e2ee1da3f
• [plugins] Inject remote_plugin_id into install elicitations (#26409)

  Summary
  - Propagate cached remote plugin IDs through Codex plugin discovery.
  - Inject `remote_plugin_id` and connector IDs into
  `request_plugin_install` elicitation `_meta` from the resolved plugin.
  - Keep the remote plugin ID out of the model-facing tool schema,
  arguments, and result.
  
  Validation
  - `just test -p codex-tools`
  - `just test -p codex-core-plugins`
  - `just test -p codex-core
  list_tool_suggest_discoverable_plugins_includes_cached_remote_global_plugins`
  - `just fix -p codex-tools`
  - `just fix -p codex-core-plugins`
  - `just fix -p codex-core`
  - `git diff --check`
  - `just test -p codex-core` was also attempted: 2,581 passed, 55 failed,
  and 1 timed out across unrelated sandbox/environment-sensitive
  integration tests.

  Alex Daley · 2026-06-10 12:01:03 -07:00
  020bf49346
• [codex] Return workspace directory installed plugins (#27098)

  ## Summary
  
  - return installed `workspace-directory` remote plugins by default in
  `plugin/installed`
  - keep shared-with-me installed plugins gated behind `plugin_sharing`
  - filter remote installed plugin marketplaces by canonical marketplace
  name instead of coarse workspace scope
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-core-plugins`
  - `just test -p codex-app-server`
  - `just fix -p codex-core-plugins`
  - `just fix -p codex-app-server`
  - `$xin-build` targeted verification:
  - `just test -p codex-core-plugins
  build_remote_installed_plugin_marketplaces_from_cache_filters_by_marketplace_name`
  - `just test -p codex-app-server
  plugin_installed_includes_workspace_directory_without_plugin_sharing`
  - `just test -p codex-app-server
  plugin_installed_includes_remote_shared_with_me_plugins`
  - `just test -p codex-app-server
  plugin_list_omits_shared_with_me_kind_when_plugin_sharing_disabled`

  xl-openai · 2026-06-09 01:23:16 -07:00
  a304569c79
• [codex] Move plugin discoverable logic into core-plugins (#25783)

  ## Summary
  - Move plugin discoverable recommendation filtering from `codex-core`
  into `codex-core-plugins` behind `ToolSuggestPluginDiscoveryInput`.
  - Keep `codex-core` as a thin adapter from `Config` to the core-plugins
  API and back to `DiscoverablePluginInfo`.
  - Keep the existing discoverable allowlist private to the core-plugins
  implementation.
  
  ## Validation
  - `just fmt`
  - `just test -p codex-core list_tool_suggest_discoverable_plugins`
  - `git diff --check`
  - Read-only subagent review: no findings

  xl-openai · 2026-06-01 23:25:37 -07:00
  07f04cc3c7
• [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
• 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
• [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
• [codex] Add OpenAI Developers to tool suggest allowlist (#21423)

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

  mifan-oai · 2026-05-06 23:49:15 -04:00
  001363188a
• Move plugin out of core. (#20348)
  xl-openai · 2026-04-30 14:26:14 -07:00
  7b3de63041
• [plugins] Allow MSFT curated plugins in tool_suggest (#20304)

  ## Summary
  - [x] Move the allowlist out of core crate
  - [x] Add Teams, SharePoint, Outlook Email, and Outlook Calendar to the
  tool_suggest discoverable plugin allowlist
  - [x] Add focused coverage for Microsoft curated plugin discovery
  
  ## Testing
  - just fmt
  - cargo test -p codex-core-plugins
  - cargo test -p codex-core
  list_tool_suggest_discoverable_plugins_returns_

  Matthew Zeng · 2026-04-29 19:45:52 -07:00
  ebe602d005
• Add hooks/list app-server RPC (#19778)

  ## Why
  
  We need a way to list the available hooks to expose via the TUI and App
  so users can view and manage their hooks
  
  ## What
  
  - Adds `hooks/list` for one or more `cwd` values that returns discovered
  hook metadata
  
  ## Stack
  
  1. openai/codex#19705
  2. This PR - openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Review Notes
  
  The generated schema files account for most of the raw diff, these files
  have the core change:
  
  - `hooks/src/engine/discovery.rs` builds the inventory entries during
  hook discovery while leaving runtime handlers focused on execution.
  - `app-server/src/codex_message_processor.rs` wires `hooks/list` into
  the app-server flow for each requested `cwd`.
  - `app-server-protocol/src/protocol/v2.rs` defines the new v2
  request/response payloads exposed on the wire.
  
  ### Core Changes
  
  `core/src/plugins/manager.rs` adds `plugins_for_layer_stack(...)` so
  `skills/list` and `hooks/list`can resolve plugin state for each
  requested `cwd`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-29 23:39:57 +00:00
  8774229a89
• [mcp] Fix plugin MCP approval policy. (#19537)

  Plugin MCP servers are loaded from plugin manifests rather than
  top-level `[mcp_servers]`, so their tool approval preferences need to be
  stored and applied through the owning plugin config. Without this,
  choosing "Always allow" for a plugin MCP tool could write a preference
  that was not reliably used on later tool calls.
  
  ## Summary
  - Add plugin-scoped MCP policy config under
  `plugins.<plugin>.mcp_servers`, including server enablement, tool
  allow/deny lists, server defaults, and per-tool approval modes.
  - Overlay plugin MCP policy onto manifest-provided server configs when
  plugins are loaded.
  - Route persistent "Always allow" writes for plugin MCP tools back to
  the owning `plugins.<plugin>.mcp_servers.<server>.tools.<tool>` config
  entry.
  - Reload user config after persisting an approval and make the plugin
  load cache config-aware so stale plugin MCP policy is not reused after
  `config.toml` changes.
  - Regenerate the config schema and add coverage for plugin MCP policy
  loading, approval lookup, persistence, and stale-cache prevention.
  
  ## Testing
  - `cargo test -p codex-config`
  - `cargo test -p codex-core-plugins`
  - `cargo test -p codex-core --lib plugin_mcp`

  Matthew Zeng · 2026-04-29 15:40:03 -07:00
  e20391e567
• feat: Use remote installed plugin cache for skills and MCP (#20096)

  - Fetches and caches remote /installed plugin state
  - Lets skills/list load skills from remote-installed cached plugins
  without requiring a local marketplace entry
  - Routes plugin list/startup/install/uninstall changes through async
  plugin cache invalidation and MCP refresh

  xl-openai · 2026-04-29 12:09:49 -07:00
  73cd831952
• 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
• Discover hooks bundled with plugins (#19705)

  ## Why
  
  Plugins can bundle lifecycle hooks, but Codex previously only discovered
  hooks from user, project, and managed config layers. This adds the
  plugin discovery and runtime plumbing needed for plugin-bundled hooks
  while keeping execution behind the `plugin_hooks` feature flag.
  
  ## What
  
  - Discovers plugin hook sources from each plugin's default
  `hooks/hooks.json`.
  - Supports `plugin.json` manifest `hooks` entries as either relative
  paths or inline hook objects.
  - Plumbs discovered plugin hook sources through plugin loading into the
  hook runtime when `plugin_hooks` is enabled.
  - Marks plugin-originated hook runs as `HookSource::Plugin`.
  - Injects `PLUGIN_ROOT` and `CLAUDE_PLUGIN_ROOT` into plugin hook
  command environments.
  - Updates generated schemas and hook source metadata for the plugin hook
  source.
  
  ## Stack
  
  1. This PR - openai/codex#19705
  2. openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Reviewer Notes
  
  - Core logic is in `codex-rs/core-plugins/src/loader.rs` and
  `codex-rs/hooks/src/engine/discovery.rs`
  - Moved existing / adding new tests to
  `codex-rs/core-plugins/src/loader_tests.rs` hence the large diff there
  - Otherwise mostly plumbing and minor schema updates
  
  ### Core Changes
  
  The `codex-rs/core` changes are limited to wiring plugin hook support
  into existing core flows:
  
  - `core/src/session/session.rs` conditionally pulls effective plugin
  hook sources and plugin hook load warnings from `PluginsManager` when
  `plugin_hooks` is enabled, then passes them into `HooksConfig`.
  - `core/src/hook_runtime.rs` adds the `plugin` metric tag for
  `HookSource::Plugin`.
  - `core/config.schema.json` picks up the new `plugin_hooks` feature
  flag, and `core/src/plugins/manager_tests.rs` updates fixtures for the
  added plugin hook fields.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-28 14:17:18 -07:00
  c6e7d564c3
• [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
• feat: Use short SHA versions for curated plugin cache entries (#19095)

  Curated plugin cache entries now use an 8-character SHA prefix, instead
  of the full SHA, as the cache folder version number.

  xl-openai · 2026-04-23 21:15:03 -07:00
  53be451673
• refactor: route Codex auth through AuthProvider (#18811)

  ## Summary
  
  This PR moves Codex backend request authentication from direct
  bearer-token handling to `AuthProvider`.
  
  The new `codex-auth-provider` crate defines the shared request-auth
  trait. `CodexAuth::provider()` returns a provider that can apply all
  headers needed for the selected auth mode.
  
  This lets ChatGPT token auth and AgentIdentity auth share the same
  callsite path:
  - ChatGPT token auth applies bearer auth plus account/FedRAMP headers
  where needed.
  - AgentIdentity auth applies AgentAssertion plus account/FedRAMP headers
  where needed.
  
  Reference old stack: https://github.com/openai/codex/pull/17387/changes
  
  ## Callsite Migration
  
  | Area | Change |
  | --- | --- |
  | backend-client | accepts an `AuthProvider` instead of a raw
  token/header |
  | chatgpt client/connectors | applies auth through
  `CodexAuth::provider()` |
  | cloud tasks | keeps Codex-backend gating, applies auth through
  provider |
  | cloud requirements | uses Codex-backend auth checks and provider
  headers |
  | app-server remote control | applies provider headers for backend calls
  |
  | MCP Apps/connectors | gates on `uses_codex_backend()` and keys caches
  from generic account getters |
  | model refresh | treats AgentIdentity as Codex-backend auth |
  | OpenAI file upload path | rejects non-Codex-backend auth before
  applying headers |
  | core client setup | keeps model-provider auth flow and allows
  AgentIdentity through provider-backed OpenAI auth |
  
  ## Stack
  
  1. https://github.com/openai/codex/pull/18757: full revert
  2. https://github.com/openai/codex/pull/18871: isolated Agent Identity
  crate
  3. https://github.com/openai/codex/pull/18785: explicit AgentIdentity
  auth mode and startup task allocation
  4. This PR: migrate Codex backend auth callsites through AuthProvider
  5. https://github.com/openai/codex/pull/18904: accept AgentIdentity JWTs
  and load `CODEX_AGENT_IDENTITY`
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-23 17:14:02 -07:00
  5882f3f95e
• Move marketplace add/remove and startup sync out of core. (#19099)

  Move more things to core-plugins.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-23 11:27:17 -07:00
  198eddd25d
• feat: Support remote plugin list/read. (#18452)

  Add a temporary internal remote_plugin feature flag that merges remote
  marketplaces into plugin/list and routes plugin/read through the remote
  APIs when needed, while keeping pure local marketplaces working as
  before.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-21 18:39:07 -07:00
  a978e411f6
• Split DeveloperInstructions into individual fragments. (#18813)

  Split DeveloperInstructions into individual fragments.

  pakrym-oai · 2026-04-21 10:22:36 -07:00
  2a226096f6
• Refactor app-server config loading into ConfigManager (#18442)

  Localize app-server configuration loading in one place.

  pakrym-oai · 2026-04-21 10:22:26 -07:00
  5fe767e8e1
• Move external agent config out of core (#18850)

  ## Summary
  - Move external agent config migration logic and tests from `codex-core`
  into `app-server/src/config`.
  - Keep the migration service crate-private to app-server and update the
  API adapter imports.
  - Remove stale core re-exports and expose only the needed marketplace
  source helper.
  
  ## Testing
  - `cargo test -p codex-app-server config::external_agent_config`
  - `just fmt`
  - `just fix -p codex-app-server`
  - `just fix -p codex-core`
  - `git diff --check`

  pakrym-oai · 2026-04-21 08:33:58 -07:00
  833212115e
• refactor: use semaphores for async serialization gates (#18403)

  This is the second cleanup in the await-holding lint stack. The
  higher-level goal, following https://github.com/openai/codex/pull/18178
  and https://github.com/openai/codex/pull/18398, is to enable Clippy
  coverage for guards held across `.await` points without carrying broad
  suppressions.
  
  The stack is working toward enabling Clippy's
  [`await_holding_lock`](https://rust-lang.github.io/rust-clippy/master/index.html#await_holding_lock)
  lint and the configurable
  [`await_holding_invalid_type`](https://rust-lang.github.io/rust-clippy/master/index.html#await_holding_invalid_type)
  lint for Tokio guard types.
  
  Several existing fields used `tokio::sync::Mutex<()>` only as
  one-at-a-time async gates. Those guards intentionally lived across
  `.await` while an operation was serialized. A mutex over `()` suggests
  protected data and trips the await-holding lint shape; a single-permit
  `tokio::sync::Semaphore` expresses the intended serialization directly.
  
  ## What changed
  
  - Replace `Mutex<()>` serialization gates with `Semaphore::new(1)` for
  agent identity ensure, exec policy updates, guardian review session
  reuse, plugin remote sync, managed network proxy refresh, auth token
  refresh, and RMCP session recovery.
  - Update call sites from `lock().await` / `try_lock()` to
  `acquire().await` / `try_acquire()`.
  - Map closed-semaphore errors into the existing local error types, even
  though these semaphores are owned for the lifetime of their managers.
  - Update session test builders for the new
  `managed_network_proxy_refresh_lock` type.
  
  ## Verification
  
  - The split stack was verified at the final lint-enabling head with
  `just clippy`.
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18403).
  * #18698
  * #18423
  * #18418
  * __->__ #18403

  Michael Bolin · 2026-04-20 17:21:29 +00:00
  5d5d610740
• [codex] Add marketplace remove command and shared logic (#17752)

  ## Summary
  
  Move the marketplace remove implementation into shared core logic so
  both the CLI command and follow-up app-server RPC can reuse the same
  behavior.
  
  This change:
  - adds a shared `codex_core::plugins::remove_marketplace(...)` flow
  - moves validation, config removal, and installed-root deletion out of
  the CLI
  - keeps the CLI as a thin wrapper over the shared implementation
  - adds focused core coverage for the shared remove path
  
  ## Validation
  
  - `just fmt`
  - focused local coverage for the shared remove path
  - heavier follow-up validation deferred to stacked PR CI

  xli-oai · 2026-04-17 21:44:47 -07:00
  e9c70fff3f
• [codex] Describe uninstalled cross-repo plugin reads (#18449)

  ## Summary
  - Populate `PluginDetail.description` in core for uninstalled cross-repo
  plugins when detailed fields are unavailable until install.
  - Include the source Git URL plus optional path/ref/sha details in that
  fallback description.
  - Keep `details_unavailable_reason` as the structured signal while
  app-server forwards the description normally.
  - Add plugin-read coverage proving the response does not clone the
  remote source just to show the message.
  
  ## Why
  Uninstalled cross-repo plugins intentionally return sparse detail data
  so listing/reading does not clone the plugin source. Without a
  description, Desktop and TUI detail pages look like an ordinary empty
  plugin. This gives users a concrete explanation and source pointer while
  keeping the existing structured reason available for callers.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-core
  read_plugin_for_config_uninstalled_git_source_requires_install_without_cloning`
  - `cargo test -p codex-app-server plugin_read --test all`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`
  
  Note: `cargo test -p codex-app-server` was also attempted before the
  latest refactor and failed broadly in unrelated v2
  thread/realtime/review/skills suites; the new plugin-read test passed in
  that run as well.

  xli-oai · 2026-04-17 20:31:13 -07:00
  def6467d2b
• feat: Add remote plugin fields to plugin API (#17277)

  ## Summary
  Update the plugin API for the new remote plugin model.
  
  The mental model is no longer “keep local plugin state in sync with
  remote.” Instead, local and remote plugins are becoming separate
  sources. Remote catalog entries can be shown directly from the remote
  API before installation; after installation they are still downloaded
  into the local cache for execution, but remote installed state will come
  from the API and be held in memory rather than being read from config.
  
  • ## API changes
  - Remove `forceRemoteSync` from `plugin/list`, `plugin/install`, and
  `plugin/uninstall`.
    - Remove `remoteSyncError` from `plugin/list`.
    - Add remote-capable metadata to `plugin/list` / `plugin/read`:
      - nullable `marketplaces[].path`
      - `source: { type: "remote", downloadUrl }`
      - URL asset fields alongside local path fields:
    `composerIconUrl`, `logoUrl`, `screenshotUrls`
    - Make `plugin/read` and `plugin/install` source-compatible:
      - `marketplacePath?: AbsolutePathBuf | null`
      - `remoteMarketplaceName?: string | null`
      - exactly one source is required at runtime

  xl-openai · 2026-04-17 16:47:58 -07:00
  26d9894a27
• [codex] Add cross-repo plugin sources to marketplace manifests (#18017)

  ## Summary
  - add first-class marketplace support for git-backed plugin sources
  - keep the newer marketplace parsing behavior from `main`, including
  alternate manifest locations and string local sources
  - materialize remote plugin sources during install, detail reads, and
  non-curated cache refresh
  - expose git plugin source metadata through the app-server protocol
  
  ## Details
  This teaches the marketplace parser to accept all of the following:
  - local string sources such as `"source": "./plugins/foo"`
  - local object sources such as
  `{"source":"local","path":"./plugins/foo"}`
  - remote repo-root sources such as
  `{"source":"url","url":"https://github.com/org/repo.git"}`
  - remote subdir sources such as
  `{"source":"git-subdir","url":"owner/repo","path":"plugins/foo","ref":"main","sha":"..."}`
  
  It also preserves the newer tolerant behavior from `main`: invalid or
  unsupported plugin entries are skipped instead of breaking the whole
  marketplace.
  
  ## Validation
  - `cargo test -p codex-core plugins::marketplace::tests`
  - `just fix -p codex-core`
  - `just fmt`
  
  ## Notes
  - A full `cargo test -p codex-core` run still hit unrelated existing
  failures in agent and multi-agent tests during this session; the
  marketplace-focused suite passed after the rebase resolution.

  xli-oai · 2026-04-17 15:11:42 -07:00
  0e111e08d0
• Sync local plugin imports, async remote imports, refresh caches after… (#18246)

  … import
  
  ## Why
  
  `externalAgentConfig/import` used to spawn plugin imports in the
  background and return immediately. That meant local marketplace imports
  could still be in flight when the caller refreshed plugin state, so
  newly imported plugins would not show up right away.
  
  This change makes local marketplace imports complete before the RPC
  returns, while keeping remote marketplace imports asynchronous so we do
  not block on remote fetches.
  
  ## What changed
  
  - split plugin migration details into local and remote marketplace
  imports based on the external config source
  - import local marketplaces synchronously during
  `externalAgentConfig/import`
  - return pending remote plugin imports to the app-server so it can
  finish them in the background
  - clear the plugin and skills caches before responding to plugin
  imports, and again after background remote imports complete, so the next
  `plugin/list` reloads fresh state
  - keep marketplace source parsing encapsulated behind
  `is_local_marketplace_source(...)` instead of re-exporting the internal
  enum
  - add core and app-server coverage for the synchronous local import path
  and the pending remote import path
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core` (currently fails an existing unrelated
  test:
  `config_loader::tests::cli_override_can_update_project_local_mcp_server_when_project_is_trusted`)
  - `cargo test` (currently fails existing `codex-app-server` integration
  tests in MCP/skills/thread-start areas, plus the unrelated `codex-core`
  failure above)

  alexsong-oai · 2026-04-17 09:34:55 +00:00
  20b4b80426
• Move Computer Use tool suggestion to core (#18219)

  ## Summary
  
  Move the Computer Use tool suggestion into core Codex plugin discovery.
  
  Also search `openai-bundled` when listing suggested plugins, with test
  coverage for overlap between baked-in suggestions and
  `tool_suggest.discoverables`.
  
  ## Test plan
  
  Tested locally:
  
  - `cargo test -p codex-core list_tool_suggest_discoverable_plugins`

  Leo Shimonaka · 2026-04-16 19:55:23 -07:00
  dd00efe781
• feat: Handle alternate plugin manifest paths (#18182)

  Load plugin manifests through a shared discoverable-path helper so
  manifest reads, installs, and skill names all see the same alternate
  manifest location.

  xl-openai · 2026-04-16 19:43:19 -07:00
  37161bc76e
• Move marketplace add under plugin command (#18116)

  ## Summary
  - move the marketplace add CLI from `codex marketplace add` to `codex
  plugin marketplace add`
  - keep marketplace config overrides working through the nested plugin
  command
  - reject `--sparse` for local marketplace directory sources before the
  local-source install path bypasses git-source validation
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  - `cargo test -p codex-cli`
  - `cargo test -p codex-core marketplace_add -- --nocapture`
  - `cargo test -p codex-core
  install_plugin_updates_config_with_relative_path_and_plugin_key --
  --nocapture`
  - `xli-test-marketplace-cli` local isolated matrix: `T1`, `L1`-`L10`

  xli-oai · 2026-04-16 17:06:34 -07:00
  5818ed6660
• Add server-level approval defaults for custom MCP servers (#17843)

  ## Summary
  - Add `default_tools_approval_mode` support for custom MCP server
  configs, matching the existing `codex_apps` behavior
  - Apply approval precedence as per-tool override, then server default,
  then `auto`
  - Update config serialization, CLI display, schema generation, docs, and
  tests
  
  ## Testing
  - `cargo check -p codex-config`
  - `cargo check -p codex-core`
  - `just write-config-schema`
  - `just fmt`
  - `cargo test -p codex-config`
  - Targeted `codex-core` tests for config parsing, config writes, and MCP
  approval precedence
  - `just fix -p codex-config -p codex-core`

  Matthew Zeng · 2026-04-16 18:18:07 +00:00
  71174574ad
• Move more connector logic into connectors crate (#18158)

  Reduce the size of core

  pakrym-oai · 2026-04-16 11:16:44 -07:00
  206dd13c32
• Auto-upgrade configured marketplaces (#17425)

  ## Summary
  - Add best-effort auto-upgrade for user-configured Git marketplaces
  recorded in `config.toml`.
  - Track the last activated Git revision with `last_revision` so
  unchanged marketplace sources skip clone work.
  - Trigger the upgrade from plugin startup and `plugin/list`, while
  preserving existing fail-open plugin behavior with warning logs rather
  than new user-visible errors.
  
  ## Details
  - Remote configured marketplaces use `git ls-remote` to compare the
  source/ref against the recorded revision.
  - Upgrades clone into a staging directory, validate that
  `.agents/plugins/marketplace.json` exists and that the manifest name
  matches the configured marketplace key, then atomically activate the new
  root.
  - Local `.agents/plugins/marketplace.json` marketplaces remain live
  filesystem state and are not auto-pulled.
  - Existing non-curated plugin cache refresh is kicked after successful
  marketplace root upgrades.
  
  ## Validation
  - `just write-config-schema`
  - `cargo test -p codex-core marketplace_upgrade`
  - `cargo check -p codex-cli -p codex-app-server`
  - `just fix -p codex-core`
  
  Did not run the complete `cargo test` suite because the repo
  instructions require asking before a full core workspace run.

  xli-oai · 2026-04-16 10:36:34 -07:00
  faf48489f3
• Improve external agent plugin migration for configured marketplaces (#18055)
  alexsong-oai · 2026-04-16 17:34:38 +00:00
  109b22a8d0
• [1/8] Add MCP server environment config (#18085)

  ## Summary
  - Add an MCP server environment setting with local as the default.
  - Thread the default through config serialization, schema generation,
  and existing config fixtures.
  
  ## Stack
  ```text
  o  #18027 [8/8] Fail exec client operations after disconnect
  │
  o  #18025 [7/8] Cover MCP stdio tests with executor placement
  │
  o  #18089 [6/8] Wire remote MCP stdio through executor
  │
  o  #18088 [5/8] Add executor process transport for MCP stdio
  │
  o  #18087 [4/8] Abstract MCP stdio server launching
  │
  o  #18020 [3/8] Add pushed exec process events
  │
  o  #18086 [2/8] Support piped stdin in exec process API
  │
  @  #18085 [1/8] Add MCP server environment config
  │
  o  main
  ```
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-16 08:50:03 -07:00
  b4be3617f9
• Stabilize Bazel tests (timeout tweaks and flake fixes) (#17791)
  David de Regt · 2026-04-16 07:57:51 -07:00
  6adba99f4d
• Extract plugin loading and marketplace logic into codex-core-plugins (#18070)

  Split plugin loading, marketplace, and related infrastructure out of
  core into codex-core-plugins, while keeping the core-facing
  configuration and orchestration flow in codex-core.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-15 23:13:17 -07:00
  48cf3ed7b0
• feat: Support alternate marketplace manifests and local string (#17885)

  - Discover marketplace manifests from different supported layout paths
  instead of only .agents/plugins/marketplace.json.
  - Accept local plugin sources written either as { source: "local", path:
  ... } or as a direct string path.
  - Skip unsupported or invalid plugin source entries without failing the
  entire marketplace, and keep valid local plugins loadable.

  xl-openai · 2026-04-15 14:16:41 -07:00
  e70ccdeaf7
• [codex] Fix current main CI blockers (#17917)

  ## Summary
  - Fix marketplace-add local path detection on Windows by using
  `Path::is_absolute()`.
  - Make marketplace-add local-source tests parse/write TOML through the
  same helpers instead of raw string matching.
  - Update `rand` 0.9.x to 0.9.3 and document the remaining audited `rand`
  0.8.5 advisory exception.
  - Refresh `MODULE.bazel.lock` after the Cargo.lock update.
  
  ## Why
  Latest `main` had two independent CI blockers: marketplace-add tests
  were not portable to Windows path/TOML escaping, and cargo-deny still
  reported `RUSTSEC-2026-0097` after the recent rustls-webpki fix.
  
  ## Validation
  - `cargo test -p codex-core marketplace_add -- --nocapture`
  - `cargo deny --all-features check`
  - `just bazel-lock-check`
  - `just fix -p codex-core`
  - `just fmt`
  - `git diff --check`

  sayan-oai · 2026-04-15 11:47:26 +01:00
  b99a62c526
• [codex] Support local marketplace sources (#17756)

  ## Summary
  
  - Port marketplace source support into the shared core marketplace-add
  flow
  - Support local marketplace directory sources
  - Support direct `marketplace.json` URL sources
  - Persist the new source types in config/schema and cover them in CLI
  and app-server tests
  
  ## Validation
  
  - `cargo test -p codex-core marketplace_add`
  - `cargo test -p codex-cli marketplace_add`
  - `cargo test -p codex-app-server marketplace_add`
  - `just write-config-schema`
  - `just fmt`
  - `just fix -p codex-core`
  - `just fix -p codex-cli`
  
  ## Context
  
  Current `main` moved marketplace-add behavior into shared core code and
  still assumed only git-backed sources. This change keeps that structure
  but restores support for local directories and direct manifest URLs in
  the shared path.

  xli-oai · 2026-04-14 15:58:14 -07:00
  3cc689fb23
• Make skill loading filesystem-aware (#17720)

  Migrates skill loading to support reading repo skills from the remote
  environment.

  pakrym-oai · 2026-04-14 15:40:40 -07:00
  96254a763a
• Spread AbsolutePathBuf (#17792)

  Mechanical change to promote absolute paths through code.

  pakrym-oai · 2026-04-14 14:26:10 -07:00
  dd1321d11b
• fix: Revert danger-full-access denylist-only mode (#17732)

  ## Summary
  
  - Reverts openai/codex#16946 and removes the danger-full-access
  denylist-only network mode.
  - Removes the corresponding config requirements, app-server
  protocol/schema, config API, TUI debug output, and network proxy
  behavior.
  - Drops stale tests that depended on the reverted mode while preserving
  newer managed allowlist-only coverage.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-config network_requirements`
  - `cargo test -p codex-core network_proxy_spec`
  - `cargo test -p codex-core
  managed_network_proxy_decider_survives_full_access_start`
  - `cargo test -p codex-app-server map_requirements_toml_to_api`
  - `cargo test -p codex-tui debug_config_output`
  - `cargo test -p codex-app-server-protocol`
  - `just fix -p codex-config -p codex-core -p codex-app-server-protocol
  -p codex-app-server -p codex-tui`
  - `git diff --cached --check`
  
  Not run: full workspace `cargo test` (repo instructions ask for
  confirmation before that broader run).

  viyatb-oai · 2026-04-14 09:50:14 -07:00
  81c0bcc921
• Refactor plugin loading to async (#17747)

  Simplifies skills migration.

  pakrym-oai · 2026-04-13 21:52:56 -07:00
  3b24a9a532
• [codex] Refactor marketplace add into shared core flow (#17717)

  ## Summary
  
  Move `codex marketplace add` onto a shared core implementation so the
  CLI and app-server path can use one source of truth.
  
  This change:
  - adds shared marketplace-add orchestration in `codex-core`
  - switches the CLI command to call that shared implementation
  - removes duplicated CLI-only marketplace add helpers
  - preserves focused parser and add-path coverage while moving the shared
  behavior into core tests
  
  ## Why
  
  The new `marketplace/add` RPC should reuse the same underlying
  marketplace-add flow as the CLI. This refactor lands that consolidation
  first so the follow-up app-server PR can be mostly protocol and handler
  wiring.
  
  ## Validation
  
  - `cargo test -p codex-core marketplace_add`
  - `cargo test -p codex-cli marketplace_cmd`
  - `just fix -p codex-core`
  - `just fix -p codex-cli`
  - `just fmt`

  xli-oai · 2026-04-13 20:37:11 -07:00
  ff584c5a4b