07 | Codex Plugins and Connectors: Install, Authorize, and Govern
Installation, authorization, and use are separate
The upstream guide makes an important distinction: seeing a plugin or connector does not mean it is installed; installation does not mean it is authorized against an external system; authorization does not tell you which capabilities are appropriate for a particular task. Keeping these stages separate makes both troubleshooting and governance clearer.
Before connecting anything, state the target system, business purpose, least permissions required, owner, and revocation method.
Four concepts, four roles
- Plugin: a distributable, reusable package of capabilities.
- Connector: the path for connecting and authorizing an external service.
- MCP: the protocol and server that expose tools to Codex.
- Skill: a process for performing and delivering a task type.
They are not mutually exclusive. The course’s GitHub example starts with read-only repository and PR context, then applies a clear review Skill. If writing is unnecessary, do not request write permission.
A least-privilege first connection
- Discover a capability from a trusted source in the App.
- Read its required permissions and data scope.
- Complete read-only authorization and verify it with one small task.
- Record its version, authorized identity, accessible resources, and owner.
- Revoke, disable, or remove it when it is no longer needed.
CLI can help manage sources and diagnose problems, but it cannot replace human permission judgment.
From personal trial to team governance
Before sharing with a team, maintain a small governance record: source, maintainer, permitted projects, external tools or secrets, and upgrade/rollback procedure. A capability should become a team asset only when it is repeated, stable, and explicit about its permissions.
Plugins should make work more reusable and reviewable—not bring opaque external actions into a project.