98 Commits

• [codex] Skip plugin MCP OAuth for matching app routes (#27461)

  ## Context
  
  This is PR5 in the plugin auth-routing stack. Earlier PRs make plugin
  surface projection auth-aware, narrow App/MCP conflicts by App
  declaration name, and keep connector listings auth-aware. This PR
  applies the same name-based App/MCP conflict rule into plugin MCP
  loading, so install-time MCP OAuth and plugin detail metadata both
  reflect the MCPs available for the current auth route.
  
  ## 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
  
  - Make `load_plugin_mcp_servers` auth-aware and let it load App
  declarations before filtering same-name MCP servers for Codex-backend
  auth.
  - Use that filtered MCP list for both install-time MCP OAuth and
  marketplace plugin detail metadata.
  - Preserve API-key/direct auth behavior so plugin MCP servers remain
  visible and can still start OAuth.
  
  ## Validation
  
  ```bash
  cargo fmt --all
  cargo test -p codex-core-plugins read_plugin_for_config_filters_mcp_servers_for_codex_backend_auth
  cargo check -p codex-core-plugins -p codex-app-server
  git diff --check
  git diff --cached --check
  ```

  felixxia-oai · 2026-06-15 14:04:01 +01:00
  e5253b97fb
• Discover stdio MCP servers from selected executor plugins (#27870)

  ## Why
  
  **In short:** this PR discovers MCP registrations by reading a selected
  plugin's `.mcp.json` on its executor. #27884 then resolves those
  registrations in the shared catalog.
  
  `thread/start.selectedCapabilityRoots` can select a plugin root owned by
  an executor, and Codex can resolve that package through the executor
  filesystem. MCP declarations inside the selected plugin are still
  ignored.
  
  This PR adds the source-specific discovery layer on top of the
  selected-plugin catalog boundary in #27884:
  
  ```text
  selected capability root
          |
          v
  resolve the plugin through its executor filesystem
          |
          v
  read and normalize its MCP config through the same filesystem
          |
          v
  contribute stdio registrations bound to that environment ID
  ```
  
  The existing MCP launcher and connection manager remain unchanged. MCP
  config parsing is shared with local plugins through #27863.
  
  ## What changed
  
  - Added an executor plugin MCP provider in the MCP extension.
  - Retained only the exact filesystem capability used for package
  resolution and reused it for the selected plugin's MCP config, with no
  host-filesystem fallback or unrelated process/HTTP authority.
  - Read either the manifest-declared MCP config or the default
  `.mcp.json`; a missing default file means the plugin has no MCP servers.
  - Accepted stdio servers only for this first vertical. Executor-owned
  HTTP declarations are skipped with a warning until their placement
  semantics are defined.
  - Normalized stdio registrations with the owning environment's stable
  logical ID and plugin-root working directory.
  - Resolved environment-variable names on the owning executor and
  rejected explicit local forwarding for non-local plugins.
  - Froze discovered declarations once per active thread runtime, then
  applied current managed plugin and MCP requirements when contributing
  them.
  - Carried the selected root ID, display name, and selection order into
  the catalog contribution defined by #27884.
  
  ## Behavior and scope
  
  There is intentionally no production behavior change yet. This PR
  provides the executor provider and contribution boundary, but app-server
  does not install it in this change. Existing local plugin MCP loading is
  unchanged, and no MCP process is launched by this PR alone.
  
  ## Assumptions
  
  - The selected root ID is the plugin policy identity; the manifest
  display name is presentation metadata.
  - An environment ID is a stable logical authority. Reconnection or
  replacement under the same ID does not change ownership.
  - Selected plugin packages and their manifests are trusted inputs.
  - The selected package and MCP discovery snapshot remain frozen for the
  active thread runtime.
  
  ## Follow-up
  
  The next PR installs this contributor in app-server and adds an
  end-to-end test proving that a selected plugin MCP tool launches on its
  owning executor, can be called by the model, survives an explicit MCP
  refresh, and is invisible when its root was not selected.
  
  Resume, fork, environment removal or ID changes, dynamic catalog reload,
  and executor-owned HTTP MCP placement remain separate lifecycle
  decisions.
  
  ## Verification
  
  Focused tests cover executor-only filesystem reads, missing and
  malformed config, stdio filtering and normalization, managed
  requirements, package attribution, and selection order. CI owns
  execution of the test suite.

  jif · 2026-06-15 11:52:05 +02:00
  b3c423e475
• build: run buildifier from just fmt (#28125)

  ## Intent
  
  Keep Bazel and Starlark files consistently formatted without requiring
  contributors to install or version buildifier themselves.
  
  ## Implementation
  
  - Add a SHA-256-pinned, cross-platform DotSlash manifest for buildifier
  v8.5.1.
  - Run buildifier from the shared `just fmt` and `just fmt-check` driver,
  with Windows-safe explicit DotSlash invocation.
  - Provision DotSlash in formatting CI and contributor devcontainers, and
  document the source-build prerequisite.
  - Apply the initial mechanical buildifier formatting baseline.

  Adam Perry @ OpenAI · 2026-06-13 21:43:39 -07:00
  740c4f269d
• [codex] Dedupe plugin MCPs by app declaration name (#27607)

  ## Context
  
  This is the next step in the plugin auth-routing stack. The earlier PRs
  make `PluginsManager` auth-aware and move the broad App/MCP surface
  decision into that layer. This PR narrows the ChatGPT/SIWC behavior so
  we only hide a plugin MCP server when it conflicts with an App
  declaration of the same name.
  
  In product terms: if a plugin exposes both an App route and MCP route
  for `foo`, ChatGPT/SIWC sessions should use the App route for `foo`. If
  the same plugin also exposes a separate MCP server like `foo2`, that MCP
  server should remain available.
  
  ```json
  // .app.json
  {
    "apps": {
      "foo": {
        "id": "connector_abc"
      }
    }
  }
  ```
  
  ```json
  // .mcp.json
  {
    "mcpServers": {
      "foo": {
        "url": "https://mcp.foo.com/mcp"
      },
      "foo2": {
        "url": "https://mcp.foo2.com/mcp"
      }
    }
  }
  ```
  
  ## 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
  
  - Preserve App declaration names in loaded plugin metadata.
  - Keep public effective App outputs as deduped connector IDs for
  existing callers.
  - For ChatGPT/SIWC, suppress only plugin MCP servers whose names match
  declared App names.
  
  ## Validation
  
  ```bash
  cargo fmt --all
  cargo test -p codex-core-plugins plugin_auth_projection
  cargo test -p codex-core-plugins effective_apps
  cargo test -p codex-core-plugins read_plugin_for_config_installed_git_source_reads_from_cache_without_cloning
  cargo test -p codex-core explicit_plugin_mentions_use_apps_for_chatgpt_dual_surface_plugins
  cargo test -p codex-core explicit_plugin_mentions_keep_non_conflicting_mcp_for_chatgpt_auth
  cargo test -p codex-app-server --test all plugin_install_filters_disallowed_apps_needing_auth
  git diff --check
  ```
  
  ---------
  
  Co-authored-by: Xin Lin <xl@openai.com>

  felixxia-oai · 2026-06-13 17:53:09 -07:00
  51316ead4a
• [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] Add auth mode to plugin manager constructor (#27652)

  ## Context
  
  Plugins can expose more than one way for Codex to use them: App
  connectors for ChatGPT/SIWC-backed sessions and MCP servers for API key
  login sessions. The broader goal is to make `PluginsManager` the place
  that understands which plugin surfaces should be visible for the current
  auth route, so callers do not each have to make that decision
  themselves.
  
  This PR is the small setup step for that work. It lets the plugin
  manager be created with the current `AuthMode`, which gives the followup
  auth routing PRs the information they need without relying on setter
  injection.
  
  ## 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
  
  - Let `PluginsManager::new_with_restriction_product` accept an initial
  `AuthMode`.
  - Keep `PluginsManager::new` behavior unchanged for ordinary callers.
  
  ## Validation
  
  ```bash
  cargo test -p codex-core-plugins plugins_manager_tracks_auth_mode
  cargo test -p codex-core list_tool_suggest_discoverable_plugins
  git diff --check
  ```
  
  ---------
  
  Co-authored-by: Xin Lin <xl@openai.com>

  felixxia-oai · 2026-06-12 18:00:31 -07:00
  aef40ad91f
• [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
• [codex] make PathUri::from_abs_path infallible (#27976)

  ## Why
  
  `PathUri::from_abs_path` can fail for absolute paths that do not have a
  normal `file:` URI representation, forcing filesystem call sites to
  handle a conversion error even though the original path can be preserved
  losslessly.
  
  ## What
  
  Make `from_abs_path` infallible and migrate its callers. Unrepresentable
  paths use `file:///%00/bad/path/<base64>`, encoding Unix bytes or
  Windows UTF-16LE; `to_abs_path` validates and decodes that fallback. The
  leading encoded null reserves a namespace that cannot collide with a
  real Unix or Windows path, and fallback URIs remain opaque to lexical
  path operations.
  
  ## Validation
  
  Added path-URI coverage for Unix null and non-UTF-8 paths, Windows
  device/verbatim and non-Unicode paths, serialization, malformed
  fallbacks, opaque lexical operations, invalid native payloads, and
  literal `/bad/path` collision resistance.

  Adam Perry @ OpenAI · 2026-06-12 16:58:42 -07:00
  968a3ac9c1
• [codex] Add size to internal filesystem metadata (#27927)

  ## Why
  
  `ExecutorFileSystem::get_metadata` reports file kind and timestamps but
  not size. Internal callers that need to enforce a size limit therefore
  have to read the complete file first, which is especially wasteful for
  remote filesystems.
  
  This adds the missing internal metadata so consumers can reject
  oversized files before transferring or buffering them. The field is
  named `size`, matching VS Code's `FileStat.size` filesystem convention.
  
  ## What changed
  
  - add `size: u64` to internal `FileMetadata`
  - populate it from the underlying filesystem metadata
  - carry it through sandbox-helper and remote exec-server responses
  - cover files, directories, symlink targets, and sandboxed reads across
  local and remote filesystem implementations
  
  The new field is intentionally not exposed through the app-server API.
  
  ## Testing
  
  - `just test -p codex-exec-server get_metadata`
  - `just test -p codex-exec-server
  file_system_sandboxed_metadata_and_read_allow_readable_root`
  - `just test -p codex-core-plugins`
  - `just test -p codex-skills-extension`

  pakrym-oai · 2026-06-12 12:12:08 -07:00
  76d8f20241
• [codex] expose remote plugin share URL (#27890)

  ## Summary
  
  - expose the remote plugin detail endpoint's `share_url` as nullable
  `PluginDetail.shareUrl`
  - preserve existing `PluginSummary.shareContext` behavior for local and
  workspace sharing flows
  - regenerate the app-server TypeScript and JSON schema fixtures
  
  ## Why
  
  The remote plugin detail response already includes a canonical
  `share_url`, but that value was not surfaced by `plugin/read` for global
  plugins. Global plugins intentionally have no `shareContext`, so using
  that model for the URL would change the semantics consumed by the
  existing share modal.
  
  ## User impact
  
  Codex clients can use `PluginDetail.shareUrl` for a remote plugin's
  copy-link action, including when the plugin is disabled by an
  administrator, without changing existing share-modal or ownership
  behavior.
  
  ## Validation
  
  - `cargo test -p codex-app-server
  plugin_read_includes_share_url_for_admin_disabled_remote_plugin`
  - `cargo test -p codex-app-server-protocol
  typescript_schema_fixtures_match_generated`
  - `cargo test -p codex-app-server-protocol
  json_schema_fixtures_match_generated`
  - `cargo fmt --all`

  Eric Ning · 2026-06-12 11:53:55 -07:00
  9600afb1a1
• Extract shared plugin MCP config parsing (#27863)

  ## Why
  
  We want a thread-selected plugin to eventually expose stdio MCP servers
  that run on the executor owning that plugin.
  
  The existing plugin MCP parser lived inside `core-plugins` and was
  coupled to the host filesystem loader. Reusing it from an executor
  provider would either duplicate MCP normalization or make the plugin
  package layer own MCP runtime semantics. This PR creates the shared
  MCP-owned boundary first.
  
  In simple terms:
  
  ```text
  plugin .mcp.json
          |
          v
  shared parser in codex-mcp
          |
          +-- Declared placement: preserve current local-plugin behavior
          |
          +-- Environment placement: produce config bound to one executor
  ```
  
  This builds on the authority-bound plugin descriptors from #27692. It
  intentionally does not discover, register, or launch executor MCP
  servers yet.
  
  ## What changed
  
  - Moved plugin MCP file parsing and normalization from `core-plugins`
  into `codex-mcp`.
  - Kept support for both existing file shapes: a top-level server map and
  an object containing `mcpServers`.
  - Kept per-server failure isolation: one invalid server does not discard
  valid siblings, while malformed top-level JSON still fails the whole
  file.
  - Updated the existing local plugin loader to use `Declared` placement,
  preserving its current transport, OAuth, relative `cwd`, and error
  behavior.
  - Added `Environment` placement for the next stacked PR:
  - the selected environment ID overrides anything declared by the plugin;
    - missing stdio `cwd` defaults to the plugin root;
  - relative `cwd` is resolved beneath the plugin root and cannot traverse
  outside it;
  - bare or source-less environment-variable references resolve on a
  non-local executor;
  - explicit orchestrator environment-variable forwarding is rejected for
  executor-owned plugins.
  
  ## User impact
  
  None in this PR. Existing local plugin MCP loading follows the same
  behavior through the shared parser. The executor placement mode is not
  connected to thread startup until the follow-up registration PR.
  
  ## Assumptions
  
  - A selected capability root's environment is authoritative. A plugin
  cannot redirect its stdio process to the orchestrator or another
  executor.
  - Relative working directories belong under the plugin package root.
  Explicit absolute working directories remain valid within the owning
  environment.
  - For a non-local executor, unqualified environment-variable names refer
  to that executor. Reading an orchestrator variable requires an explicit
  contract and is rejected for now.
  - Parsing only produces normalized `McpServerConfig` values. Process
  startup remains owned by the existing MCP runtime and connection
  manager.
  
  ## Follow-ups
  
  1. Add the executor MCP provider and catalog registration: read the
  selected plugin's MCP config through the same executor filesystem,
  support stdio only, freeze the result per active thread, apply managed
  policy, and resolve name collisions as discovered plugin < selected
  plugin < explicit config.
  2. Install that provider in app-server and add an end-to-end test
  proving `thread/start.selectedCapabilityRoots` launches and calls the
  MCP tool on the selected executor, preserves the frozen registration
  across refresh, and does not expose it to an unselected thread.
  3. After the initial executor-stdio vertical, define
  resume/fork/environment-replacement semantics, executor HTTP placement,
  warning delivery, common MCP tool-context bounds, and move remaining MCP
  source composition above core.
  
  ## Verification
  
  - `cargo check -p codex-mcp -p codex-core-plugins --tests`
  - `just bazel-lock-check`
  - Added focused parser coverage for legacy local normalization, executor
  authority, working-directory handling, and environment-variable
  sourcing.

  jif · 2026-06-12 15:10:05 +02:00
  17b9f4843e
• Add executor-owned plugin resolution (#27692)

  ## Why
  
  CCA can select a capability root that lives in an executor environment,
  but
  Codex only had a host-filesystem plugin loader. Before selected executor
  plugins can contribute MCP servers, we need a small package boundary
  that can
  answer:
  
  > Does this selected root contain a plugin, and if so, what does its
  manifest
  > declare?
  
  The answer must come from the selected environment's filesystem. A
  failed
  executor lookup must never fall back to the orchestrator filesystem.
  
  ## What this changes
  
  This PR introduces:
  
  ```rust
  PluginProvider::resolve(root)
      -> Result<Option<ResolvedPlugin>, Error>
  ```
  
  `ExecutorPluginProvider` resolves one `SelectedCapabilityRoot` through
  its
  exact `environment_id`. It checks the recognized manifest locations,
  reads the
  manifest through that environment's `ExecutorFileSystem`, and returns an
  inert
  `ResolvedPlugin` containing:
  
  - the opaque selected-root ID;
  - the environment-bound plugin root;
  - the authority-bound manifest resource;
  - parsed metadata and authority-bound component locators.
  
  Descriptor construction rejects manifest or component paths outside the
  selected package root, so consumers cannot accidentally lose the package
  boundary when they receive a resolved plugin.
  
  If the root has no plugin manifest, resolution returns `None`, allowing
  the
  caller to treat it as a standalone capability such as a skill.
  
  ```text
  selected root: repo -> env-1:/workspace/repo
                           |
                           | env-1 filesystem only
                           v
               .codex-plugin/plugin.json
                           |
                           v
          ResolvedPlugin { authority, root, manifest }
  ```
  
  The existing host loader and the new executor provider now share the
  same
  manifest parser. Existing `codex-core-plugins::manifest` type paths
  remain
  available through re-exports, so host behavior and callers are
  unchanged.
  
  ## Scope
  
  This is intentionally a non-user-visible package-resolution PR. It does
  not:
  
  - parse or register plugin MCP server configurations;
  - activate skills, connectors, hooks, or MCP servers;
  - change app-server wiring;
  - introduce host fallback, caching, or lifecycle behavior.
  
  #27670 has merged, and this PR is now based directly on `main`. Together
  with
  the resolved MCP catalog from #27634, it establishes the inputs needed
  for the
  executor stdio MCP vertical without changing the existing MCP runtime.
  
  ## Follow-up
  
  The next PR will consume `ResolvedPlugin`, read its declared/default MCP
  config
  through the same executor filesystem, bind supported stdio servers to
  that
  environment, and feed those registrations into the resolved MCP catalog.
  An
  app-server E2E will prove that selecting an executor plugin exposes and
  invokes
  its tool on the owning executor.
  
  Resume/fork semantics, dynamic environment replacement, and non-stdio
  placement remain separate lifecycle decisions.
  
  ## Validation
  
  - `just fmt`
  - `cargo check --tests -p codex-plugin -p codex-core-plugins`
  - `just bazel-lock-check`
  - `git diff --check`
  
  Test targets were compiled but not executed locally; CI will run the
  test and
  Clippy suites.

  jif · 2026-06-12 13:37:33 +02:00
  267eacfca2
• [codex] Propagate plugin app categories (#27420)

  ## What
  - Parse optional `.app.json` `category` overrides for plugin apps.
  - Add nullable `category` to `AppSummary` and `AppTemplateSummary` in
  the app-server protocol.
  - Fall back from `branding.category` to the first non-empty
  `app_metadata.categories` value when building app/template summaries.
  - Regenerate schema/type fixtures and update plugin read/install tests.
  
  ## Why
  The plugin details UI needs a normalized per-app category. Some apps
  only provide their default category in metadata, while others need a
  local `.app.json` override.

  charlesgong-openai · 2026-06-11 10:34:41 -07:00
  eb76336f60
• [codex] Pass auth mode to plugin manager (#27517)

  ## Summary
  - Add auth mode state to `PluginsManager`.
  - Sync the plugin manager auth mode when `ThreadManager` is created and
  when account auth changes.
  - Route plugin load outcomes through an auth-aware projection hook so
  follow-up plugin filtering can stay inside `core-plugins`.
  
  ## Motivation
  This prepares plugin capability loading to be configured by auth mode,
  such as hiding or exposing app/MCP-backed plugin surfaces based on
  whether the user is using ChatGPT auth or API-key auth, without leaking
  those details outside the plugin manager.
  
  ## Tests
  - `just fmt`
  - `just test -p codex-core-plugins`
  - `env -u CODEX_SANDBOX_NETWORK_DISABLED -u CODEX_SANDBOX just test -p
  codex-core thread_manager::tests`
  - `env -u CODEX_SANDBOX_NETWORK_DISABLED -u CODEX_SANDBOX just test -p
  codex-app-server`

  xl-openai · 2026-06-10 20:57:35 -07:00
  856855914f
• [codex] Skip local curated discovery for remote plugins (#27311)

  ## Summary
  
  - skip the local `openai-curated` marketplace before marketplace loading
  when tool-suggest discovery uses remote plugins
  - preserve existing marketplace listing behavior for all other callers
  and when remote plugins are disabled
  - add regression coverage proving the curated marketplace is excluded
  before its malformed manifest can be read
  
  ## Why
  
  Tool-suggest discovery previously loaded every local `openai-curated`
  plugin manifest and only discarded that marketplace afterward when
  remote plugins were enabled. The remote catalog is used in that mode, so
  the local scan consumed CPU without contributing discoverable plugins.
  
  ## Impact
  
  Remote-plugin tool suggestion discovery no longer reads the local
  curated marketplace and its plugin manifests. `openai-bundled`,
  configured marketplaces, normal `plugin/list` behavior, and local
  curated discovery when remote plugins are disabled are unchanged.
  
  ## Validation
  
  - `just test -p codex-core-plugins
  list_marketplaces_can_skip_openai_curated_before_loading`
  - `just test -p codex-core
  list_tool_suggest_discoverable_plugins_omits_openai_curated_when_remote_enabled`
  - `just fmt`
  - `git diff --check`

  xl-openai · 2026-06-10 13:11:09 -07:00
  7011044c1c
• [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
• fix: use plugin service route for remote uninstall (#27223)
  Eric Ning · 2026-06-09 12:52:05 -07:00
  7a7cee1be4
• [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
• Use server app auth requirements for remote plugin install (#27085)

  ## Summary
  - request `includeAppsNeedingAuth=true` when installing remote plugins
  - return backend-provided `app_ids_needing_auth` from the remote install
  client
  - use those app IDs to populate `appsNeedingAuth` without refetching
  accessible apps, with fallback for older responses
  
  ## Testing
  - `just fmt`
  - `just test -p codex-app-server`
  - `just test -p codex-core-plugins`
  - real app-server install/uninstall check with Notion remote plugin
  - subagent review found no blocking issues

  xl-openai · 2026-06-08 21:39:35 -07:00
  14660c22d1
• Use cached remote plugin catalog for plugin list (#26932)

  ## Summary
  
  This changes the default remote plugin marketplace listing to use the
  cached global remote catalog when it is already present on disk. The
  foreground `plugin/list` response can then return from the local catalog
  cache instead of waiting on `/ps/plugins/list`.
  
  When a cached global catalog was present at the start of the request,
  `plugin/list` still schedules a background refresh through the existing
  plugin-list background task path so the disk cache is updated for future
  requests. Cache misses keep the existing synchronous remote fetch path
  and write the cache, and they do not schedule an extra duplicate
  background `/ps/plugins/list` refresh.
  
  Installed/enabled state continues to come from the existing remote
  installed overlay path. This change only affects the global remote
  catalog directory data used by `plugin/list`.
  
  ## Testing
  
  - `just fmt`
  - `just test -p codex-app-server
  plugin_list_uses_cached_global_remote_catalog_and_refreshes_it`
  - `just test -p codex-core-plugins`
  - `git diff --check`

  xl-openai · 2026-06-08 14:47:09 -07:00
  381f0de531
• [codex] Prune stale curated plugin caches (#26934)

  Curated plugin startup refresh now removes cached plugins whose names no
  longer appear in the raw openai-curated marketplace. This prevents users
  with the old standalone Google Sheets plugin selected locally from
  continuing to load its stale cache after the curated repo drops it.
  
  Existing config is left untouched, and plugins still present in the
  marketplace continue to refresh from local curated sources.
  
  Validation:
  - `just fmt`
  - `just test -p codex-core-plugins`
  - `git diff --check`

  xl-openai · 2026-06-08 14:46:59 -07:00
  daf76a57d2
• fix(core-plugins): send Codex product SKU to plugin-service (#26804)
  Eric Ning · 2026-06-06 14:03:00 -07:00
  cdc8ec065e
• [codex] Remove legacy remote plugin startup sync (#25936)

  ## Summary
  
  - Remove the legacy startup remote plugin sync path that called
  `/plugins/list` and reconciled curated plugin cache/config.
  - Remove the `sync_plugins_from_remote` API, its result/error types,
  startup marker task, and tests that expected the legacy request.
  - Keep the current remote installed bundle sync and remote catalog flows
  (`/ps/plugins/installed` and `/ps/plugins/list`) intact.
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `env HOME=/private/tmp/codex-xin-build-home
  USERPROFILE=/private/tmp/codex-xin-build-home just test -p
  codex-core-plugins`
  - Searched for legacy `/plugins/list` sync references; remaining matches
  are `/ps/plugins/list` catalog tests/code.
  
  ## Notes
  
  - `just test -p codex-app-server plugin_list` is currently blocked
  before running filtered tests by an unrelated compile error in
  `app-server/tests/suite/v2/image_generation.rs`:
  `app_test_support::McpProcess` is not exported.

  xl-openai · 2026-06-05 16:33:01 -07:00
  4f655bc3b7
• [codex] Bound WSL local curated discovery (#26669)

  ## Context
  The installed-app suggestion expansion added in #24996 reads plugin
  details for trusted file-backed marketplace candidates because the list
  response does not include app ids. On Windows-backed WSL mounts, the
  local `openai-curated` checkout lives under `$CODEX_HOME/.tmp/plugins`,
  and those per-plugin detail reads can be very slow.
  
  Remote curated already has cached app ids, so it does not need the same
  local filesystem traversal.
  
  ## Summary
  - Keep only the WSL Windows-backed local `openai-curated` checkout on
  the legacy fallback/configured discovery path.
  - Preserve installed-app expansion for non-WSL file-backed marketplaces
  and remote curated.
  - Add focused tests for the WSL local curated path predicate.
  
  ## Test
  - `just test -p codex-core-plugins discoverable`
  - `just test -p codex-core plugins::discoverable::tests`

  xl-openai · 2026-06-05 14:09:40 -07:00
  679cc08445
• Speed up TUI startup by reusing plugin discovery (#26469)

  ## Summary
  
  TUI startup loads related plugin data from `hooks/list`, session MCP
  initialization, and plugin skill warmup. These paths repeated filesystem
  discovery and emitted the same plugin warnings, while `hooks/list` and
  account/model bootstrap ran serially.
  
  This change:
  
  - Reuses one immutable plugin load outcome across startup consumers.
  - Keys the cache only on plugin-relevant configuration.
  - Single-flights concurrent plugin loads and prevents invalidated loads
  from repopulating the cache.
  - Runs hook discovery and account/model bootstrap concurrently.
  - Preserves configuration-migration ordering, hook review behavior, and
  accurate startup telemetry.
  
  In 10 alternating release-build launches in the Ruff repository with the
  existing `~/.codex` configuration, median time to the first editable
  composer decreased from 833ms to 504ms. The branch was faster in 9 of 10
  pairs, with a paired median improvement of 312ms.

  Charlie Marsh · 2026-06-05 15:32:43 -04:00
  055c7a7c53
• Pull plugin service less frequently (#26431)

  # Summary
  Reduce download traffic to `github.com/openai/plugins` while continuing
  to check for updates on every Codex startup.
  
  # Root cause
  The startup sync replaced the local repository with a fresh shallow
  clone whenever the remote revision changed. At Codex's global scale,
  repeatedly downloading the repository created excessive GitHub traffic.
  
  # Changes
  - Run `git ls-remote` on each startup to read the remote HEAD SHA.
  - Skip all repository downloads when the local and remote SHAs match.
  - Update existing checkouts with an exact-SHA shallow `git fetch`,
  followed by reset and clean.
  - Bootstrap new installations with `git init` plus the same shallow
  fetch, rather than cloning.
  - Keep the existing file lock so concurrent Codex processes serialize
  updates and do not duplicate fetches.
  - Preserve the existing GitHub HTTP and export archive fallback
  behavior.
  
  # Impact
  Each startup makes one lightweight remote HEAD check. Repository objects
  are downloaded only when the revision changes, and existing Git objects
  are reused during updates.
  
  # Validation
  - `just test -p codex-core-plugins startup_sync` (15 tests passed)
  - `just test -p codex-core-plugins` (201 tests passed)
  - `just clippy -p codex-core-plugins` (passes with one pre-existing
  `large_enum_variant` warning)
  - Production app-server smoke test against GitHub:
    - Fresh home: `ls-remote`, `git init`, one exact-SHA shallow fetch
  - Unchanged restart: `ls-remote` and local `rev-parse` only; no fetch or
  clone
  - Bench smoke passed

  beggers-openai · 2026-06-04 17:47:58 -07:00
  72d0bfb6ba
• [codex] Expose unavailable app templates in plugin detail (#26317)

  ## Summary
  - Adds `unavailable_app_templates` to the app-server protocol and
  generated schemas/types.
  - Parses plugin-service `release.unavailable_app_templates` in the
  remote plugin client.
  - Maps remote unavailable templates into app-server `PluginDetail`.
  - Defaults local plugins to an empty unavailable app template list.
  
  ## Validation
  - `just write-app-server-schema`
  - `cargo +1.95.0 fmt --manifest-path codex-rs/Cargo.toml --all --check`
  - `cargo +1.95.0 test --manifest-path codex-rs/Cargo.toml -p
  codex-app-server-protocol schema_fixtures`
  - `cargo +1.95.0 check --manifest-path codex-rs/Cargo.toml -p
  codex-app-server-protocol -p codex-core-plugins -p codex-app-server`
  - `git diff --check`
  
  Note: default `cargo check` uses rustc 1.89 locally and failed because
  dependencies require newer Rust, so validation was rerun with installed
  Rust 1.95.

  charlesgong-openai · 2026-06-04 23:42:27 +00:00
  b9ff450902
• fix(app-server): expose remote MCP servers in plugin read (#26453)

  ## Why
  
  Remote plugin detail responses include MCP server metadata under
  `release.mcp_servers`, but Codex did not deserialize or propagate that
  field. As a result, `plugin/read` always returned an empty `mcpServers`
  list for remote plugins, so the plugin details pane omitted the MCP
  Servers section even when the remote plugin declares one.
  
  This affects uninstalled plugins as well: the remote detail API is the
  source of truth and returns MCP server keys without requiring a local
  plugin bundle.
  
  ## What changed
  
  - Deserialize MCP server entries from remote plugin detail responses.
  - Normalize their keys into a sorted, deduplicated list on
  `RemotePluginDetail`.
  - Return those keys from app-server `plugin/read` instead of hardcoding
  an empty list.
  - Add regression coverage proving an uninstalled remote plugin returns
  its MCP server names.
  
  ## Test plan
  
  - `just test -p codex-core-plugins`
  - `just test -p codex-app-server plugin_read`

  Eric Ning · 2026-06-04 22:10:24 +00:00
  769c231aa1
• Load plugin hooks without other plugin capabilities (#26272)

  ## Summary
  
  `hooks/list` only consumes plugin hook declarations, but previously
  loaded every enabled plugin's skills, MCP configuration, apps, and
  capability summary before discarding them.
  
  In a local benchmark, this reduced `hooks/list` latency by over 100ms
  (e.g., from 594 to 467ms on startup, and 168 to 16ms when making a
  `hooks/list` call later in the same TUI session). This is on the
  critical path to rendering the TUI, so every 10s of ms should be eyed
  skeptically (IMO).
  
  This change adds a hook-specific plugin loading path that preserves
  plugin enablement, remote/local conflict resolution, deterministic
  ordering, manifest resolution, and hook-loading warnings while skipping
  unrelated capabilities. (I think there's room for a more general design
  here that allows you to project the capabilities you need at load-time,
  but that seems unnecessary right now.)

  Charlie Marsh · 2026-06-04 11:21:40 -04:00
  4ae7930f58
• Preserve remote plugin default prompts (#25887)

  ## Summary
  
  - Read `default_prompts` from remote plugin release metadata.
  - Prefer the plural prompt list over legacy `default_prompt`.
  - Fall back to `default_prompt` as a single-item list for backward
  compatibility.
  
  ## Testing
  
  - `just test -p codex-core-plugins`
  - `just test -p codex-app-server`

  Eric Ning · 2026-06-03 12:39:13 -07:00
  aeac226d16
• 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
• [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
• Handle invalid plugin skills manifest field (#25717)

  ## Summary
  - Treat invalid `plugin.json` `skills` shapes as a field-level warning
  instead of rejecting the whole manifest
  - Keep valid string path behavior unchanged and continue falling back to
  the default `skills/` root
  - Add regression coverage for array-shaped `skills`
  
  ## Tests
  - `just fmt`
  - `cargo test -p codex-core-plugins`

  xli-oai · 2026-06-01 17:19:34 -07:00
  1ad0d7aa4b
• fix: Deduplicate installed local and remote curated plugins (#25681)

  ## Summary
  - Deduplicate installed `openai-curated` and `openai-curated-remote`
  plugin conflicts by feature flag.
  - Prefer remote when remote plugins are enabled; otherwise prefer local,
  while preserving one-sided installs.
  
  ## Testing
  - `just fmt`
  - `git diff --check`
  - Targeted `just test` was blocked locally because `cargo-nextest` is
  not installed.

  xl-openai · 2026-06-01 14:27:18 -07:00
  6ae99fd35f
• Preserve plugin app manifest order (#25491)

  ## Summary
  - Preserve app declaration order when loading plugin .app.json files.
  - Keep plugin connector summaries in plugin app order after connector
  metadata is merged and filtered.
  - Add regression coverage for .app.json order and connector summary
  order.
  
  ## Validation
  - just fmt
  - just test -p codex-chatgpt
  connectors_for_plugin_apps_returns_only_requested_plugin_apps
  - just test -p codex-core-plugins
  effective_apps_preserves_app_config_order
  - just fix -p codex-core-plugins (passes with existing clippy
  large_enum_variant warning in core-plugins/src/manifest.rs)
  - just fix -p codex-chatgpt
  - just bazel-lock-update
  - just bazel-lock-check

  charlesgong-openai · 2026-06-01 11:04:21 -07:00
  9756316d89
• Avoid repeated marketplace upgrades for alternate layouts (#24320)

  Fixes #24249.
  
  ## Why
  
  Codex already supports discovering marketplaces under both
  `.agents/plugins/marketplace.json` and
  `.claude-plugin/marketplace.json`. The Git marketplace auto-upgrade
  no-op check only looked for the `.agents` layout. That meant an
  installed `.claude-plugin` marketplace with matching revision metadata
  still looked absent, so plugin list/startup upgrade work could stage and
  re-activate the same marketplace again.
  
  That matches the failure shape in #24249: the report called out repeated
  marketplace sync/cache refresh logs and a large recently-touched
  `.tmp/marketplaces/.staging` directory. This change makes the
  auto-upgrade path recognize the installed `.claude-plugin` marketplace
  as already current, which should remove that staging/activation feedback
  loop.
  
  ## What changed
  
  `codex-rs/core-plugins/src/marketplace_upgrade.rs` now uses the existing
  supported marketplace manifest discovery helper when deciding whether an
  installed Git marketplace is already current. Existing local plugin
  source validation is unchanged; `source: "./"` still remains invalid.
  
  ## Confidence
  
  Confidence is high that this fixes the repeated marketplace upgrade
  path: the old hardcoded layout check was definitely wrong for installed
  `.claude-plugin` marketplaces, and the reported staging churn points
  directly at that path.
  
  Confidence is not 100% because we do not have a CPU profile or a fully
  re-run reporter repro. A malformed marketplace entry can still be logged
  as invalid if another caller repeatedly lists plugins; this PR fixes the
  staging/upgrade feedback loop that likely made the failure pathological,
  not every possible source of repeated marketplace resolution.

  Eric Traut · 2026-05-26 14:40:06 -07:00
  414561294c
• fix: plugin bundle archive handling for upload and install (#23983)

  Move plugin tar.gz packing and unpacking into a shared core-plugins
  archive helper so uploaded bundles are decoded through the same tar
  handling used for installs. This removes duplicate archive logic,
  supports GNU long-name entries on extraction, and keeps size, traversal,
  link, and entry-type checks in one place.

  xl-openai · 2026-05-22 19:31:39 -07:00
  7d47056ea4
• fix: Allow plugin skills to share plugin-level icon assets (#23776)

  Thread the plugin root through plugin skill loading so skill interface
  icons can reference shared plugin assets, such as ../../assets/logo.svg.

  xl-openai · 2026-05-21 16:11:59 -07:00
  247e22a9f6
• Remove plugin hooks feature flag (#22552)

  # Why
  
  This is a follow-up stacked on top of the `plugin_hooks` default-on
  change. Once we are comfortable making plugin hooks part of the normal
  plugin behavior, the separate feature flag stops buying us much and
  leaves extra branching/cache state behind.
  
  # What
  
  - remove the `PluginHooks` feature and generated config-schema entries
  - make plugin hook loading/listing follow plugin enablement directly
  - drop plugin-manager cache/state that only existed to distinguish
  hook-flag toggles
  - remove tests and fixtures that modeled `plugin_hooks = true/false`

  Abhinav · 2026-05-21 19:15:18 +00:00
  24faf49b2a
• Route MCP servers through explicit environments (#23583)

  ## Summary
  - route each configured MCP server through an explicit per-server
  `environment_id` instead of a manager-wide remote toggle
  - default omitted `environment_id` to `local`, resolve named ids through
  `EnvironmentManager`, and fail only the affected MCP server when an
  explicit id is unknown
  - keep local stdio on the existing local launcher path for now, while
  named-environment stdio uses the selected environment backend and
  requires an absolute `cwd`
  - allow local HTTP MCP servers to keep using the ambient HTTP client
  when no local `Environment` is configured; named-environment HTTP MCPs
  use that environment's HTTP client
  
  ## Validation
  - devbox Bazel build: `bazel build --bes_backend= --bes_results_url=
  //codex-rs/cli:codex //codex-rs/rmcp-client:test_stdio_server
  //codex-rs/rmcp-client:test_streamable_http_server`
  - devbox app-server config matrix with real `config.toml` /
  `environments.toml` files covering omitted local, explicit local,
  omitted local under remote default, explicit remote stdio, local HTTP
  without local env, explicit remote HTTP, local stdio without local env,
  unknown explicit env, and remote stdio without `cwd`

  starr-openai · 2026-05-21 17:19:54 +02:00
  298e5cfce1
• [codex] List marketplaces considered by plugin discovery

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

  Casey Chow · 2026-05-20 19:17:46 -04:00
  60b45d92d9
• feat(plugins): tabulate plugin list output (#23727)

  ## Summary
  - render `codex plugin list` as one table per marketplace with the
  marketplace manifest path shown above each table
  - surface the installed plugin version in the CLI output by threading
  `installed_version` through marketplace listing state
  - narrow the system-root exemption so only known bundled/runtime
  marketplaces skip missing-manifest failures, and keep `VERSION` empty
  for cached-but-unconfigured plugins
  
  ## Rationale
  The plugin list UX was hard to scan as a flat list and did not show
  which installed version was active. This change makes the CLI output
  easier to read in the real multi-marketplace case, keeps the plugin path
  visible, fixes the Sapphire regression where bundled/runtime marketplace
  roots were blocking `plugin list`, and addresses the two review findings
  that came out of the follow-up deep review.
  
  ## Key Decisions
  - kept the CLI output grouped per marketplace instead of one global
  table so the marketplace path can live with the rows it owns
  - kept `VERSION` as the installed version, which means it is empty until
  a plugin is actually installed
  - handled the bundled/runtime regression in the CLI snapshot validation
  path rather than widening app-server protocol or changing marketplace
  loading behavior
  - narrowed the exemption to known system marketplace names plus expected
  system paths, so user-configured marketplaces under those directories
  still fail loudly
  - gated `installed_version` on actual installed state so `VERSION`
  cannot show stale cache state for `not installed` rows
  
  ## Validation
  - `just fmt`
  - Sapphire: `cargo test -p codex-cli --test plugin_cli` (`14 passed; 0
  failed`)
  - Sapphire smoke test: bundled/runtime roots still work
    - `cargo run -q -p codex-cli -- plugin add sample@debug`
    - `cargo run -q -p codex-cli -- plugin list`
  - verified the bundled/runtime-root scenario no longer errors and shows
  the expected marketplace table output
  - Sapphire smoke test: custom marketplace under bundled path still
  errors
  - verified `failed to load configured marketplace snapshot(s)` for
  `custom-marketplace`
  - Sapphire smoke test: cached-but-unconfigured plugin hides version
  - verified `sample@debug not installed` renders with an empty `VERSION`
  column
  
  ## Sample Output
  ```text
  /tmp/custom-marketplace/plugin.json
  NAME          VERSION  STATUS         DESCRIPTION
  sample@debug  1.0.0    enabled        Debug sample plugin
  other@local            not installed  Local development plugin
  ```

  Casey Chow · 2026-05-20 18:04:49 -04:00
  3075061bdd
• feat: Add vertical remote plugin collection support (#23584)

  - Adds an explicit vertical marketplace kind for plugin/list that
  fail-open fetches collection=vertical only when full remote plugins are
  disabled.
  
  - Renames the global remote marketplace/cache identity to
  openai-curated-remote and materializes remote installs with backend
  release versions and app manifests.

  xl-openai · 2026-05-19 22:03:08 -07:00
  dc255b0d8a
• fix(plugins): keep version upgrades additive (#23356)

  ## Why
  
  Windows can reject plugin cache upgrades when a running MCP server still
  has its working directory inside the currently active plugin version.
  The existing cache refresh path replaces
  `plugins/cache/<marketplace>/<plugin>` as a whole, so a live handle
  under the old version can make an otherwise ordinary version bump fail.
  
  This PR keeps the existing plugin-selection model intact while making
  version bumps less disruptive.
  
  ## What changed
  
  - When installing a new version beside an existing plugin cache root,
  move only the staged version directory into place instead of replacing
  the whole plugin root.
  - Best-effort prune older sibling version directories after the new
  version is activated.
  - Preserve the existing whole-root replacement path for first installs
  and same-version refreshes.
  - Add regression coverage for upgrading from `1.0.0` to `2.0.0` without
  replacing the plugin root.
  
  ## Verification
  
  - `cargo test -p codex-core-plugins install_with_new_version`
  - `cargo fmt --package codex-core-plugins --check`

  iceweasel-oai · 2026-05-19 04:02:30 +00:00
  d3d38159ed
• [codex] Add installed-plugin mention API (#22448)

  ## Summary
  - add app-server `plugin/installed` for mention-oriented plugin loading
  - return installed plugins plus explicitly requested install-suggestion
  rows
  - keep remote handling on installed-state data instead of the broad
  catalog listing path
  
  ## Why
  The `@` mention surface only needs plugins that are usable now, plus a
  small product-approved set of install suggestions. It does not need the
  full catalog-shaped `plugin/list` payload that the Plugins page uses.
  
  ## Validation
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core-plugins`
  - `cargo test -p codex-app-server --test all plugin_installed_`
  
  ## Notes
  - The package-wide `cargo test -p codex-app-server` run still hits an
  existing unrelated stack overflow in
  `in_process::tests::in_process_start_clamps_zero_channel_capacity`.
  - Companion webview PR: https://github.com/openai/openai/pull/915672

  xli-oai · 2026-05-18 03:11:54 -07:00
  da14dd2add
• Support explicit MCP OAuth client IDs (#22575)

  ## Why
  Some MCP OAuth providers require a pre-registered public client ID and
  cannot rely on dynamic client registration. Codex already supports MCP
  OAuth, but it had no way to supply that client ID from config into the
  PKCE flow.
  
  ## What changed
  - add `oauth.client_id` under `[mcp_servers.<server>]` config, including
  config editing and schema generation
  - thread the configured client ID through CLI, app-server, plugin login,
  and MCP skill dependency OAuth entrypoints
  - configure RMCP authorization with the explicit client when present,
  while preserving the existing dynamic-registration path when it is
  absent
  - add focused coverage for config parsing/serialization and OAuth URL
  generation
  
  ## Verification
  - `cargo test -p codex-config -p codex-rmcp-client -p codex-mcp -p
  codex-core-plugins`
  - `cargo test -p codex-core blocking_replace_mcp_servers_round_trips
  --lib`
  - `cargo test -p codex-core
  replace_mcp_servers_streamable_http_serializes_oauth_resource --lib`
  - `cargo test -p codex-core config_schema_matches_fixture --lib`
  
  ## Notes
  Broader local package runs still hit unrelated pre-existing stack
  overflows in:
  - `codex-app-server::in_process_start_clamps_zero_channel_capacity`
  -
  `codex-core::resume_agent_from_rollout_uses_edge_data_when_descendant_metadata_source_is_stale`

  Matthew Zeng · 2026-05-14 11:52:43 -07:00
  d8ddeb6869
• feat: add layered --profile-v2 config files (#17141)

  ## Why
  
  `--profile-v2 <name>` gives launchers and runtime entry points a named
  profile config without making each profile duplicate the base user
  config. The base `$CODEX_HOME/config.toml` still loads first, then
  `$CODEX_HOME/<name>.config.toml` layers above it and becomes the active
  writable user config for that session.
  
  That keeps shared defaults, plugin/MCP setup, and managed/user
  constraints in one place while letting a named profile override only the
  pieces that need to differ.
  
  ## What Changed
  
  - Added the shared `--profile-v2 <name>` runtime option with validated
  plain names, now represented by `ProfileV2Name`.
  - Extended config layer state so the base user config and selected
  profile config are both `User` layers; APIs expose the active user layer
  and merged effective user config.
  - Threaded profile selection through runtime entry points: `codex`,
  `codex exec`, `codex review`, `codex resume`, `codex fork`, and `codex
  debug prompt-input`.
  - Made user-facing config writes go to the selected profile file when
  active, including TUI/settings persistence, app-server config writes,
  and MCP/app tool approval persistence.
  - Made plugin, marketplace, MCP, hooks, and config reload paths read
  from the merged user config so base and profile layers both participate.
  - Updated app-server config layer schemas to mark profile-backed user
  layers.
  
  ## Limits
  
  `--profile-v2` is still rejected for config-management subcommands such
  as feature, MCP, and marketplace edits. Those paths remain tied to the
  base `config.toml` until they have explicit profile-selection semantics.
  
  Some adjacent background writes may still update base or global state
  rather than the selected profile:
  
  - marketplace auto-upgrade metadata
  - automatic MCP dependency installs from skills
  - remote plugin sync or uninstall config edits
  - personality migration marker/default writes
  
  ## Verification
  
  Added targeted coverage for profile name validation, layer
  ordering/merging, selected-profile writes, app-server config writes,
  session hot reload, plugin config merging, hooks/config fixture updates,
  and MCP/app approval persistence.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-14 15:16:15 +02:00
  deedf3b2c4
• Relax remote plugin sync gate (#22594)

  ## Summary
  - Allow remote installed-plugin cache refresh to start whenever plugins
  are enabled.
  - Allow remote installed-plugin bundle sync to start whenever plugins
  are enabled.
  - Remove the extra local `remote_plugin_enabled` guard from those
  background sync paths.
  
  ## Context
  Server-side installed plugin state and optional bundle URL behavior are
  owned by plugin-service `/public/plugins/installed`, so these local sync
  paths only need the overall plugin enablement gate.
  
  ## Test plan
  - `just fmt`
  - `cargo test -p codex-core-plugins`

  xli-oai · 2026-05-14 03:38:30 +00:00
  9797296564