Terms in this guide: Acceptance criteria · Verification
Understand what a Codex plugin can contain, where support differs, and how AboutCodex should review an installable capability bundle.
What belongs in this directory
The plugin directory should help a visitor understand the problem solved, included capabilities, supported interfaces, dependencies, external connections, permissions, and review date. It should link to the official marketplace or maintainer source rather than mirror packages without clear redistribution rights.
Keep standalone skills in the skill library. A plugin belongs here when the installable bundle combines multiple reusable capabilities or connected tools.
Engineering and code quality
This category includes review, testing, security, migration, deployment, repository, and issue-management workflows. Listings should distinguish analysis from authorized mutations and identify any command, hook, or external system the plugin can invoke.
Knowledge and documentation
These plugins provide source retrieval, document workflows, or research procedures. Review citation quality, file access, data retention, and whether a connected source is current enough for the claims the workflow makes.
Design, content, and publishing
This category covers visual creation, website building, editorial workflows, and content systems. Note which files or accounts the plugin can change, whether generated media has appropriate usage rights, and which review step precedes publication.
Operations and connected work
Calendar, messaging, storage, CRM, project-management, and business-data plugins can read or update systems outside the codebase. Authentication and approval remain important after installation. A plugin may be present while one of its servers is still disconnected or unavailable.
AboutCodex review card
For each entry show: primary task, included skill or server types, supported interfaces, authentication, data shared, write actions, maintainer, version or review date, setup link, limitations, and evidence status. Retain old review dates rather than presenting an unreviewed listing as fresh.
A plugin entry needs more than a name
Each directory entry should answer six questions: what reader task it supports, which Codex or ChatGPT surfaces support it, what components it bundles, which account or service it connects, what permissions it requires, and how its behavior was checked. This turns the directory into a decision tool instead of a copied marketplace list.
Separate the plugin package from its connected services. Current OpenAI documentation describes plugins as bundles that can include skills, MCP servers, browser extensions, and lifecycle hooks. Authentication and permissions still belong to the individual component or service. A reader should see that boundary before installation.
Keep availability claims current
Plugin support differs across clients and can change. Add a review date and link directly to the current support documentation rather than presenting a timeless compatibility table. When an entry is not tested by AboutCodex, describe it as source reviewed and name the source.
A useful update process checks removed packages, renamed components, changed installation paths, new permission requirements, and broken source links. Retain historical notes only when they help readers migrate. Never use an old listing as proof that a current installation path works.
Primary source
OpenAI plugin documentation. Source checked September 10, 2026.
Progress stays in this browser. No account needed.
Updates and upgrade guidance
- Learning context added
Added prerequisites, a suggested practice estimate, expected output, and connected definitions. The article procedure was not independently re-evaluated in this change.
What to do: Use the opening checklist to prepare. No software update is required for this editorial change.
This log starts with the first recorded review; it is not a reconstruction of earlier revisions.