This is a Codex plugin catalog, not one executable
OpenAI Plugins is a source collection for extending Codex. Each plugin sits under plugins/<name>/ and must contain .codex-plugin/plugin.json. A bundle may also carry skills, app or MCP configuration, agents, commands, hooks, and assets. The default marketplace file points Codex at those local directories and records policies such as whether authentication happens during installation or first use.
commit 33bd952 contained 53 plugin manifests and 482 SKILL.md files. The breadth is useful for reading actual structure: Figma covers design workflows, Notion covers research and knowledge capture, and separate bundles address iOS, macOS, web apps, Expo, Netlify, Remotion, and Google Slides. It also means the repository has no single runtime story. Every folder can expose a different mix of instructions, remote connections, and executable behavior.
The 4-second install covers only plugin-eval
Our lab did not install all 4,421 repository files as one product. The Node project detected by the harness lives in plugins/plugin-eval, a private package that evaluates local skills and plugins. Its install completed in 4 seconds, added 0 packages, and occupied 1 MB. There is no build script or target, so the build step was skipped rather than passed.
That narrow scope matters when reading the lab card. A successful zero-dependency npm install says the evaluator has no declared package tree at commit 33bd952. It says nothing about signing into Figma, connecting an MCP server, running a deployment workflow, or granting a remote app access. The repository used 37.4 MB before installation and contained about 254,897 lines of source, much of it instructions and plugin assets rather than one JavaScript program.
What happened when we ran it
Our sandbox ran npm install successfully in 4 seconds with Node 22, then found no build target. The test step failed with exit code 1 after 8 seconds. The package script invoked node --test tests/**/*.test.js, and Node reported that it could not find /work/repo/plugins/plugin-eval/tests/**/*.test.js.
A test file does exist in that directory, and the repository scan marked a tests directory as present. The observed failure is the literal glob path, not a failed assertion inside the suite. We did not substitute another test command because the lab records the project's supplied target. Npm audit found 0 known vulnerabilities across the installed package set, which in this run contained 0 added packages.
The repository scan found 0 CI workflow files and no Dockerfile. Those absences fit a catalog better than a deployed server, but they reduce visible repository-level verification. The 8-second failure also leaves the checked-in evaluator's assertions unproven by our standard command. A team adopting plugin-eval should first make its test invocation work in the same shell and Node environment used by its own CI.
Marketplace policy does not replace a permission review
The marketplace describes plugins as available and can specify authentication at install or use. Some entries are restricted to Codex. That metadata answers discovery questions, but it does not tell a security reviewer what every skill may instruct the agent to do, which MCP tools are reachable, or what an app connection can read and change. Those answers live inside each selected bundle and its external service.
The repository tree includes 27 .app.json files and 26 .mcp.json files at the measured commit. Plugins can also supply hooks, commands, or agent definitions. Treat installation as adding several control surfaces, even when the files are mostly text. Review the manifest, skills, connection configuration, authentication timing, and any command or hook before making a plugin available across every workspace.
Licensing needs the same per-folder attention. GitHub's repository metadata returned no top-level license, while our tree check found license files in only some plugin directories. That does not make every unlicensed folder forbidden, nor does a licensed subfolder cover its neighbors. It means a company intending to copy, modify, or redistribute a bundle should identify the license that applies to that exact directory instead of inferring one from the OpenAI owner name.
Plugin-eval separates static checks from live Codex runs
The included plugin-eval package is the closest thing here to a standalone tool. It requires Node.js 20 or newer and can run directly from its folder or through npm link. Static commands analyze a plugin, explain token budgets, or propose a measurement plan. The benchmark command is different: it launches real codex exec sessions in isolated temporary workspaces and stores run artifacts under .plugin-eval/.
Its guide tells users to inspect generated benchmark configuration, especially when prompts or the target project came from elsewhere. That warning is the right operational boundary. Static scoring can be part of routine review, while live benchmarks consume model usage and execute an agent workflow. Keep artifacts and local node_modules out of commits unless they are intentional records, and use a disposable target for unfamiliar benchmark scenarios.
August pushes show activity without a release channel
GitHub recorded the last push on August 26, 2026, and 40 combined issues and pull requests. The latest open activity fetched for this review was concentrated in pull requests updated during June and July, including plugin syncs, skill changes, connector work, and scheduled-task templates. GitHub returned no latest release, so there is no repository-wide version tag to use as a compatibility promise.
For plugin authors, this is still the most direct public reference for Codex's own curated bundles. Read it folder by folder, copy structure only when the applicable license permits it, and pin commit 33bd952 or a later revision you have reviewed. For ordinary Codex users, installing one needed plugin is more defensible than cloning the catalog wholesale. The test-path failure makes local verification part of adoption, not an optional cleanup task.