ChatGPT Apps became plugins: what actually changed

Nothing in my MCP servers changed the week OpenAI started calling everything a plugin. Same tools, same schemas, same optional UI resource. What changed is the unit people discover, install, submit, and publish. OpenAI's documentation says it directly: an app is the MCP-backed capability, a plugin is the package around it.

Four distinctions that should not be collapsed

The shorthand misses all four. OpenAI unified distribution; it did not flatten every trust decision into one thing.

The application you built is still the application

A public MCP server still defines the tools, authentication, schemas, annotations, and the real business rules. Tools still return model-readable structured data. When a UI genuinely improves the task, it still attaches through _meta.ui.resourceUri, runs in a host-controlled sandbox, and talks to the host over the MCP Apps bridge.

The one genuine shift: OpenAI now recommends starting new UI work with the MCP Apps standard keys and the ui/* bridge, keeping window.openai for capabilities without a shared equivalent, a ChatGPT host modal, a specific file-handling API. Existing Apps SDK APIs remain supported. That is a portability improvement rather than a deprecation: the shared standard owns the common path, and the SDK still gets ChatGPT-only capabilities first.

The wrapper carries more than the app

A plugin can include an app, skills, or both. In the richer local package format it also carries lifecycle hooks, MCP configuration, assets, and marketplace metadata.

my-plugin/
  .codex-plugin/plugin.json   # required package manifest
  .app.json                   # optional app or connector mapping
  .mcp.json                   # optional MCP server configuration
  skills/                     # optional repeatable workflows
  hooks/                      # optional lifecycle behavior
  assets/                     # listing and install-surface media

An app alone gives ChatGPT tools and, optionally, an embedded UI. A plugin can add the instructions for using those tools well: the same spreadsheet app exposes read and write tools while a bundled skill teaches the team's approval workflow, validation checklist, and output format. The product becomes what the system can do, packaged with how ChatGPT should do it.

The manifest fields are plural on purpose: .app.json maps to one or more apps or connectors, .mcp.json configures MCP servers. Figma's official package uses all three slots, referencing the hosted Figma connector and Figma's remote MCP endpoint while shipping design-to-code skills. Codex Security maps three apps in one .app.json, Linear, GitHub, and Atlassian, alongside a set of security skills.

{
  "skills": "./skills/",
  "apps": "./.app.json",
  "mcpServers": "./.mcp.json"
}

// A simplified multi-app mapping
{
  "apps": {
    "linear": { "id": "..." },
    "github": { "id": "..." },
    "atlassian": { "id": "..." }
  }
}

Nothing merges because it shares a bundle. IDs, OAuth sessions, scopes, and tool policies stay separate: installation decides what the agent knows about; each connector still decides who the user is and what is allowed.

The trust ladder

Published, shared, and installed are different claims

"Official," "published," and "installed" answer different questions. A plugin can be authored by OpenAI or a third party, distributed through a personal, repository, workspace, or public catalog, and installed or merely available. Treating those as interchangeable is how trust decisions go wrong.

A marketplace, in this model, is a source configuration: personal at ~/.agents/plugins/marketplace.json, repository at $REPO_ROOT/.agents/plugins/marketplace.json, listing one plugin or many, resolved from local paths, Git repositories, or npm.

For development, ChatGPT developer mode still hands you an app ID beginning plugin_asdk_app, which the plugin creator can drop into .app.json, so you can exercise a plugin through a personal or repository marketplace before anything goes public. Installation copies the package into the local Codex plugin cache rather than running the marketplace source in place; after a change, refresh or reinstall and start a new session. A workspace can share a developer plugin internally, but sharing does not publish it.

The public path is stricter. A public plugin cannot reference an existing, already-published ChatGPT app: you submit the production MCP server again through the plugin portal, which scans it, validates the metadata, and reviews the server directly. The documented submission package includes:

• a verified developer or business identity;
• a production MCP server and domain-verification endpoint;
• accurate readOnlyHint, openWorldHint, and destructiveHint annotations;
• listing, support, privacy, and legal URLs;
• starter prompts and release notes;
• exactly five positive and three negative review test cases;
• skills, when the plugin includes them.

After review, the developer chooses when to publish. There is no separate apps directory; app-only, skills-only, and app-plus-skills packages land in one plugin directory across ChatGPT and Codex. A third-party package can be public and reviewed without ever becoming an "official OpenAI plugin."

The runtime split

ChatGPT and Codex share the package, not the runtime

The shared directory lets you install the same product concept in both hosts. It guarantees nothing about invocation, permissions, presentation, or lifecycle.

When Codex runs a plugin, it resolves the marketplace entry, installs a versioned copy into its cache, and lets a new session discover the enabled skills and tools. Each connector authenticates separately, plugin-provided MCP servers start under their own configuration, and every tool call still runs under the Codex sandbox and approval policy. Packaging grants no extra authority; a custom ChatGPT UI renders only where the host supports that contract. Package one coherent product, then test two execution profiles: installation, authentication, tool use, and UI in ChatGPT; skill discovery, MCP startup, approvals, and a complete non-visual fallback in Codex.

The migration is seven moves

What not to rewrite

Do not move authorization into a skill. Do not put business logic in the plugin manifest. Do not make UI mandatory when a tool response is enough. Do not replace portable MCP Apps calls with product-name checks. The server remains the enforcement boundary, the tool contract remains the model interface, and the UI remains an optional interaction layer. The dependency direction stays clean:

plugin distribution and workflows
  → app reference
    → MCP server tools and authentication
      → optional portable MCP Apps UI
        → optional ChatGPT-specific enhancements

Where the documentation goes quiet

• No automatic conversion is documented. The docs explain new plugin submission; they do not promise existing app listings will migrate on their own.
• No universal legacy deadline is documented. Do not invent a shutdown date for the previous listing path.
• Rollout and entitlement can differ. The directory, developer portal, and individual features vary by account or workspace.
• Custom UI support is host-specific. A plugin's skills and tools may work in Codex while its ChatGPT visual experience does not exist on that surface.

The precise claim was never that plugins replaced MCP Apps. OpenAI moved app distribution into a broader plugin model and kept the MCP-backed app as a component inside it. The app is still the exhibit; the plugin is the crate it ships in. You do not judge a sculpture by its crate. You do need the crate to get it into the building.