xl-openai

Add dynamic HTTP header helpers for MCP servers (#38245) ## What changed - Add `http_headers_helper` configuration for local streamable HTTP MCP servers. The configured shell command runs once per connection and returns a JSON object of headers that is cached across requests. - Apply helper headers to MCP startup and OAuth flows while restricting them to the server origin, stopping redirects, rejecting reserved or duplicate headers, and enforcing output and execution limits. - Reject helpers for remote or managed-disabled servers, use the local environment working directory, and redact helper commands from `codex mcp list` and `codex mcp get` output. ## Testing - Cover configuration validation, helper lifecycle and output parsing, origin isolation, OAuth discovery and token refresh, managed requirements, environment selection, and CLI redaction. GitOrigin-RevId: 84e0e26ce75520b0869d37c72b1678e033bd6818

[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.

[plugins] Enforce marketplace source policy at runtime (#29691) ## Summary - project effective marketplace/plugin config through the enterprise source policy so blocked installed plugins become inactive - filter plugin list/read/discovery and CLI marketplace source/snapshot reporting using the same policy - enforce source admission for background marketplace cache refreshes - continue refreshing/upgrading independent marketplaces and plugins when one entry fails, returning per-entry errors - include policy-projected plugin state in cache and refresh keys so requirement changes invalidate stale results ## Stack This is PR 2 of 2 and is based on #29690. Review the admission model and source matcher in #29690 first; this PR contains only runtime enforcement. ## Test plan - `just test -p codex-core-plugins` (287 tests) - `just test -p codex-cli plugin_list_ignores_implicit_system_marketplace_roots_without_manifests` - `cargo check -p codex-cli -p codex-app-server --tests`

Refresh MCP HTTP helper headers after authorization failures (#41400) ## What changed - Re-run the HTTP headers helper after a same-origin `POST` receives a `401` or `403`, and retry the request once when the effective headers changed. - Share refreshes across concurrent rejected requests, retain the previous headers when refresh fails, and keep the retry within the original timeout. - Allow helpers to supply `Authorization` while preserving explicit OAuth or bearer credentials, OAuth insufficient-scope challenges, and redirect safety checks. ## Testing - Cover rotating helper headers for MCP tool calls and same-origin OAuth token refreshes. - Cover concurrent rejections, failed and unchanged refreshes, retry limits, timeouts, and redirects. GitOrigin-RevId: c662edefdb1cd2876d9d02545a72d5bd6739864f

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

Preserve discovery paths for symlinked skills (#37144) ## Why Symlinked skills have a canonical `SKILL.md` path that can differ from the path under the configured skill root. A catalog entry that advertises the discovery path must still select the canonical skill. ## What changed - Track each loaded skill's discovery path alongside its canonical identity. - Render discovery paths in the skill catalog and accept either form for structured selections and linked skill mentions. - Preserve enabled-state checks, deduplication, and product filtering when resolving discovery paths. ## Testing Added loader, catalog, mention-resolution, and end-to-end turn coverage for skills discovered through directory symlinks. GitOrigin-RevId: bae539b766cc3782c7c121a4276c337699cbb509

Validate identifiers in plugin creator workflows (#39131) ## Why Plugin and marketplace names can flow into generated install commands, so the plugin creator must reject names outside the supported identifier syntax before using them or changing files. ## What changed - Centralize validation for plugin names, including dotted names, and marketplace names. - Apply validation when reading marketplaces, validating manifests, updating cachebusters, and scaffolding plugins. - Validate existing marketplace state before scaffold writes so invalid or duplicate entries leave plugin and marketplace files unchanged. ## Testing Add regression tests for accepted identifiers, unsafe and malformed names, dotted plugin names, and failure paths that must not modify files. GitOrigin-RevId: 9db68c2313a1539c5ab44d777966e33b460ceb71

[codex] Ignore local curated plugins when remote catalog is active (#29765) ## Summary - suppress configured `openai-curated` plugins when the remote plugin feature is enabled and auth uses the Codex backend - preserve `openai-api-curated` and non-Codex-backend behavior while including remote catalog activation in the plugin load cache key - add core plugin coverage and an app-server integration test for runtime feature enablement ## Why The Codex app enables remote plugins through process-local runtime feature enablement, which can happen after app-server startup tasks have already observed legacy local plugin state. The existing conflict logic only preferred a remote plugin when the same plugin was already installed remotely, so a configured legacy-only plugin could continue exposing skills and other capabilities from `openai-curated`. ## Impact When the remote catalog is active, legacy `openai-curated` plugins no longer contribute skills, MCP servers, apps, or hooks. Remote installed plugins continue to load normally, and `openai-api-curated` remains unaffected. This does not change remote fetch, bundle sync, or uninstall behavior. ## Validation - `just test -p codex-core-plugins remote_global_catalog_ignores_local_curated_plugins remote_plugin_feature_keeps_local_curated_without_codex_backend` - `just test -p codex-app-server runtime_remote_plugin_enablement_excludes_local_curated_plugin_skills` - `just fmt` - `git diff --check`

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

[plugins] Add marketplace source requirements (#29690) ## Why Managed deployments need a mergeable way to declare which marketplace sources Codex may use. An enterprise-keyed TOML table avoids array merge ambiguity and lets every requirements layer use the existing config precedence rules without a marketplace-specific merger. ## Requirements shape ```toml [marketplaces] restrict_to_allowed_sources = true [marketplaces.allowed_sources.company_plugins] source = "git" url = "https://github.com/example/company-plugins.git" ref = "main" [marketplaces.allowed_sources.internal_git] source = "host_pattern" host_pattern = "^git\\.example\\.com$" [marketplaces.allowed_sources.local_plugins] source = "local" path = "/opt/company/codex-plugins" ``` `restrict_to_allowed_sources` follows normal scalar precedence. `allowed_sources` follows normal recursive TOML table merge behavior: distinct keys accumulate and fields under the same key use normal layer precedence. The final `source` value later selects which fields the marketplace admission policy interprets. The raw rule fields remain optional while requirements layers are composed, so a higher-priority layer can override only `ref`, `url`, or another individual field. Source-specific validation and normalization intentionally belong to the marketplace admission layer, not requirements merging. This initial shape includes `git`, `host_pattern`, and `local` sources. It does not add npm or path-pattern rules. ## What changed - Add the marketplace requirements TOML shape to `ConfigRequirementsToml`, `ConfigRequirementsWithSources`, and `ConfigRequirements`. - Carry marketplace requirements through the existing regular requirements merge path. - Keep allowed-source entries as raw partial tables for downstream policy interpretation. - Cover partial same-key overlays, source changes, unknown fields, and unmodified local paths. This PR defines and composes the requirements only. Source admission is implemented by the next PR in the stack. ## Stack This is PR 1 of 3. #29753 adds source admission on top of this PR; draft #29691 will add runtime enforcement after it is rebased later. ## Test plan - `just test -p codex-config marketplace_`