A plugin in Codex is an installable package that combines different kinds of customization into one distributable set. It can contain skills, connectors and MCP servers, hooks, assets and scheduled-task templates. The point of a plugin is to turn scattered configuration into a product with a version, installed and updated as a whole. ChatGPT and Codex use a shared public catalog, but the surfaces differ - and this difference matters to understand before installing.

The difference in surfaces means that "the plugin is in the catalog" is not equal to "the plugin works for me the same way". ChatGPT Work on the web gives a browser directory, install and use. The desktop app adds connector auth to that. The Codex CLI works through /plugins and marketplace commands. And the IDE extension does not support plugins at all right now. So the availability of a specific plugin is checked on your surface rather than assuming that presence in the catalog guarantees work everywhere.

It helps to see how plugins look from the CLI once. Below is the /plugins command that opens work with them. An important detail after install: for the bundled skills and tools to appear in discovery, you start a new session. A plugin does not blend into an already running conversation retroactively - its components are picked up on the next launch. This is the same logic as with the rest of the configuration: the new state applies on a new prefix, not instantly.

The sign-in method affects which plugins are available at all. API-key login supports some OpenAI-curated plugins, but OAuth-dependent connections may be absent: a connector needing interactive OAuth will not work where there is no ChatGPT sign-in. This is worth accounting for in advance, especially in automation: if a pipeline counts on a specific connector, you check that the chosen authorization method gives access to it at all.

It helps to gather plugin support by surface into a table once. Below is the map: ChatGPT Work web, desktop, CLI and IDE. You return to it when planning where a specific customization will work: what installs conveniently in the desktop with connector auth may be unavailable in the IDE and require a different approach in the CLI. Choosing the surface for a plugin is part of planning, not a detail found out already in production.