On July 9, 2026, OpenAI replaced ChatGPT’s App Directory with a Plugin Directory spanning ChatGPT and Codex. Existing app connections did not disappear. Instead, the discovery layer expanded from individual integrations to packaged workflow capabilities.
The word “plugin” has carried several meanings in ChatGPT’s history, so the new structure deserves a precise definition. In OpenAI’s current documentation, a plugin is a package for a workflow. It can contain skills, apps, and app templates. A plugin may combine several of them, or it may contain only reusable skills.
That makes the directory less like a conventional app store and more like a catalog of agent capabilities. A listing can bundle instructions for how to perform a task, the connection needed to reach external data or actions, and a template an administrator can configure for an organization.
Skills, apps, and templates have different jobs
The three building blocks are related but not interchangeable.
Skills encode a repeatable method
Skills provide reusable instructions, prompts, and workflow patterns. A skill can tell Codex how to review a code change, prepare a particular report, or follow an organization’s preferred sequence. It can be useful without connecting to any external service.
Skills improve consistency by moving stable process knowledge out of one-off prompts. They do not grant new data access by themselves.
Apps connect systems, data, and actions
Apps connect ChatGPT or Codex to external systems approved for the workspace. They can expose search, synced content, user-interface elements, and actions depending on the app and configuration.
An app is the authority-bearing component. Its OAuth connection, role assignment, source-system permissions, read and write controls, and confirmation requirements determine what it can actually do.
App templates require setup
An app template helps an administrator create or configure an app required by a plugin. It is not a ready-to-use connection. An admin may need to enter organization-specific details, create a draft, publish it, and assign access.
If that setup has not happened, installing the plugin does not make the template operational.
| Component | Primary purpose | Grants external access? |
|---|---|---|
| Skill | Reusable instructions and process | No, not by itself |
| App | Connect to data, tools, or actions | Yes, within configured permissions |
| App template | Configure an organization-specific app | Only after setup and publication |
What changed from the App Directory
All existing apps are packaged into plugins for discovery, and OpenAI says existing connections remain unaffected. New submissions also appear through plugin packaging. The directory is available on ChatGPT web and desktop and within ChatGPT Work and ChatGPT Codex.
The directory is visible across plans, but visibility is not access. Installation and invocation can depend on plan, workspace settings, role, surface, region, and the capabilities included by the plugin. A listing can be visible even when a required app is disabled.
OpenAI’s documentation says users can review a plugin’s included apps, setup requirements, connection requirements, terms, and privacy policy. Depending on availability, they connect the underlying app through OAuth and may enable sync. Plugins can then be selected in conversation, including through app mentions where supported.
Permissions do not move into the package
A plugin inherits the controls of every app it uses. Those controls may cover:
- users, groups, or roles that can access the app;
- read-only versus write actions;
- confirmation before actions;
- synchronized sources;
- domain restrictions;
- source boundaries and app-specific settings.
Approving a plugin does not override permissions in the connected system. A user who lacks access to a repository, folder, record, or channel should not gain it through Codex or ChatGPT. Both workspace access and source-system authorization must succeed.
This layered model prevents a workflow package from becoming a shortcut around governance. It also creates operational dependencies: disabling a shared app can affect several plugins, while uninstalling or disabling one plugin does not necessarily erase every underlying connection.
Why packaged workflows matter
The practical benefit is reuse. Before the directory, a user might connect an app and then invent a prompt sequence from scratch. A plugin can package the skill that explains how to use the connection for a specific outcome.
For example, a sales workflow may need a CRM app, a document app, and instructions for producing an account review. A data workflow may need a warehouse connection plus a skill for validating queries and formatting results. One listing can describe the complete capability rather than asking users to assemble the pieces mentally.
This also gives administrators a clearer rollout object. They can inspect the package, required and optional apps, templates, actions, and role assignments. “Installed” and “Available” remain installation policies, not grants of data access.
Plugins are not the same as MCP
Model Context Protocol can underpin a custom app connection, but a plugin and an MCP server are different layers. The server exposes tools or resources. The app configures and governs the connection. The plugin packages that app with workflow guidance or templates for discovery and reuse.
A skill-only plugin may have no MCP component. Conversely, an MCP server can exist without a published directory plugin. Keeping the layers separate helps security reviewers ask the right questions:
- What tools does the server expose?
- How is the user authenticated?
- Which tools read or write?
- What confirmations are required?
- What instructions does the skill add?
- Which plugin packages depend on this app?
OpenAI specifically recommends reviewing the server, authentication model, exposed tools, write behavior, and dependent plugin package before publishing a custom MCP app.
A safe rollout sequence
Start with a pilot group and read-only access where possible. Review the listing and the underlying app separately. Test with a low-risk prompt and a user whose source permissions match the intended role.
Before broader installation:
- confirm required apps and templates are configured;
- limit roles and synchronized sources;
- disable unneeded write actions;
- require confirmation for sensitive actions;
- review vendor, privacy, residency, and legal terms;
- verify logs and compliance events;
- define an owner for updates and incident response.
After launch, periodically review app permissions, action controls, sync boundaries, plugin updates, support issues, and usage. A plugin can evolve, and a once-safe package may add a new capability that deserves review.
What the directory does not guarantee
Directory presence does not guarantee that a workflow fits an organization, that its underlying vendor retains no data, or that its skill instructions are correct for every context. It also does not make a preview capability production-ready.
Users should distinguish between discovering a plugin, installing it, connecting required apps, and receiving authorization for a specific action. Those are separate steps by design.
From a reusable plugin to a production media workflow
Media automation is a useful example of how the layers can work without being conflated. A team could create a private skill that describes its approved workflow for producing a narrated clip: validate the script, confirm voice authorization, upload only approved assets, create tasks, poll status, check outputs, and request publication approval.
That skill could be packaged in a plugin. If the workflow calls a remote MCP media service, the corresponding custom app would need separate configuration and security review. The package would not make that service a native ChatGPT feature, and the existence of this design pattern does not imply that a public Medux plugin is currently listed.
Medux’s Codex MCP video-editing tutorial shows an actual external-tool sequence for adding audio to a video: inspect inputs, obtain upload URLs, create the asynchronous job, monitor it, and download the result. Its text-to-speech tutorial demonstrates a related workflow for authorized voice input and generated speech.
A reusable internal plugin could encode safeguards around those steps:
- a skill defines the approved procedure and validation rubric;
- an app connection exposes only necessary MCP tools;
- source permissions control which files the user can reach;
- confirmation gates uploads and billable transformations;
- task IDs and output URLs are logged for audit;
- a final human review gates publication.
The new Plugin Directory makes that kind of workflow easier to discover and distribute across ChatGPT Work and Codex. The enduring security model is still least privilege: instructions guide the agent, apps grant bounded authority, and people approve the actions that matter.