Codex Starts Treating Plugins Like a Supply Chain

Plugins are where coding agents stop being assistants and start becoming platforms. A plugin can bring skills, app integrations, MCP server configuration, lifecycle hooks, and marketplace metadata into the same runtime that reads your repository, proposes edits, runs commands, and sometimes asks for fewer approvals than a junior engineer would. That is useful. It is also why OpenAI’s latest Codex changes matter more than their marketplace plumbing label suggests.

On June 24, OpenAI merged a cluster of Codex pull requests that treat plugins and skills less like a convenient folder of helper scripts and more like a supply chain that needs admission control. The center of the change is PR #29753, which enforces marketplace source requirements across marketplace add, plugin install, and configured Git marketplace upgrade paths. It landed at 03:13 UTC, changed 18 files, and added 1,620 lines against 193 deletions. This is not a cosmetic settings toggle. It is Codex trying to make sure the same policy applies wherever capabilities enter the system.

The supporting work is just as telling. PR #29690 adds a TOML policy shape for marketplace source requirements: [marketplaces] restrict_to_allowed_sources = true, plus keyed [marketplaces.allowed_sources.*] entries. Those entries can describe Git repositories with optional refs, host patterns with regex matching, or local marketplace directories with absolute paths. PR #29765 prevents legacy local openai-curated plugins from contributing skills, MCP servers, apps, or hooks when the remote catalog is active under Codex backend auth. PR #29731 fixes skill usage telemetry so support and preflight skills can still emit usage events even when they are not exposed for model-visible implicit routing.

The plugin marketplace is an execution surface

The mistake teams make with agent plugins is treating them like editor extensions. Editor extensions are already risky enough, but coding-agent plugins sit closer to execution authority. OpenAI’s own Codex docs describe plugins as the distribution unit for reusable skills and apps, while marketplaces can install from GitHub shorthand, Git URLs, SSH Git URLs, or local directories, with ref pinning and sparse checkout support. That broad source surface is exactly what makes Codex useful across organizations. It is also what makes source admission non-negotiable.

If a managed deployment says “only these marketplaces are allowed,” that policy cannot live in one happy-path installer. It has to apply to every mutation path: adding a marketplace, installing a plugin, refreshing a configured Git marketplace, and migrating external-agent setups. PR #29753 centralizes the admission decision so CLI, app-server, and migration flows all hit the same guardrail. It also keeps upgrading independent marketplaces when one source is rejected and reports per-marketplace errors instead of turning one bad catalog into a global failure. That is the right kind of boring: strict where authority enters, resilient where maintenance should continue.

The matching rules are deliberately specific. Codex can match normalized Git repository URLs with optional exact refs, Git hosts via managed regular expressions, local marketplaces by exact absolute path, and managed OpenAI marketplace path/name boundaries. Those details matter because “allow GitHub” and “allow this exact repository at this exact ref” are very different security postures. A team that trusts a single internal catalog should not accidentally trust the entire host. A team that permits a local marketplace path should understand that it is granting filesystem-adjacent authority, not just selecting a prettier UI source.

Keyed config is policy engineering, not syntax trivia

The most underappreciated design choice is that the allowed-source table is keyed rather than array-based. That sounds like implementation detail until you have lived with enterprise configuration. Real deployments do not have one config file. They have admin defaults, machine images, workspace rules, user settings, feature flags, and emergency overrides. Arrays are miserable in layered config because nobody can tell whether the next layer appends, replaces, or edits by index without inventing a merge language.

Codex’s keyed shape lets distinct rules accumulate and lets fields under the same key follow normal precedence. That makes it possible for an organization to say “these sources are allowed globally,” a workspace to add “this local marketplace is allowed for this repo,” and an admin override to tighten one rule without rewriting the whole list. If that sounds mundane, good. Agent governance should be mundane. The exciting version is how you get policy drift, bypasses, and a post-incident spreadsheet full of “we thought this setting applied there too.”

PR #29765 shows the same principle in a different seam. Once the remote catalog is active, legacy local openai-curated plugins should not remain in the runtime graph just because startup saw them first. Otherwise the operator believes capabilities are coming from the remote catalog, while the agent still has local curated skills, hooks, apps, or MCP servers available. That is not a catalog migration; that is two catalogs wearing one trench coat. Suppressing the legacy local source under the remote-catalog path makes capability provenance match the user’s mental model.

Telemetry has to see hidden skills too

The skill-usage telemetry fix is a smaller patch with a larger lesson. Codex skills use progressive disclosure: the model initially sees names, descriptions, and paths, then loads full SKILL.md content only after selection. The docs say the initial skill list is capped at 2% of the model context window, or 8,000 characters when unknown. Some support or preflight skills should not be model-visible for implicit invocation. That is sensible. But if another skill reads or runs them, the runtime still needs to account for that usage.

Before PR #29731, the same flag effectively influenced model-visible implicit routing and command-based usage detection. Splitting those concerns is the right boundary. “Can the model select this skill implicitly?” and “Should the runtime emit usage events when this skill is used?” are different questions. Teams adopting agent platforms should copy that distinction. Hidden support capabilities are still capabilities. They should show up in telemetry, audits, and incident reconstruction even when they are intentionally absent from the model’s menu.

This is where the supply-chain framing becomes practical. A serious coding-agent deployment should be able to answer four questions without spelunking logs for a week: which marketplace source installed this capability, which policy allowed it, which skills or hooks became available because of it, and when did the runtime actually use them? Codex is not done, but this set of patches moves those answers closer to the control plane instead of leaving them as folklore.

For engineering teams, the action list is straightforward. Require marketplace source allowlists for managed agent deployments. Prefer exact Git URL and ref matching for catalogs you own. Use host-pattern rules only when you truly trust the whole host and its governance model. Treat local marketplace paths as privileged inputs. Enforce the same policy across CLI, app-server, installation, upgrade, and migration flows. Audit legacy curated or bundled sources during catalog migrations. And make sure skill usage telemetry is not tied only to what the model can choose implicitly.

The broader industry point is that coding-agent supply chain is not just npm packages, PyPI dependencies, model weights, or prompt files. It is also plugin marketplaces, skill bundles, MCP server definitions, hooks, app integrations, and the config layers deciding which of those may exist. The agent race is full of demos about how fast a model can patch a bug. Fine. But the platforms teams will actually trust are the ones that can say, with a straight face, where an agent’s tools came from and why they were allowed to run.

Codex is moving plugin governance from local convenience toward runtime invariant. That is the correct direction. If agents are going to install capabilities on our behalf, the marketplace cannot be a vibes-based folder with a search box. It has to be a governed supply chain, and the admission check has to happen before the agent gets clever.

Sources: OpenAI Codex PR #29753, PR #29690, PR #29765, PR #29731, OpenAI Codex plugin docs, OpenAI Codex skills docs