If you’ve been following the evolution of AI-powered development tools, you’ve probably noticed a recurring theme: the best tools aren’t just smart—they’re connected. OpenAI’s Codex has taken this principle to heart with their plugin system, and it’s worth understanding what this means for your workflow.
In this post, we’ll break down exactly what Codex plugins are, how they work, and why the architecture matters for developers who want to get serious about AI-assisted development.
What Are Codex Plugins?
At their core, Codex plugins bundle three types of capabilities into reusable workflows:
- Skills — Reusable instructions for specific kinds of work
- Apps — Connections to external tools like GitHub, Slack, or Google Drive
- MCP Servers — Services that provide additional tools or shared information
Think of a plugin as a capability package. Instead of manually configuring each integration, you install a plugin and get a coherent set of tools that work together. The Gmail plugin, for instance, lets Codex read and manage your email. The Google Drive plugin gives you access across Drive, Docs, Sheets, and Slides. The Slack plugin can summarize channels or draft replies.
This bundled approach is significant. Rather than treating each integration as an isolated feature, plugins create workflows where multiple capabilities can be orchestrated together.
The Three Pillars: Skills, Apps, and MCP
Let’s dig into each component because understanding the architecture helps you make better decisions about which plugins to use and how to use them effectively.
Skills: Contextual Instructions
Skills are reusable instructions that Codex loads when needed. They tell the agent how to follow the right steps, use appropriate references, and leverage helper scripts for specific tasks.
The key insight here is contextual loading. Codex doesn’t need to hold every possible instruction in memory at all times. When you invoke a skill, the relevant instructions and references get loaded, keeping the agent focused and efficient.
This is similar to how a skilled professional works—you don’t consciously think through every procedure you’ve ever learned. You load the relevant mental model when the situation calls for it.
Apps: External Connections
Apps are your bridges to external tools. When you install a plugin that includes apps, you’re enabling Codex to both read information from those tools and take actions in them.
The authentication flow is worth noting: some plugins prompt you to sign in during installation, while others wait until first use. Either way, your existing approval settings still apply. Installing a plugin makes its workflows available, but doesn’t bypass your security preferences.
This is a sensible default. You want capability without losing control.
MCP Servers: The Protocol Layer
MCP (Model Context Protocol) servers are perhaps the most interesting component for developers. These services give Codex access to additional tools or shared information, often from systems outside your local project.
If you’re building custom integrations or working with specialized infrastructure, MCP is where you’ll spend time. It’s the extensibility layer that lets organizations and developers create bespoke capabilities while maintaining a consistent interface.
Installing and Using Plugins
The installation process is straightforward in both the Codex app and CLI.
In the Codex App: Open the Plugins directory, browse or search for what you need, and select the plus button or “Add to Codex.”
In the CLI:
Run /plugins within Codex to open the plugins list, then select “Install plugin” on your chosen option.
Once installed, you have two primary ways to invoke plugin capabilities:
Natural Language: Simply describe what you want. “Summarize unread Gmail threads from today” or “Pull the latest launch notes from Google Drive.” Codex will choose the appropriate installed tools for the task.
Explicit Invocation: Type @ to invoke a specific plugin or skill directly. This is useful when you want precise control over which capability handles your request.
The natural language approach is convenient for exploration and ad-hoc tasks. Explicit invocation is better when you’ve established a workflow and want consistency.
Permissions and Data Flow
Here’s where things get appropriately nuanced. Installing a plugin makes its workflows available, but several layers of control remain in place:
- Your existing approval settings continue to apply
- Connected external services maintain their own authentication and privacy policies
- Bundled skills are available immediately, but apps may require additional sign-in
- MCP servers may need extra setup or authentication
When Codex sends data through a bundled app, that app’s terms and privacy policy govern the interaction. This is standard for any integration model, but it’s worth keeping in mind as you decide which plugins to trust with which data.
Managing Your Plugin Stack
Plugins aren’t permanent commitments. You can uninstall any plugin by reopening it from the plugin browser and selecting “Uninstall plugin.”
Note that uninstalling removes the plugin bundle from Codex, but bundled apps stay installed in ChatGPT until you manage them separately. This separation makes sense—you might want the app connection for other purposes even if you’re done with the specific plugin.
For more granular control, you can disable a plugin without uninstalling it. In ~/.codex/config.toml:
[plugins."gmail@openai-curated"]
enabled = falseRestart Codex after making this change. This approach is useful when you want to temporarily remove a capability without losing your configuration.
What This Means for Development Workflows
The plugin architecture signals a broader shift in how we think about AI development tools. Rather than monolithic systems that try to do everything, we’re moving toward composable capabilities that developers can mix and match.
This has several implications:
Specialization becomes viable. A plugin can focus on doing one thing exceptionally well, trusting that other plugins will handle adjacent concerns.
Enterprise customization gets easier. Organizations can build internal plugins that encode their specific workflows, standards, and integrations without forking the entire tool.
The ecosystem can evolve faster. New capabilities don’t require core updates. Third parties can extend the system while OpenAI maintains the platform.
Workflow portability improves. A well-designed plugin is essentially a workflow specification. It can be shared, versioned, and refined over time.
Building Your Own Plugins
If the curated plugin directory doesn’t cover your needs, you can build your own. OpenAI provides guidance on local scaffolding, marketplace setup, plugin manifests, and packaging.
This is where the MCP server capability becomes particularly valuable. You can expose internal APIs, proprietary databases, or specialized tools through a plugin interface, giving Codex access to capabilities that would never appear in a public directory.
The barrier to entry is reasonable for organizations already building integrations. If you’re comfortable with API development, plugin creation is within reach.
The Bottom Line
Codex plugins represent a mature approach to AI tool extensibility. By bundling skills, apps, and MCP servers into coherent packages, OpenAI has created a system that’s powerful enough for enterprise use while remaining accessible for individual developers.
The key principles are sound: capability without sacrificing control, composability without complexity explosion, and extensibility without ecosystem fragmentation.
If you’re using Codex and haven’t explored the plugin directory, it’s worth a look. And if you’re building development tools or workflows, the plugin architecture offers a model worth studying—whether or not you’re working directly with Codex.
The future of AI-assisted development isn’t just smarter models. It’s smarter integration. Plugins are one concrete step in that direction.