123 Commits

• [plugins] Add dark-mode logo metadata (#29488)

  Adds additive dark-mode plugin logo metadata across manifests, remote
  catalogs, and the app-server protocol while keeping uninstalled Git
  listings free of synthetic local paths.
  
  Supersedes #28945. This replacement uses an upstream branch so trusted
  CI can use the repository-provided remote Bazel configuration.
  
  ## Current state
  
  Plugin interfaces expose only the default logo asset. Clients therefore
  cannot select a dedicated dark-mode logo even when a plugin provides
  one.
  
  ## What this PR changes
  
  - Adds nullable `logoDark` and `logoUrlDark` fields to
  `PluginInterface`.
  - Resolves local `interface.logoDark` assets and maps remote
  `logo_url_dark` values.
  - Removes path-backed interface assets, including `logoDark`, from
  uninstalled Git fallback listings until the plugin has a real local
  root.
  - Updates the bundled plugin validator and manifest reference.
  - Regenerates the app-server JSON schemas and TypeScript types.
  
  Local manifests expose `interface.logoDark` as a package-relative asset
  path. Remote catalog responses expose `logo_url_dark`. These values map
  into separate app-server fields so clients can preserve local-path and
  remote-URL handling.
  
  ## Risk
  
  The fields are additive and nullable, so existing clients retain their
  current logo behavior. The main risks are an incomplete mapping path or
  exposing a synthetic local path for an uninstalled Git plugin.
  Local-manifest, remote-catalog, fallback-listing, protocol
  serialization, and app-server integration tests cover those paths.
  
  Spiciness: 2/5
  
  ## Testing
  
  - `just write-app-server-schema`
  - `just fmt`
  - Regression test first failed with `logo_dark` resolved to
  `/assets/logo-dark.png`, then passed after the fallback-listing fix.
  - `just test -p codex-core-plugins` (267 tests passed)
  - `just test -p codex-app-server 'suite::v2::plugin'` (114 tests passed)
  - `just test -p codex-app-server-protocol -p codex-core-plugins -p
  codex-plugin -p codex-skills` (517 tests passed before the follow-up)
  - `just test -p codex-tui plugin` (47 tests passed)
  - Validated a local plugin manifest containing `interface.logoDark` with
  the bundled validator.
  
  ## Manual verification
  
  Create a local plugin with both `interface.logo` and
  `interface.logoDark`, then call `plugin/list` or `plugin/read`. Confirm
  the response contains separate `logo` and `logoDark` paths. For a remote
  catalog entry, confirm `logoUrlDark` is populated from `logo_url_dark`.
  For an uninstalled Git marketplace entry, confirm path-backed interface
  assets remain absent until installation.
  
  Issue: N/A - coordinated maintainer change.

  Drew · 2026-06-22 16:01:27 -07:00
  2c351cb864
• [codex-core-plugins] Remote Plugin ID Persisted to File (#27669)

  ## This PR
  
  Remote plugin analytics cannot rely only on the in-memory
  installed-plugin snapshot because that snapshot is refreshed
  asynchronously after startup. This PR persists the authoritative backend
  identity alongside each cached remote plugin bundle so later consumers
  can resolve it without a network request.
  
  ### Behavior
  
  - Store Codex-owned remote installation metadata in an atomic
  `.codex-remote-plugin-install.json` sidecar under the plugin cache root.
  - Use a versioned, snake_case schema:
  
    ```json
    {
      "schema_version": 1,
      "remote_plugin_id": "plugins~Plugin_..."
    }
    ```
  
  - Write the metadata during remote bundle installation.
  - Backfill it when bundle sync finds an already-current cached bundle.
  - Clear it when a generic/local install replaces the cache.
  - Let existing uninstall and stale-cache removal delete it with the
  plugin cache root.
  - Reject unsupported schema versions rather than silently misreading
  future formats.
  
  This PR does not change analytics serialization or event behavior.
  
  ### Review surface
  
  The implementation is limited to four `codex-core-plugins` files:
  
  - `store.rs`: owns the versioned sidecar read/write/remove lifecycle.
  - `remote_bundle.rs`: persists the backend ID after a remote bundle
  install.
  - `remote/remote_installed_plugin_sync.rs`: backfills metadata for an
  already-current cached bundle.
  - Tests cover the storage lifecycle and both remote write paths.
  
  ## Testing / Validation
  
  ### Automated
  
  - `just test -p codex-core-plugins` (268 tests passed)
  - `just fix -p codex-core-plugins` passes with one pre-existing
  `large_enum_variant` warning in `manifest.rs`.
  - Coverage verifies the exact filename and JSON schema, identity
  replacement, local reinstall clearing, uninstall cleanup, remote bundle
  installation, unsupported schema rejection, and installed-plugin sync
  backfill.
  
  ### Live manual validation
  
  Validated the production app-server RPC path with an isolated temporary
  `CODEX_HOME` and the PR-built Codex binary. The app-server communicated
  over stdio and did not bind a port.
  
  Test plugin: `plugins~Plugin_b80dd84519148191a409cde181c9b3d6`
  (`build-macos-apps@openai-curated-remote`).
  
  1. Confirmed `plugin/read` initially reported the plugin uninstalled.
  2. Installed it through `plugin/install` and confirmed version `0.1.4`
  was cached.
  3. Verified
  `$CODEX_HOME/plugins/cache/openai-curated-remote/build-macos-apps/.codex-remote-plugin-install.json`
  was created beside the `0.1.4/` bundle directory with mode `0600` and
  the expected contents:
  
     ```json
     {
       "schema_version": 1,
  "remote_plugin_id": "plugins~Plugin_b80dd84519148191a409cde181c9b3d6"
     }
     ```
  
  4. Deleted only the sidecar, restarted the app-server, and confirmed
  installed-plugin startup sync recreated it with the same contents.
  5. Uninstalled through `plugin/uninstall`, confirmed `plugin/read`
  returned `installed: false`, and verified the local plugin cache root
  was removed.
  6. Restored the account's original uninstalled state and removed the
  isolated home and copied credentials.
  
  ## Split Overview
  
  ```text
  main
  ├── #27093  Debug analytics capture                     merged
  │   └── #27099  Non-mutating plugin smoke               merged
  │       └── #27100  Remote install/uninstall smoke      merged
  └── #27102  Plugin telemetry metadata refactor          merged
      └── #27669  Persist remote plugin identity           ← this PR
  
  Next:
  └── Final PR: add explicit local and remote IDs to plugin analytics
  ```
  
  This PR is based directly on `main`; prerequisite
  [#27102](https://github.com/openai/codex/pull/27102) has merged. The
  original combined [#26281](https://github.com/openai/codex/pull/26281)
  remains the aggregate reference until the final replacement PR is
  published.

  jameswt-oai · 2026-06-22 14:28:39 -07:00
  a72433d560
• [codex] Centralize Plugin Analytics Metadata (#27102)

  This PR moves construction of `PluginTelemetryMetadata` from loader and
  model helpers into `PluginsManager`, which already owns installed plugin
  state and will eventually perform remote identity enrichment. The
  metadata type remains in `codex-plugin`, and serialized analytics events
  remain unchanged.
  
  ## Before
  
  ```mermaid
  flowchart LR
      subgraph Events["Analytics event paths"]
          direction TB
          Lifecycle["Local install / uninstall"]
          Config["Enable / disable"]
          Remote["Remote install"]
          Used["Plugin used"]
      end
  
      subgraph Construction["Metadata construction"]
          direction TB
          Loader["Loader telemetry helpers"]
          Summary["PluginCapabilitySummary::telemetry_metadata"]
          Override["Caller adds remote_plugin_id"]
      end
  
      Metadata["PluginTelemetryMetadata"]
  
      Lifecycle --> Loader
      Config --> Loader
      Remote --> Loader
      Loader -->|"local events"| Metadata
      Loader -->|"remote install"| Override
      Override --> Metadata
      Used --> Summary
      Summary --> Metadata
  ```
  
  Telemetry metadata was constructed through loader helpers, a
  capability-summary method, and a remote-install call-site override.
  
  ## After
  
  ```mermaid
  flowchart LR
      subgraph Events["Analytics event paths"]
          direction TB
          Lifecycle["Local install / uninstall"]
          Config["Enable / disable"]
          Remote["Remote install"]
          Used["Plugin used"]
      end
  
      Manager["PluginsManager — single construction owner"]
      Metadata["PluginTelemetryMetadata"]
  
      Lifecycle --> Manager
      Config --> Manager
      Remote -->|"authoritative remote ID"| Manager
      Used -->|"capability summary"| Manager
      Manager --> Metadata
  ```
  
  Every analytics path delegates metadata construction to
  `PluginsManager`. Remote install still supplies its authoritative
  backend ID explicitly.
  
  ## What Changes
  
  - Make loader code return a focused plugin capability summary instead of
  constructing analytics metadata.
  - Centralize immutable plugin telemetry metadata construction in
  `PluginsManager`.
  - Route local install/uninstall, remote install, enable/disable, and
  plugin-used emitters through the manager.
  - Preserve the current serialized analytics contract exactly.
  
  Normal metadata still has no remote override. Remote install continues
  to provide its authoritative backend ID explicitly, so the existing
  serializer continues reporting that ID through `plugin_id`.
  Snapshot-based enrichment is intentionally deferred to the final PR.
  
  ## Testing
  
  - `just test -p codex-core-plugins` (238 tests passed)
  - `just test -p codex-plugin` (3 tests passed)
  - Scoped Clippy/compile checks passed for `codex-plugin`,
  `codex-core-plugins`, `codex-app-server`, and `codex-core`.
  
  ## Split Overview
  
  ```text
  main
  ├── #27093  Debug analytics capture                 (merged)
  ├── #27099  Non-mutating plugin smoke               (merged)
  ├── #27100  Remote install/uninstall smoke          (merged)
  └── #27102  Plugin telemetry metadata refactor      ← you are here
      └── #27669  Persist remote plugin identity
  
  After #27102 and #27669 merge:
  └── Final PR: add explicit local and remote IDs to plugin analytics
  ```
  
  Review order and dependencies:
  
  1. [#27093 Add debug-only analytics event
  capture](https://github.com/openai/codex/pull/27093) (merged)
  2. [#27099 Add a plugin analytics smoke
  workflow](https://github.com/openai/codex/pull/27099) (merged)
  3. [#27100 Add a remote plugin analytics mutation smoke
  workflow](https://github.com/openai/codex/pull/27100) (merged)
  4. This metadata refactor, independent and based on `main`
  5. [#27669 Persist remote plugin
  identity](https://github.com/openai/codex/pull/27669), stacked on this
  PR
  6. Final remote-ID behavior PR, created after the prerequisites merge
  
  The original [#26281](https://github.com/openai/codex/pull/26281)
  remains open as the aggregate reference until the final replacement PR
  is published.

  jameswt-oai · 2026-06-22 10:27:23 -07:00
  44dbae90eb
• [codex] Skip curated repo sync for remote plugins (#29005)

  ## Summary
  
  - skip the legacy `openai-curated` startup repository sync when remote
  plugins are enabled and the current auth uses the Codex backend
  - keep the curated sync for API-key, Bedrock, and unauthenticated
  sessions that fall back to the local marketplace
  - preserve configured marketplace upgrades and all remote plugin startup
  warmups
  
  ## Why
  
  The remote catalog owns plugin discovery and materialization only when
  it is usable for the current auth mode. Starting the legacy curated
  repository sync in that case performs an unnecessary Git/HTTP/archive
  download and cache refresh. API-key and Bedrock sessions still require
  the local curated marketplace, so they must continue syncing it.
  
  ## User impact
  
  Codex startup no longer downloads or refreshes the local
  `openai-curated` snapshot when the remote catalog is active. Behavior is
  unchanged for auth modes that use the local curated marketplace.
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  
  Rust tests were not run per the repository's local verification policy
  for this narrow conditional change.

  xl-openai · 2026-06-18 18:02:14 -07:00
  38c96866f0
• [plugins] Refresh plugin and tool caches after remote install (#28951)

  Summary
  - Refresh the installed remote-plugin snapshot and Codex Apps tools
  after completing a remote JIT install.
  - Gate `completed: true` on every expected `app_connector_id` appearing
  after the uncached `tools/list` refresh, while continuing to skip local
  bundle verification for server-side installs.
  - Keep the cached recommendations response and filter refreshed
  installed remote IDs locally, so this does not add another
  recommendations fetch.
  - Add regression coverage for tools appearing after the hard refresh and
  remaining absent after the refresh. The resumed model request sees the
  refreshed tool router when installation completes.
  
  Root Cause
  - Remote suggestions from `openai-curated-remote` returned `true` before
  taking the existing connector refresh path, leaving the resumed turn
  with the pre-install Apps tool catalog.
  
  Validation
  - `just test -p codex-core request_plugin_install`
  - `just test -p codex-core-plugins
  recommended_plugin_candidates_filter_installed_and_disabled_plugins`
  - `just test -p codex-core-plugins`
  - `just fix -p codex-core-plugins`
  - `just fix -p codex-core`
  - `just fmt`
  - `just test -p codex-core` was not fully clean locally: 2,729 passed,
  26 failed, and 16 skipped. The failures were dominated by local
  Seatbelt/network/timing issues, including plugin-install timeouts under
  full-suite contention; the focused plugin-install runs pass.

  Alex Daley · 2026-06-18 20:08:04 -04:00
  7e37354a58
• [codex] Reuse parsed plugin skills during session startup (#28844)

  ## Summary
  
  - Preserve raw plugin skill-root snapshots in the matching loaded-plugin
  cache entry, keyed by the effective plugin root identity including
  namespace.
  - Pass those snapshots through `SkillsLoadInput` as an optional preload,
  so session startup reuses plugin parsing while ordinary skill loads pass
  `None`.
  - Keep plugin skill loading cohesive: the existing loaders accept the
  optional snapshots directly, and uncached or marketplace-detail paths do
  not create a cache.
  
  ## Why
  
  Plugin discovery already parses plugin skills to determine available
  capabilities. Cold session startup then scanned and parsed the same
  roots again while building the skills snapshot.
  
  This solves the same duplicate-work problem as #28623 while keeping
  ownership narrow: `PluginsManager` creates and owns
  `PluginSkillSnapshots` only for its loaded-plugin cache entry;
  `SkillsService` consumes an optional clone. Entry replacement or
  clearing naturally drops the snapshots, with no separate generation,
  capacity policy, or watcher coupling.
  
  ## Validation
  
  - `cargo clippy -p codex-core-skills --all-targets -- -D warnings`
  - `just test -p codex-core-plugins
  skills_service_reuses_skills_parsed_during_plugin_load`
  - `just test -p codex-core-skills
  namespaces_plugin_skills_using_provided_namespace`
  - `just fmt`

  xl-openai · 2026-06-18 16:45:58 -07:00
  e83b7841b0
• [codex] Support marketplace plugin manifest fallback (#28789)

  ## Summary
  
  Support marketplace plugins whose source directory does not include a
  discoverable plugin manifest. Metadata-rich `marketplace.json` entries
  now act as fallback plugin manifests for listing, local detail reads,
  install, and non-curated cache refresh.
  
  The fallback preserves marketplace-entry plugin fields wholesale, then
  adds the small Codex-facing compatibility bridge for presentation
  metadata. A real source `plugin.json` always wins when present.
  
  ## Details
  
  - Capture flattened marketplace-entry fields into
  `MarketplacePluginManifestFallback`, preserving fields such as
  `version`, `description`, `skills`, `mcpServers`, `apps`, `hooks`,
  `agents`, `commands`, `strict`, `author`, and future manifest fields
  without a per-field translation list.
  - Bridge Claude-style top-level `displayName`, `author.name`,
  `homepage`, and marketplace `category` into Codex's nested `interface`
  fields only when the nested values are absent.
  - Treat fallback metadata as installable only when the marketplace entry
  contributes metadata beyond bare `name` and `source`; existing
  missing-manifest behavior remains for metadata-free entries.
  - Read local plugin details from the already parsed fallback manifest,
  including fallback-declared app and MCP paths, instead of rereading only
  an on-disk manifest.
  - Pass fallback contents into `PluginStore`, which validates them and
  injects `.codex-plugin/plugin.json` into Store's existing atomic copy.
  Local marketplace source directories are never mutated, and the fallback
  path no longer needs an additional staging directory.
  - Keep Git source materialization unchanged; Git clones still use the
  existing marketplace source staging area before Store installation.

  charlesgong-openai · 2026-06-18 15:49:27 -07:00
  772c5c5195
• [codex] Preserve remote plugin download status errors (#28863)

  ## Summary
  
  - preserve the original HTTP status when a remote plugin bundle download
  returns a non-success response
  - retain at most 8 KiB of the error response body and annotate
  truncation or body-read failures
  - add regression coverage for an oversized error response
  
  ## Root cause
  
  The non-success response path reused the normal size-limited body
  reader. When an error response exceeded 8 KiB, that reader returned
  `DownloadTooLarge` before the code constructed `DownloadStatus`, masking
  the upstream HTTP status and response context.
  
  ## Impact
  
  Remote plugin installation failures now retain the actionable upstream
  HTTP status without allowing unbounded error bodies into logs.
  
  ## Validation
  
  - `just test -p codex-app-server
  plugin_install_preserves_status_when_remote_bundle_error_body_is_too_large`
  - `just fmt`
  - `git diff --check`

  xl-openai · 2026-06-18 14:29:01 -07:00
  406062c3af
• [codex] Cache plugin metadata for tool suggestions (#27812)

  ## Why
  
  `built_tools` runs for every sampling request, and local plugin
  discovery was repeatedly rereading plugin manifests, skills, MCP
  configuration, and app declarations to build the same tool-suggest
  metadata.
  
  That source-derived metadata is stable until the existing plugin manager
  reloads its cache. Runtime eligibility still needs to reflect the
  current install, disable, policy, app-overlap, and authentication state.
  
  ## What changed
  
  - Add a bounded, in-memory tool-suggest metadata cache owned by
  `PluginsManager`.
  - Key cached metadata by plugin identity and source, while applying
  authentication routing each time the metadata is projected.
  - Invalidate the metadata alongside the existing loaded-plugin cache,
  including its normal configuration, marketplace refresh, and
  remote-installed-plugin invalidation paths.
  - Guard against an in-flight load repopulating stale metadata after
  invalidation.
  - Keep marketplace membership and all runtime eligibility filtering live
  rather than introducing a separate catalog or revision model.
  
  ## Impact
  
  Repeated sampling requests reuse already-loaded plugin capability
  metadata while retaining the existing plugin-manager lifecycle as the
  single freshness boundary.
  
  ## Validation
  
  - `just test -p codex-core-plugins` — 252 passed
  - Added focused coverage for cache invalidation and authentication
  reprojection.

  Matthew Zeng · 2026-06-18 12:25:07 -07:00
  a52a3b5197
• [codex] Pass plugin namespace into skill loading (#28608)

  ## What changed
  
  - retain the parsed plugin manifest namespace on loaded plugins
  - carry that namespace through `PluginSkillRoot` and `SkillRoot`
  - use the provided namespace when qualifying plugin skill names
  - include the namespace in the skills cache key
  
  ## Why
  
  Plugin loading has already parsed `plugin.json`, but skill parsing
  currently walks every `SKILL.md` ancestor and probes/reads the manifest
  again to reconstruct the same namespace. Passing the parsed namespace
  removes those repeated filesystem calls, which are particularly costly
  on remote filesystems.
  
  Context:
  https://openai.slack.com/archives/C0ARA9GF5D4/p1781639496496439?thread_ts=1781202444.891669&cid=C0ARA9GF5D4
  
  ## Impact
  
  Plugin skill names remain unchanged. A regression test uses a
  deliberately different on-disk manifest name to verify that plugin roots
  use the provided parsed namespace.
  
  ## Validation
  
  - `just test -p codex-core-skills -p codex-core-plugins -p codex-plugin
  -p codex-utils-plugins` (352 passed)
  - `just fix -p codex-core-skills -p codex-core-plugins -p codex-plugin
  -p codex-utils-plugins`
  - `just fmt`

  Matthew Zeng · 2026-06-18 00:16:46 -07:00
  c73296a0f0
• [codex] Split plugin and skill warmup tracing (#28605)

  ## What changed
  
  - promote plugin config loading to an info-level `plugins_for_config`
  span
  - promote skill config loading to an info-level `skills_for_config` span
  - attach stable OpenTelemetry names to both spans
  
  ## Why
  
  `session_init.plugin_skill_warmup` currently combines plugin loading and
  skill loading, which makes cold-start traces unable to identify which
  phase dominates. These child spans preserve the existing aggregate while
  making the two costs independently visible.
  
  Context:
  https://openai.slack.com/archives/C0ARA9GF5D4/p1781639496496439?thread_ts=1781202444.891669&cid=C0ARA9GF5D4
  
  ## Impact
  
  This is observability-only. It does not change plugin or skill loading
  behavior.
  
  ## Validation
  
  - `just test -p codex-core-skills -p codex-core-plugins` (347 passed)
  - `just fmt`

  Matthew Zeng · 2026-06-17 22:45:10 -07:00
  2c7802e7cf
• [codex] Support plugin manifest path lists (#28790)

  ## Summary
  
  Allow plugin manifests to declare `skills` as either a single path
  string or an array of path strings in the core plugin loader.
  
  ## Why
  
  Some plugin packages need to expose skills from more than one directory.
  Before this change, `plugin.json` only accepted a single string for
  `skills`, so manifests like this were ignored as an invalid `skills`
  shape:
  
  ```json
  {
    "skills": ["./skills/abc", "./skills/edk"]
  }
  ```
  
  This keeps the existing single-string form working while adding support
  for the list form. The final scope is intentionally limited to the core
  plugin manifest/load path for `skills`; `apps`, file-backed
  `mcpServers`, and the bundled plugin-creator assets are unchanged in
  this PR.
  
  ## What changed
  
  - Parse `skills` as either a string or an array of strings in
  `plugin.json`.
  - Store resolved skill paths as a list in `PluginManifestPaths`.
  - Load manifest-declared skill roots in addition to the default
  `./skills` root.
  - Deduplicate exact duplicate skill roots before loading.
  - Rely on existing skill-loader dedupe by canonical `SKILL.md` path for
  overlapping roots such as `./skills` plus `./skills/abc`.
  - Update plugin manifest tests to cover:
    - single string `skills`
    - list of string `skills`
    - duplicate skill roots
    - `./skills` as a manifest path
    - explicit child roots like `./skills/abc` and `./skills/edk`
    - overlapping-root dedupe
  
  ## Validation
  
  - `just test -p codex-plugin`
  - `just test -p codex-core-plugins`
  - `just test -p codex-mcp-extension`
  - `git diff --check`

  charlesgong-openai · 2026-06-17 21:33:53 -07:00
  e12dd73b7d
• [codex] trace tools build latency (#28782)

  Add more tracing spans around tool building.

  Owen Lin · 2026-06-17 14:53:54 -07:00
  38211a3ff8
• fix(plugins): support root local marketplace plugins (#28771)

  ## Summary
  - allow local marketplace `source.path: "."` and `source.path: "./"` to
  resolve to the marketplace root
  - keep `""` invalid and preserve rejection of non-root paths without
  `./` plus non-normal/traversal paths
  - add focused regression coverage for repo-root plugin layouts and
  rejected local paths
  
  ## Tests
  - `RUSTUP_TOOLCHAIN=stable just fmt`
  - `RUSTUP_TOOLCHAIN=stable just test -p codex-core-plugins`
  - `RUSTUP_TOOLCHAIN=stable just fix -p codex-core-plugins`
  
  Note: plain pinned-toolchain `just fmt` was blocked locally by a rustup
  `clippy` component conflict, so validation used the working stable 1.95
  toolchain fallback.

  Casey Chow · 2026-06-17 14:06:42 -07:00
  a760b63f83
• [codex] Track plugin install and import telemetry failures (#28731)

  ## Summary
  - Track plugin install failures through the unified
  `codex_plugin_install_failed` event for local installs, remote install
  preflight failures, bundle failures, and remote catalog/backend
  failures.
  - Send classified `error_type` values in plugin install failure
  analytics instead of raw error strings.
  - Stop sending raw external-agent import errors in analytics while
  preserving raw failure details in app-facing import
  notifications/history.
  - Keep raw plugin/migration diagnostics in `tracing::warn!` logs.
  - Keep remote failure plugin names as the existing local placeholder
  (`unknown`) and remove the extra telemetry plugin-name override.
  - Change `ExternalAgentConfigImportParams.source` from a generated enum
  to `string | null`, with legacy `claudeCode` / `claudeCowork` inputs
  normalized to existing analytics values.
  
  ## Testing

  charlesgong-openai · 2026-06-17 13:16:34 -07:00
  3959ab0ffc
• [codex] Support object-valued plugin MCP manifests (#28580)

  ## Summary
  This fixes plugin manifest parsing for MCP servers declared as an object
  directly in `plugin.json`.
  
  Before this change, Codex modeled `mcpServers` as only a string path,
  for example:
  
  ```json
  {
    "name": "counter-sample",
    "version": "1.1.1",
    "mcpServers": "./.mcp.json"
  }
  ```
  
  Some migrated plugins instead provide the server map directly in the
  manifest:
  
  ```json
  {
    "name": "counter-sample",
    "version": "1.1.1",
    "description": "Plugin that declares MCP servers in the manifest",
    "mcpServers": {
      "counter": {
        "type": "http",
        "url": "https://sample.example/counter/mcp"
      }
    }
  }
  ```
  
  That object form previously failed during install/load with an error
  like:
  
  ```text
  failed to parse plugin manifest: invalid type: map, expected a string
  ```
  
  ## What changed
  - Add a manifest representation for `mcpServers` as either
  `Path(Resource)` or `Object(map)`.
  - Parse `plugin.json` `mcpServers` as either a string path or an object.
  - Route object-valued MCP server maps through the existing plugin MCP
  config parser instead of adding a second parser.
  - Apply existing per-plugin MCP server policy to object-valued MCP
  servers the same way as file-backed MCP servers.
  - Include object-valued MCP server names in plugin telemetry/capability
  metadata.
  - Support object-valued MCP config for executor plugins without
  requiring a `.mcp.json` filesystem read.
  - Update the bundled plugin-creator validator and `plugin-json-spec.md`
  so generated-plugin validation accepts the same object-valued shape.
  
  ## Compatibility
  Existing plugin manifests that use `"mcpServers": "./.mcp.json"`
  continue to work. Plugins can now also use the object shape shown above.
  
  ## Tests
  Added coverage for the new manifest attribute shape at the install,
  normal load, telemetry, and executor-provider layers:
  
  - `install_accepts_manifest_mcp_server_objects`
  - `load_plugins_loads_manifest_mcp_server_objects`
  - `plugin_telemetry_metadata_uses_manifest_mcp_server_objects`
  - `reads_manifest_object_config_without_executor_file_system_access`
  
  Also smoke-tested the plugin-creator validator against both supported
  forms:
  
  - `mcpServers` as a direct object in `plugin.json`
  - `mcpServers` as `"./.mcp.json"` with a companion `.mcp.json`
  
  ## Validation
  - `just test -p codex-plugin`
  - `just test -p codex-core-plugins`
  - `just test -p codex-mcp-extension`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fmt`
  - `git diff --check`
  - Focused rename/object-form rerun: `just test -p codex-core-plugins
  manager::tests::load_plugins_loads_manifest_mcp_server_objects
  manager::tests::plugin_telemetry_metadata_uses_manifest_mcp_server_objects
  store::tests::install_accepts_manifest_mcp_server_objects`
  - Focused executor rerun: `just test -p codex-mcp-extension
  executor_plugin::provider::tests::reads_manifest_object_config_without_executor_file_system_access`
  - `python3
  codex-rs/skills/src/assets/samples/plugin-creator/scripts/validate_plugin.py
  /private/tmp/codex-validator-object`
  - `python3
  codex-rs/skills/src/assets/samples/plugin-creator/scripts/validate_plugin.py
  /private/tmp/codex-validator-path`

  charlesgong-openai · 2026-06-16 19:22:57 -07:00
  1883dedc0e
• [codex] Gate remote plugin catalog by auth (#28625)

  ## Summary
  
  - Treat the remote global plugin catalog as active only when
  `remote_plugin` is enabled and the current auth uses the Codex backend.
  - Skip the local OpenAI curated marketplace for remote-enabled ChatGPT
  users while preserving configured marketplaces.
  - Keep the local curated marketplace for API-key users, unauthenticated
  fallback, and ChatGPT users with `remote_plugin` disabled.
  - Apply the same effective-remote gate to the remote
  installed-marketplace cache.
  
  ## Root cause
  
  The tool-suggestion discovery path unconditionally included the local
  OpenAI curated marketplace. For remote-enabled ChatGPT users, that made
  remote discovery additive: Codex parsed every local curated
  `plugin.json` before also loading the remote catalog.
  
  ## Validation
  
  - `just fmt`
  - `cargo build -p codex-cli --bin codex`
  - Targeted auth/feature matrix tests pass, including API-key auth with
  `remote_plugin` enabled.
  - Manual CLI validation confirmed:
    - ChatGPT + remote off includes local curated.
    - ChatGPT + remote on excludes local curated.
    - API-key auth keeps local curated when remote is enabled.
  - `just test -p codex-core-plugins`: 235 passed; one unrelated existing
  marketplace test failed because it loaded the developer's home
  marketplace configuration.

  xl-openai · 2026-06-16 17:24:48 -07:00
  69bc0645ac
• [codex] [3/4] Activate endpoint plugin recommendations (#27704)

  Summary\n- Await endpoint recommendation selection while constructing
  each authenticated turn, removing the first-turn cache race.\n- Snapshot
  and filter endpoint candidates once per turn, then use that same set for
  the bounded contextual user fragment, tool exposure, and exact install
  validation.\n- Keep recommendation selection ephemeral: do not persist
  recommendation state in or gate resumed threads on prior context.\n-
  Hide the legacy list tool in endpoint mode and preserve legacy discovery
  unchanged when the endpoint is disabled or unavailable.\n- Keep remote
  plugin and connector app identities out of model-visible context and
  attach them only to Codex-owned elicitation metadata.\n\nStack\n- 3/4,
  based on #28400.\n- Endpoint client and cache: #28399.\n- Generalized
  suggestion presentation: #28400.\n- Install-schema follow-up:
  #28403.\n\nValidation\n- \n- \n- \n- \n- Full : 2,649 passed and 88
  environment-dependent tests failed because this sandbox cannot write ,
  nest Seatbelt, or locate auxiliary test binaries.

  Alex Daley · 2026-06-16 23:04:07 +00:00
  a34da3b295
• [codex] [1/4] Add recommended plugin endpoint cache (#28399)

  Summary
  - Add authenticated parsing for `/ps/plugins/suggested?scope=GLOBAL`,
  including remote plugin and connector app identities.
  - Validate, deduplicate, sort, and cap endpoint candidates before
  caching them by backend and account identity.
  - Deduplicate concurrent cache misses and warm recommendations from the
  existing remote-installed-plugin refresh path used at startup and after
  account changes.
  - Keep endpoint results model-invisible in this PR; failures and
  responses without `enabled: true` resolve to legacy mode.
  
  Stack
  - 1/3. Follow-up: #28400 generalizes plugin suggestion presentation
  without activating endpoint recommendations.
  - Final activation: #27704.
  
  Validation
  - `just test -p codex-core-plugins recommended_plugins`
  - `just fix -p codex-core-plugins`
  - `just fmt`
  - `git diff --check`

  Alex Daley · 2026-06-16 22:22:21 +00:00
  7e735b59ce
• [codex] exec-server: stream files in chunks (#28354)

  ## Why
  
  `fs/readFile` buffers the entire file in one response, which makes large
  remote reads expensive and prevents callers from applying backpressure.
  We need an opt-in streaming path with bounded block sizes while
  preserving the existing single-call API for small and sandboxed reads.
  
  ## What changed
  
  - Add `ExecServerClient::stream`, returning a named `FileReadStream`
  that implements `futures::Stream` and yields immutable 1 MiB byte
  blocks.
  - Add internal `fs/open`, `fs/readBlock`, and `fs/close` RPCs.
  `fs/readBlock` accepts an explicit offset and length.
  - Keep unsandboxed files open between block reads, cap open handles per
  connection, and clean them up on EOF, error, stream drop, explicit
  close, or connection shutdown.
  - Reject platform-sandboxed streaming opens instead of turning the
  one-shot sandbox helper into a persistent server. Existing `fs/readFile`
  behavior is unchanged.
  
  ## Testing
  
  - `just test -p codex-exec-server`
  - Integration coverage for 1 MiB chunking, exact block-boundary EOF,
  sandbox rejection, and continued reads from the opened file after path
  replacement.
  - Handle-manager coverage for non-sequential offsets, variable block
  lengths, the 128-handle limit, and capacity release after close.

  pakrym-oai · 2026-06-16 09:50:55 -07:00
  a4711b88dd
• [codex] Clarify plugin load and runtime capability stages (#28472)

  ## Summary
  
  Plugin loading and auth projection both previously produced
  `PluginLoadOutcome`. That made an unfiltered load result look like
  runtime-ready capabilities and generated capability summaries before
  auth routing had run.
  
  This change keeps loaded plugin records in the cache, applies the
  current auth policy in `PluginsManager`, and only then builds
  `PluginLoadOutcome` and its summaries. Auth changes still reuse the
  cached disk load and re-resolve apps and MCP servers without reloading
  plugins.
  
  The updated tests cover cached auth changes and verify that capability
  summaries match the effective app/MCP surface.
  
  ## Testing
  
  - `just test -p codex-core-plugins`
  - `just test -p codex-plugin`
  - `just fix -p codex-core-plugins`

  xl-openai · 2026-06-16 12:57:21 +01:00
  de1f77bfdd
• [codex] Make plugin details capability aware (#27958)

  ## Summary
  
  Makes plugin details/read flows capability-aware so auth-filtered plugin
  surfaces report the same usable app/MCP/skill shape as the marketplace
  and install flows.
  
  ## Validation
  
  Not run; this change was rebased onto the current plugin auth stack and
  pushed as a draft PR.
  
  **Manual test**
  1. set up a local marketplace with a plugin that has both app and mcp
  declarations
  
  ```
  // .app.json
  {
    "apps": {
      "linear": {
        "id": "some_id"
      }
    }
  }
  
  ```
  
  ```
  // .mcp.json
  {
    "mcpServers": {
      "linear": {
        "type": "http",
        "url": "https://mcp.linear.app/mcp",
        "oauth_resource": "https://mcp.linear.app/mcp"
      },
      "linear2": {
        "type": "http",
        "url": "https://mcp.linear2.app/mcp",
        "oauth_resource": "https://mcp.linear2.app/mcp"
      }
    }
  }
  ```
  
  2a. **login in with api key** and observe plugin details page which
  shows no apps (note we don't show "app not available due to api key log
  in as there's no way to differentiate between no apps and app without
  substitute mcp exists" without significantly more code changes, i've
  separated this to a follow up if we want that behaviour.
  <img width="1170" height="279" alt="Screenshot 2026-06-15 at 23 45 40"
  src="https://github.com/user-attachments/assets/d36cb160-fbec-461e-9643-9c761dbae7bb"
  />
  <img width="975" height="640" alt="Screenshot 2026-06-15 at 18 40 30"
  src="https://github.com/user-attachments/assets/90ec0bc8-7506-4b90-bbd3-070720de799e"
  />
  
  
  2b. **log in with chat** and observe intended conflict resolution logic
  <img width="1165" height="224" alt="Screenshot 2026-06-15 at 17 17 30"
  src="https://github.com/user-attachments/assets/80adfbf2-7dac-4f08-8b76-8eeeab6c95e7"
  />
  <img width="968" height="567" alt="Screenshot 2026-06-15 at 18 38 59"
  src="https://github.com/user-attachments/assets/9ea92c5e-535b-4aa4-8ad0-ee513b57bc3c"
  />

  felixxia-oai · 2026-06-16 01:25:22 +00:00
  d959664420
• [codex] Load API curated marketplace by auth (#28383)

  ## Summary
  - choose the local OpenAI curated marketplace manifest based on auth:
  Codex backend auth gets the existing marketplace, direct provider auth
  gets `api_marketplace.json`
  - include Bedrock API key auth in the direct-provider API marketplace
  path
  - safely skip the API marketplace when `api_marketplace.json` is absent
  
  ## Validation
  - `just fmt`
  - `git diff --check origin/main...HEAD`
  - CI should run the full validation
  
  ## Manual Testing
  
  ### - New api marketplace not available for API key sign
  1. Safely not display anything from api marketplace
  <img width="1161" height="289" alt="Screenshot 2026-06-15 at 21 37 43"
  src="https://github.com/user-attachments/assets/a5f16642-8a20-4ac1-a0de-1274a4c7b5b2"
  />
  
  ### - New api marketplace for API key sign in
  1. Setup api_marketplace.json
  ```
  {
    "name": "openai-curated",
    "interface": {
      "displayName": "Codex official"
    },
    "plugins": [
      {
        "name": "linear",
        "source": {
          "source": "local",
          "path": "./plugins/linear"
        },
        "policy": {
          "installation": "AVAILABLE",
          "authentication": "ON_INSTALL"
        },
        "category": "Productivity"
      }
    ]
  }
  ```
  
  2. Log in with API key, observe that only the defined plugin from
  api_marketplace.json is available from "Codex Official" (outside of
  local testing marketplaces)
  <img width="1167" height="446" alt="Screenshot 2026-06-15 at 21 16 53"
  src="https://github.com/user-attachments/assets/7cf61477-d826-4ef6-bc05-0a23ac1c0259"
  />
  
  also checked functionality on codex app
  
  ### - SiWC users 
  Still uses 'default' marketplace.json and renders all plugins
  <img width="1171" height="502" alt="Screenshot 2026-06-15 at 21 40 25"
  src="https://github.com/user-attachments/assets/d212ea9b-0aa5-470b-8ea4-450efe65bb2b"
  />
  
  also checked functionality on codex app
  
  
  ## Notes
  - `just test -p codex-core-plugins` was started locally before splitting
  branches, but I stopped relying on local tests per follow-up and left
  final validation to PR CI.

  felixxia-oai · 2026-06-16 01:16:11 +00:00
  02dce8eb8d
• [codex] Centralize plugin auth capability filtering (#27902)

  ## Summary
  
  This is the first step in making plugin auth routing consistent. The
  rule should not live as one-off checks in every place that loads or
  displays plugin capabilities.
  
  This PR introduces a small resolver for the auth-level policy: given a
  plugin's declared apps, MCP servers, current auth mode, and active
  state, return the capabilities that are actually usable in that context.
  
  ## Why
  
  Product rule:
  - SiWC auth can use app connectors, so app declarations stay available.
  - API-key/direct auth cannot use app connectors, so app declarations are
  removed.
  - When an active plugin has both an app and an MCP server with the same
  name, the app route wins for Codex-backed auth and the conflicting MCP
  server is hidden.
  
  Putting that rule in `capabilities.rs` gives the rest of the stack one
  place to ask instead of duplicating auth checks in loader, manager,
  marketplace, and details code.
  
  ## Validation
  
  - `cargo fmt`
  - `cargo test -p codex-core-plugins`

  felixxia-oai · 2026-06-16 00:13:27 +00:00
  7e0dce91df
• [codex] Preserve remote plugin directory order (#28395)

  ## Summary
  
  - preserve the plugin directory endpoint's response order while merging
  installed state
  - append unmatched installed-only plugins afterward when requested
  - add focused coverage for directory order and installed-only placement
  
  ## Why
  
  The remote marketplace merge currently reconstructs plugins through
  ordered maps and sets, then sorts the result alphabetically by display
  name. That discards any ordering supplied by the plugin directory
  endpoint before the list reaches Desktop.
  
  ## Implementation
  
  Directory plugin IDs are unique, so the merge now iterates the directory
  vector directly in response order. For each directory plugin, it removes
  matching installed state from an ID-indexed map and builds the summary.
  Any entries left in the installed map are installed-only plugins and are
  appended when `include_installed_only` is enabled.
  
  There is no separate rank field, rank map, or final sort. Desktop
  therefore receives directory order—including any backend ranking—and can
  preserve it within its existing stable UI state tiers.
  
  ## Testing
  
  - `just test -p codex-core-plugins` (225 passed)

  jameswt-oai · 2026-06-15 16:09:43 -07:00
  4c1c9bf327
• [codex] Add created-by-me remote plugin marketplace (#28203)

  ## Summary
  - add the `created-by-me-remote` marketplace backed by paginated
  `scope=USER` plugin directory and installed-plugin requests
  - include USER plugins in installed-plugin caching, bundle sync, and
  stale-cache cleanup without client-side discoverability filtering
  - expose the marketplace through app-server v2 and regenerate the
  protocol schemas
  
  ## Testing
  - `cargo build -p codex-app-server --bin codex-app-server`
  - production-auth `plugin/list` smoke test for `created-by-me-remote`
  (returned the expected USER plugin as installed and enabled)
  - `just test -p codex-core-plugins` (221 passed)
  - `just test -p codex-app-server-protocol` (231 passed)
  - `just test -p codex-app-server suite::v2::plugin_list::` (37 passed)
  - `just fix -p codex-core-plugins -p codex-app-server-protocol -p
  codex-app-server`
  - `just fmt`

  Eric Ning · 2026-06-15 22:07:07 +00:00
  709f19e111
• [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
• [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