48 Commits

• [plugins] Enforce marketplace source admission requirements (#29753)

  ## Why
  
  Managed marketplace source requirements only become effective when every
  local marketplace mutation path applies the same admission decision.
  This change centralizes that decision so CLI, app-server, and
  external-agent migration flows cannot add, install from, or refresh a
  disallowed source.
  
  ## What changed
  
  - Match exact normalized Git repository URLs with an optional exact
  `ref`.
  - Match Git hosts with managed regular expressions.
  - Match local marketplaces by exact absolute path.
  - Preserve the expected path/name boundary for managed OpenAI
  marketplaces.
  - Enforce source admission during marketplace add, plugin install, and
  configured Git marketplace upgrade.
  - Continue upgrading independent marketplaces when one source is
  rejected and return a per-marketplace error.
  - Load the effective requirements stack at CLI, app-server, and
  external-agent migration entry points.
  
  This PR does not filter already configured marketplaces at runtime; that
  remains in draft follow-up #29691.
  
  ## Stack
  
  This is PR 2 of 3 and is based on #29690, which introduces the
  requirements data shape and merge behavior.
  
  ## Test plan
  
  - Source matcher coverage for Git URL/ref, host-pattern, local-path, and
  managed marketplace cases.
  - Marketplace add and plugin install coverage for allowed and rejected
  sources.
  - Marketplace upgrade coverage for rejection and per-marketplace
  continuation.

  xl-openai · 2026-06-23 20:13:11 -07:00
  4fe02f4fcf
• auth: move domain mode below app wire types (#29721)

  ## Why
  
  Authentication mode is a domain concept used by login, model selection,
  telemetry, and transports. Keeping the canonical type in app-server
  protocol forces those lower-level crates to depend on an unrelated wire
  API.
  
  ## What changed
  
  - Added canonical `codex_protocol::auth::AuthMode` domain values.
  - Kept the app-server wire DTO unchanged and added an explicit app-side
  conversion.
  - Removed production app-server-protocol dependencies from login,
  model-provider-info, models-manager, and otel call paths.
  
  ## Stack
  
  This is PR 2 of 6, stacked on [PR
  #29714](https://github.com/openai/codex/pull/29714). Review only the
  delta from `codex/split-json-rpc-protocols`. Next: [PR
  #29722](https://github.com/openai/codex/pull/29722).
  
  ## Validation
  
  - Auth and login coverage passed in the focused protocol/domain test
  run.
  - App-server account and auth conversion coverage passed.

  Adam Perry @ OpenAI · 2026-06-24 03:10:20 +00:00
  31372078d1
• Separate local and remote plugin analytics IDs (#29495)

  ## Why
  
  Plugin analytics overloaded `plugin_id`: most events used the Codex
  `<plugin>@<marketplace>` identity, while remote install events used the
  backend plugin ID. That makes the same field change meaning across event
  types and complicates downstream identity resolution.
  
  This change makes the contract unambiguous:
  
  - `plugin_id`: the local Codex `<plugin>@<marketplace>` identity, when
  resolved
  - `remote_plugin_id`: the backend plugin identity, when available
  
  For a remote install failure that happens before plugin details resolve,
  `plugin_id` is `null` and `remote_plugin_id` remains populated.
  
  ## What changed
  
  All six plugin analytics events use the same identity contract:
  
  - `codex_plugin_installed`
  - `codex_plugin_install_failed`
  - `codex_plugin_uninstalled`
  - `codex_plugin_enabled`
  - `codex_plugin_disabled`
  - `codex_plugin_used`
  
  Remote identity is resolved from the current installed-plugin snapshot
  first, with persisted install metadata as fallback. The telemetry
  metadata type keeps local identity optional for failures that occur
  before remote details are available.
  
  The app-server test client's manual analytics smokes now find remote
  mutation events through `remote_plugin_id` and validate that `plugin_id`
  remains local.
  
  ## Remote uninstall
  
  Resolve and capture telemetry metadata before removing the local plugin
  cache, then emit `codex_plugin_uninstalled` after the backend confirms
  success. The event is also emitted when backend uninstall succeeds but
  local cache cleanup reports `CacheRemove`.
  
  If a concurrent remote-cache refresh removes the local bundle before
  telemetry capture, the already-fetched remote plugin detail supplies
  fallback capability metadata.
  
  ## Validation
  
  - `just test -p codex-analytics` — 82 passed
  - `just test -p codex-core-plugins` — 271 passed
  - `just test -p codex-app-server-test-client` — 5 passed
  - `just test -p codex-plugin` — 3 passed
  - `just test -p codex-app-server plugin_install` — 37 passed
  - `just test -p codex-app-server plugin_uninstall` — 10 passed
  
  The production app-server install/uninstall flow was also exercised
  against `plugins~Plugin_f1b845ac33888191ac156169c58733c2`
  (`build-ios-apps@openai-curated-remote`), and the plugin's original
  uninstalled state was restored.

  jameswt-oai · 2026-06-23 12:27:14 -07:00
  ff50b47dce
• [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] fetch featured IDs for remote plugins (#29485)

  ## Summary
  
  - fetch featured plugin IDs when the loaded catalog includes
  `openai-curated-remote`
  - extend the existing remote marketplace regression test to cover the
  featured IDs response
  
  ## Why
  
  When the remote plugin catalog was enabled, app-server loaded
  `openai-curated-remote` but skipped `/plugins/featured` because the
  request processor only fetched featured IDs for the local
  `openai-curated` marketplace. As a result, the desktop app could not
  render the backend-curated remote featured set.
  
  This keeps the existing local behavior and also returns the curated
  ranking for remote plugins.
  
  ## Test plan
  
  - `just fmt`
  - `git diff --check`
  - `just test -p codex-app-server
  plugin_list_includes_remote_marketplaces_when_remote_plugin_enabled`

  Eric Ning · 2026-06-22 15:08:59 -07:00
  bf7148626b
• [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] 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
• Replace SkillsManager with SkillsService (#28705)

  ## Why
  
  Host skill discovery was still exposed as a manager even though it is a
  process-owned service shared by sessions, the app-server catalog, and
  file-watcher invalidation. The skills extension also consumed an ad hoc
  loaded-skills wrapper instead of a named immutable snapshot.
  
  ## What changed
  
  - replace `SkillsManager` with concrete `SkillsService`
  - make the service cache and return immutable `HostSkillsSnapshot`
  values
  - migrate the skills extension host provider to the snapshot boundary
  - migrate app-server catalog, watcher, and invalidation paths to the
  service
  
  This keeps the service limited to host discovery, caching, roots, and
  invalidation. Catalog rendering and invocation remain extension
  responsibilities for the next stacked change.

  jif · 2026-06-17 17:01:06 +02:00
  0318381762
• [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] 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
• TUI Plugin Sharing 2 - add remote plugin section plumbing (#26702)

  This adds the background plumbing for remote-backed plugin catalog
  sections while leaving the fuller directory presentation to the next PR.
  The TUI can fetch section-specific remote marketplace results, keep
  local plugin data available, and carry section errors forward for later
  rendering.
  
  - Fetches explicit remote marketplace kinds for curated, workspace, and
  shared-with-me sections.
  - Gates shared-with-me loading on the plugin sharing feature flag.
  - Adds section-level error state and user-actionable error copy.
  - Merges remote marketplace results into the cached plugin list without
  discarding local results.

  canvrno-oai · 2026-06-15 10:25:37 -07:00
  29224d945b
• [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] Preserve plugin apps in connector listings (#27602)

  ## Context
  
  This is PR4 in the plugin auth-routing stack. The earlier PRs make
  plugin surface projection auth-aware and narrow App/MCP conflicts by App
  declaration name. This PR keeps connector listing paths aligned with
  that projected plugin App set.
  
  This means ChatGPT/SIWC users will still see plugin-provided Apps in
  connector listing surfaces like the Apps/connector picker, while API-key
  users will not see Apps they cannot use.
  
  ## 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
  
  - Have app-server compute effective plugin Apps from the existing
  PluginsManager and pass them into connector listing.
  - Keep plugin Apps visible in Apps/connector listing for ChatGPT/SIWC
  users.
  - Keep API-key-style auth from surfacing plugin Apps in connector
  listings.
  
  ## Validation
  
  ```bash
  cargo test -p codex-chatgpt connectors::tests
  cargo test -p codex-app-server list_apps_includes_plugin_apps_for_chatgpt_auth
  git diff --check
  ```

  felixxia-oai · 2026-06-15 13:50:08 +01:00
  cededa26c5
• [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
• feat: use encrypted local secrets for MCP OAuth (#27541)

  ## Summary
  
  - store MCP OAuth credentials in the configured auth credential backend
  - support encrypted-local OAuth storage, including legacy keyring
  migration
  - propagate the credential backend through MCP refresh, session, CLI,
  and app-server paths
  
  ## Stack
  
  1. #27504 — config and feature flag
  2. #27535 — auth-specific secret namespaces
  3. #27539 — encrypted CLI auth storage
  4. this PR — encrypted MCP OAuth storage
  
  This is a parallel review stack; the original #17931 remains unchanged.
  
  ## Tests
  
  - `just test -p codex-rmcp-client` (the transport round-trip test passed
  after building the required `codex` binary and retrying)
  - `just test -p codex-mcp`
  - `just test -p codex-app-server
  refresh_config_uses_latest_auth_keyring_backend`
  - `just test -p codex-core
  refresh_mcp_servers_is_deferred_until_next_turn`
  - `just test -p codex-cli mcp`
  - `just fix -p codex-rmcp-client -p codex-mcp -p codex-core -p codex-cli
  -p codex-app-server -p codex-protocol`
  - `just bazel-lock-check`

  Celia Chen · 2026-06-12 22:03:51 +00:00
  9915d34684
• [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
• [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] Remove redundant plugin app auth state (#27465)

  ## Summary
  
  - remove the redundant `needsAuth` field from `AppSummary` and generated
  app-server schemas
  - stop `plugin/read` from querying Apps MCP solely to hydrate unused
  connector auth state
  - preserve `plugin/install.appsNeedingAuth` membership and
  `app/list.isAccessible` as the authentication signals
  
  ## Why
  
  Codex App and TUI do not consume `plugin/read.plugin.apps[].needsAuth`.
  Hydrating it could establish an Apps MCP connection and discover tools
  on a cold `plugin/read` request, adding avoidable latency. The plugin
  APIs are still marked under development, so removing this wire field is
  preferable to retaining a misleading default.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `just fmt`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  plugin_install_uses_remote_apps_needing_auth_response`
  - `just test -p codex-app-server
  plugin_install_returns_apps_needing_auth`
  - `just test -p codex-app-server
  plugin_read_returns_plugin_details_with_bundle_contents`
  - `just test -p codex-tui
  plugin_detail_popup_snapshot_shows_install_actions_and_capability_summaries`
  - `$xin-build` simplify and debug reviews

  xl-openai · 2026-06-10 17:33:56 -07:00
  1a9efd473b
• [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
• Route hosted Apps MCP through extensions (#27191)

  ## Stack
  
  - Base: #27184
  - This PR is the second vertical and should be reviewed against
  `jif/external-plugins-1`, not `main`.
  
  ## Why
  
  CCA is moving toward a split runtime where the orchestrator may have no
  filesystem or executor, but it still needs to activate remotely hosted
  plugin components. HTTP MCP servers are the simplest complete example:
  they need configuration and host authentication, but they do not need an
  executor process.
  
  The Apps MCP endpoint is currently synthesized by a special-purpose
  loader inside the MCP runtime. That works locally, but it leaves hosted
  MCP activation outside the extension model being established in #27184.
  It also makes the Apps path a poor foundation for plugins whose skills,
  MCP servers, connectors, and hooks may come from different sources or
  execute in different places.
  
  This PR moves that one behavior behind an extension-owned contribution
  while preserving the existing local fallback. It deliberately does not
  introduce a generic plugin activation framework.
  
  ## What changed
  
  ### MCP extension contribution
  
  `codex-extension-api` gains an ordered `McpServerContributor` contract.
  A contributor returns typed `Set` or `Remove` overlays for MCP server
  configuration; later contributors win for the names they own.
  
  The contract stays at the existing MCP configuration boundary.
  Extensions do not create a second connection manager or transport
  abstraction.
  
  ### Hosted Apps MCP extension
  
  A new `codex-mcp-extension` contributes the reserved `codex_apps` server
  from the existing Apps feature, ChatGPT base URL, path override, and
  product SKU configuration.
  
  When `apps_mcp_path_override` is enabled for `https://chatgpt.com`, the
  resulting streamable HTTP endpoint is
  `https://chatgpt.com/backend-api/ps/mcp`. The existing ChatGPT-auth gate
  remains authoritative, so this server can run in an orchestrator-only
  process without being exposed for API-key sessions.
  
  ### One resolved runtime view
  
  `McpManager` now distinguishes three views:
  
  - **configured:** config- and plugin-backed servers before extension
  overlays;
  - **runtime:** configured servers plus host-installed extension
  contributions;
  - **effective:** runtime servers after auth gating and compatibility
  built-ins.
  
  App-server installs the hosted MCP extension and uses the runtime view
  for thread startup, refresh, status, threadless resource reads,
  connector discovery, and MCP OAuth lookup. This keeps
  `mcpServer/oauth/login` consistent with the servers exposed by the other
  MCP APIs. The hosted Apps server itself continues to use existing
  ChatGPT host authentication rather than MCP OAuth.
  
  ## Compatibility
  
  Hosts that do not install the MCP extension retain the existing Apps MCP
  synthesis path. This preserves current local-only, CLI, and
  standalone-host behavior while app-server exercises the extension path.
  
  Disabling Apps removes the reserved `codex_apps` entry, and losing
  ChatGPT auth removes it from the effective runtime view. Executor
  availability is not consulted for this HTTP transport.
  
  ## Follow-ups
  
  The next vertical will resolve a manifest-declared stdio MCP server from
  an executor-selected plugin root and execute it in the environment that
  owns that root. Later verticals can add backend-owned skills, connector
  metadata, hooks, durable selection semantics, and incremental local
  convergence without changing the component-specific runtime boundaries
  introduced here.
  
  ## Verification
  
  Focused coverage was added for:
  
  - contributing the hosted Apps MCP at `/backend-api/ps/mcp` without an
  executor;
  - requiring ChatGPT auth in the effective runtime view;
  - removing a reserved configured Apps server when the Apps feature is
  disabled.
  
  `cargo check -p codex-app-server -p codex-mcp-extension -p
  codex-extension-api -p codex-mcp` passed. Tests and Clippy were not run
  locally under the current development instruction; CI provides the full
  validation pass.

  jif · 2026-06-09 22:44:16 +02:00
  4ec3b8eeea
• [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] Expose unavailable app templates in plugin detail (#26317)

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

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

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

  Eric Ning · 2026-06-04 22:10:24 +00:00
  769c231aa1
• [codex] Cache remote plugin catalog for suggestions (#25457)

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

  xl-openai · 2026-06-01 22:10:52 -07:00
  f2b725102b
• 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
• [codex] Avoid forced directory refresh during plugin install auth checks (#25381)

  ## Summary
  - Use normal directory loading for plugin install app metadata so
  install avoids forced directory refresh while still loading metadata on
  cold cache.
  - Continue force-refreshing codex_apps tools for auth state.
  - Add regression coverage that pre-warms the directory cache and asserts
  install returns cached app metadata without extra directory requests.
  
  ## Validation
  - just fmt
  - git diff --check
  - just test -p codex-app-server plugin_install_returns_apps_needing_auth
  plugin_install_filters_disallowed_apps_needing_auth (blocked locally:
  cargo-nextest is not installed)

  xl-openai · 2026-05-31 02:14:15 -07:00
  cdde711fac
• 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: 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: Add plugin share checkout (#22435)

  Adds plugin/share/checkout to turn a shared remote plugin into a local
  working copy under ~/plugins/<name>.
  
  Registers the copy in the managed personal marketplace and records the
  remote-to-local mapping for later share/save flows.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-05-13 00:50:29 -07:00
  2a67c46de4
• 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
• feat: Normalize remote plugin summary identities. (#22265)

  Makes plugin summaries use config-style plugin@marketplace IDs while
  exposing backend remote IDs separately as remotePluginId.
  
  Also fix the consistency issue of REMOTE_SHARED_WITH_ME_MARKETPLACE_NAME

  xl-openai · 2026-05-12 00:58:37 -07:00
  5b1a4c2fa7
• feat: Add role-aware plugin share context APIs (#21867)

  Expose discoverability and full share principals in share context, carry
  roles through save/updateTargets, hydrate local shared plugin reads, and
  keep share URLs only under plugin.shareContext.

  xl-openai · 2026-05-08 20:46:39 -07:00
  479491ed89
• feat: Update plugin share settings with discoverability (#21637)

  Requires discoverability on plugin/share/updateTargets so the server can
  manage workspace link access consistently, including auto-adding the
  workspace principal for UNLISTED.
  
  Also rejects LISTED on share creation and blocks client-supplied
  workspace principals while preserving response parsing for LISTED.

  xl-openai · 2026-05-07 21:28:18 -07:00
  ae15343243
• feat: Expose plugin share metadata in shareContext (#21495)

  Extends PluginSummary.shareContext with shareUrl and reader shareTargets

  xl-openai · 2026-05-07 10:07:03 -07:00
  114bac1409
• 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
• feat: Add marketplace source filtering and plugin share context (#21419)

  Adds marketplaceKinds to plugin/list for local, workspace-directory, and
  shared-with-me; omitted params keep default local plus gated global
  behavior, while explicit kinds are exact.
  
  Exposes shareContext on plugin summaries from local share mappings and
  remote workspace/shared responses, including remotePluginId and nullable
  creator metadata.
  
  Adds shared-with-me listing through /ps/plugins/workspace/shared,
  renames the workspace remote namespace to workspace-directory, and keeps
  direct remote read/share/install/update/delete paths gated by plugins
  rather than remote_plugin.

  xl-openai · 2026-05-06 16:12:23 -07:00
  11106016ff
• Preserve session MCP config on refresh (#21055)

  # Overview
  MCP refreshes were rebuilding active threads from fresh disk-backed
  config only, which dropped thread-start session overlays such as
  app-injected MCP servers. This keeps refreshes current with disk config
  while preserving the thread-local config that only the active thread
  knows about.
  
  # Changes
  - Rebuild refreshed config per active thread using that thread's current
  `cwd`, rather than fanning out one app-server config to every thread.
  - Preserve each thread's `SessionFlags` layer while replacing reloadable
  config layers with freshly loaded config, then derive the MCP refresh
  payload from the rebuilt result.
  - Move MCP refresh orchestration into app-server so manual refreshes
  fail loudly while background refreshes remain best-effort, and route
  plugin-triggered refreshes through the same per-thread reload path.
  - Add regression coverage for session overlays, fresh project config,
  plugin-derived MCP config, current requirements, and strict vs
  best-effort refresh behavior.
  
  # Verification
  - Passed focused Rust coverage for the thread-config rebuild behavior
  and deferred MCP refresh flow, plus `cargo test -p codex-app-server
  --lib`.
  - Verified end to end in the Codex dev app against the locally built
  CLI: registered an MCP via thread config, verified that it could be used
  successfully before refresh, manually triggered MCP refresh, and
  verified that it continued to be available afterward.

  aaronl-openai · 2026-05-05 21:09:28 -07:00
  9f06d171e2
• feat: Add plugin share access controls (#21124)

  Extends `plugin/share/save` to accept optional discoverability and
  shareTargets while uploading plugin contents, and adds
  `plugin/share/updateTargets` for share-only target updates without
  re-uploading.

  xl-openai · 2026-05-05 20:14:18 -07:00
  5119680f85
• 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
• [codex] Use shared app-server JSON-RPC error helpers (#21221)

  ## Why
  
  App-server had repeated hand-built JSON-RPC error objects for standard
  error shapes. Using the shared helpers keeps the common
  `invalid_request`, `invalid_params`, and `internal_error` construction
  in one place and reduces the chance of new call sites drifting from the
  common error payload shape.
  
  ## What changed
  
  - Replaced manual standard JSON-RPC error object creation with
  `internal_error(...)`, `invalid_request(...)`, and `invalid_params(...)`
  across app-server request processors and runtime paths.
  - Removed local duplicate helper definitions from search and review
  request handling.
  - Preserved existing structured `data` payloads by creating the shared
  helper error first and then attaching the existing metadata.
  - Left custom non-standard errors and raw error-code assertions intact.
  
  ## Validation
  
  - `cargo test -p codex-app-server`

  pakrym-oai · 2026-05-05 12:13:59 -07:00
  b6d4c4ea6b
• Remove remote plugin uninstall prefix gate (#20722)

  ## Summary
  
  Remove the hardcoded remote plugin ID prefix allow-list from app-server
  uninstall routing. IDs that do not parse as local `plugin@marketplace`
  IDs now flow through the remote uninstall path, where the existing
  remote ID safety validation still rejects empty IDs, spaces, slashes,
  and other unsafe characters before URL/cache use.
  
  ## Why
  
  Plugin-service owns the backend remote plugin ID contract. Codex should
  not require remote IDs to start with the local hardcoded prefixes
  `plugins~`, `plugins_`, `app_`, `asdk_app_`, or `connector_`, because
  newer backend ID families could otherwise be rejected before
  plugin-service sees the request.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-app-server plugin_uninstall`
  - `just fix -p codex-app-server`
  - `git diff --check`

  xli-oai · 2026-05-04 16:28:13 -07:00
  a8db4af5c3
• [codex] Split app-server request processors (#20940)

  ## Why
  
  The app-server request path had grown around a large
  `CodexMessageProcessor` plus separate API wrapper/helper modules. That
  made the dependency graph hard to see and forced unrelated request
  families to share broad processor state.
  
  This PR makes the split mechanical and command-prefix oriented so
  request families own only the dependencies they use.
  
  ## What changed
  
  - Replaced `CodexMessageProcessor` with command-prefix request
  processors under `app-server/src/request_processors/`.
  - Removed the old config, device-key, external-agent-config, and fs API
  wrapper files by moving their API handling into processors.
  - Split apps, plugins, marketplace, catalog, account, MCP, command exec,
  fs, git, feedback, thread, turn, thread goals, and Windows sandbox
  handling into dedicated processors.
  - Kept shared lifecycle, summary conversion, token usage replay, and
  shared error mapping only where multiple processors use them; single-use
  helpers were inlined into their owning processor.
  - Removed the fallback processor path and moved processor tests to
  `_tests` files.
  
  ## Validation
  
  - `cargo test -p codex-app-server`
  - `cargo check -p codex-app-server`
  - `just fix -p codex-app-server`

  pakrym-oai · 2026-05-04 09:34:11 -07:00
  33b19bcfde