32 Commits

• [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] [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] 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] 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
• [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] 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
• [codex] Return workspace directory installed plugins (#27098)

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

  xl-openai · 2026-06-09 01:23:16 -07:00
  a304569c79
• [codex] 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
• [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
• 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
• 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
• 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
• 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
• 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
• [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
• 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
• feat: Expose plugin versions and gate plugin sharing (#22397)

  - Adds localVersion to plugin summaries and remoteVersion to share
  context, including generated API schemas.
  - Hydrates local and remote plugin versions from manifests and remote
  release metadata.
  - Adds default-on plugin_sharing gate for shared-with-me listing and
  plugin/share/save, with disabled-path errors
      and focused coverage.

  xl-openai · 2026-05-12 17:56:30 -07:00
  d1430fd61e
• Read cached metadata for installed Git plugins (#20825)

  ## Summary
  - Populate `plugin/list` interface metadata for installed Git-sourced
  marketplace plugins from the active cached plugin bundle.
  - Preserve marketplace category precedence so list behavior matches
  `plugin/read`.
  - Keep existing fallback behavior when the cache or manifest is missing
  or invalid.
  
  ## Test Plan
  - `cd codex-rs && just fmt`
  - `cd codex-rs && cargo test -p codex-core-plugins
  list_marketplaces_installed_git_source_reads_metadata_from_cache_without_cloning`
  - `cd codex-rs && cargo test -p codex-app-server
  plugin_list_returns_installed_git_source_interface_from_cache`
  - `cd codex-rs && just fix -p codex-core-plugins`
  - `cd codex-rs && just fix -p codex-app-server`
  - `git diff --check`
  
  Server-truth check: OpenAI monorepo app-server generated types already
  expose `PluginSummary.interface`, and the webview consumes it for plugin
  cards. This PR keeps the protocol/schema unchanged and fills the
  existing field from the cached installed bundle for Git-backed
  cross-repo plugins.

  xli-oai · 2026-05-10 16:59:57 -07:00
  2abdeb34d5
• Show plugin hooks in plugin details (#21447)

  Supersedes the abandoned #19859, rebuilt on latest `main`.
  
  # Why
  
  PR #19705 adds discovery for hooks bundled with plugins, but `/plugins`
  still only shows skills, apps, and MCP servers. This follow-up makes
  bundled hooks visible in the same plugin detail view so users can
  inspect the full plugin surface in one place.
  
  We also need `PluginHookSummary` to populate Plugin Hooks in the app;
  `hooks/list` is not enough there because plugin detail needs to show
  hooks for disabled plugins too.
  
  # What
  
  - extend `plugin/read` with `PluginHookSummary` entries for bundled
  hooks
  - summarize plugin hooks while loading plugin details
  - render a `Hooks` row in the `/plugins` detail popup
  
  <img width="3456" height="848" alt="CleanShot 2026-04-27 at 11 45 34@2x"
  src="https://github.com/user-attachments/assets/fe3a38d6-a260-4351-8513-fb04c93d725b"
  />

  Abhinav · 2026-05-07 00:21:14 -07:00
  40e282849c
• Expose plugin manifest keywords in app server (#21271)

  ## Summary
  - Add plugin manifest keywords to core plugin marketplace/detail models
  - Expose keywords on app-server v2 PluginSummary and generated
  schema/types
  - Populate keywords in plugin/list and plugin/read responses for local
  plugins
  
  Depends on https://github.com/openai/openai/pull/891087
  
  ## Validation
  - just fmt
  - just write-app-server-schema
  - cargo test -p codex-app-server-protocol
  - cargo test -p codex-core-plugins
  - cargo test -p codex-app-server
  plugin_list_keeps_valid_marketplaces_when_another_marketplace_fails_to_load
  - cargo test -p codex-app-server
  plugin_read_returns_plugin_details_with_bundle_contents

  Abdulrahman Alfozan · 2026-05-06 02:09:05 +00:00
  94db03d5af
• Move plugin out of core. (#20348)
  xl-openai · 2026-04-30 14:26:14 -07:00
  7b3de63041