OpenAI Plugins: package examples, portable formats and connection boundaries
OpenAI Plugins explained: an example catalogue, not one universal runtime
Understand the openai/plugins repository, how packages combine skills and connections, and why its pinned compatibility layout differs from current portable guidance.
What you will learn
- Identify the repository before interpreting the name
- Read the pinned examples alongside current documentation
- A package does not grant access by itself
Before you start
- Basic JSON and directory-path knowledge
- Understanding of skills and external-service permissions
Distinguish source examples from current format guidance and inspect a package without confusing metadata with runtime proof.
Key takeaways
- The repository is a catalogue of individual plugin examples.
- Pinned compatibility examples and current portable guidance must be distinguished.
- Discovery, authentication and action authorization are different gates.
Identify the repository before interpreting the name
At commit 1dc1958, openai/plugins describes a curated collection of Codex plugin examples. Individual packages live under plugins, while marketplace JSON files describe which entries to offer. This is not one executable product, a new model, or evidence that every listed service is available to every account.
A package can combine reusable instructions, connected tools and supporting resources. A marketplace answers where a package comes from; its manifest identifies the package; a skill describes a workflow; a service connection supplies capabilities. Keeping those responsibilities separate makes installation and troubleshooting much easier to reason about.
Read the pinned examples alongside current documentation
The repository README describes .codex-plugin/plugin.json as required for its examples. Official packaging guidance checked on September 14 recommends a portable root plugin.json and treats the Codex manifest as a supported compatibility layout. The examples and the newer recommendation are different source scopes, not interchangeable statements about every package.
For this series, repository claims are pinned to one commit and product-format claims cite the dated official page. We do not silently rewrite the repository into the portable format or pretend the official page is immutable. If you build a new package later, recheck the current host documentation rather than copying a historical example uncritically.
A package does not grant access by itself
The Figma example points to an app mapping and bundles design workflows. Its manifest declares capabilities and presentation details, but those labels do not authenticate a user or approve a write. A usable workflow still depends on connection access, host permissions and a request whose scope permits the action.
We inspected fixed repository files and official packaging guidance, and built a small synthetic manifest-selection model. No plugin was installed, no account was connected and no Figma document was changed. The series teaches package boundaries and review methods without presenting those checks as successful live integration.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Identify the specific package and pinned revision.
- 2
Separate catalogue, manifest, skill and connection responsibilities.
- 3
Check the current host format before authoring a new package.
Copy-ready example
{
"reviewScope": "openai/plugins",
"revision": "1dc195897af4161d039b80d8471ec0a10c9bbc89",
"repositoryLayout": "Codex compatibility examples",
"currentGuidance": "portable root manifest",
"liveInstallationTested": false
}Frequently asked questions
Is this repository a single server I can deploy?
No. It contains individual examples with different skills, connections and runtime needs.
Does a Write capability label approve a write?
No. Metadata is not user authorization or service access.
Sources
- OpenAI Plugins / README.mdSource checked 2026-09-14
- OpenAI Plugins / plugins/figma/.codex-plugin/plugin.jsonSource checked 2026-09-14
- OpenAI Plugins / plugins/figma/README.mdSource checked 2026-09-14
- OpenAI — Package your plugin (checked 2026-09-14)Source checked 2026-09-14