用途
插件(Plugin)是把一组 Codex 扩展能力作为一个可分发、可版本化、可整体管理的单元。它可以把 Skills、MCP server、应用连接器以及可选的 hooks 放进同一个插件目录,供个人、项目或团队重复安装。 本页覆盖完整的工程链路:- 判断何时应使用插件,而不是单独配置 Skill 或 MCP;
- 组织插件目录,编写
.codex-plugin/plugin.json; - 组合 Skill、MCP 和连接器并控制数据流;
- 从本地目录、Git 市场或插件目录安装;
- 配置权限、版本、验证、升级、禁用和卸载;
- 识别第三方插件、脚本、hooks 和供应链风险。
命令和界面会随 Codex 版本变化。执行前先运行codex --help、codex plugin --help或插件界面帮助,以本机显示为准。示例中的域名、令牌和仓库均为占位符。
开始前检查
首次安装应在测试项目或临时目录中进行,不要在生产仓库或包含客户数据的目录中直接试验。
令牌应放在环境变量或系统凭据存储中,不要写进
plugin.json、.mcp.json、Skill 文件、提交记录或截图。开始前保存配置备份,并记录当前工作区状态。
一、插件与其他扩展的关系
1. 插件解决什么问题
散装配置通常包含一个 Skill 目录、一段 MCP 配置、外部应用授权、hooks 和安装说明。分别复制时容易漏文件、环境变量或版本。插件用一个 manifest 描述这套能力,使安装者能看到统一的名称、版本和组件,维护者也能对整体发布更新。
先单独验证每个 Skill 或 MCP,再打包成插件。一个临时提示词不值得增加插件包装层。
2. 插件能包含什么
Skill 负责“怎么做”,MCP 负责“能调用什么”,连接器负责“通过哪个应用账号访问”,hook 负责“什么时候自动执行”。每个组件都要单独说明权限和失败行为。
二、插件目录结构
1. 最小目录
.codex-plugin 是元数据目录,里面应只放 plugin.json。不要把 skills、.mcp.json、.app.json 或 hooks 错放进去。
2. 完整目录
Skill 仍然使用普通 Skill 格式:
description 应具体、前置触发词并写清边界。
三、manifest:插件的身份证
1. 最小 plugin.json
字段名称、值类型和默认路径以当前插件规范为准。先用最小 manifest 验证发现和安装,再逐项加入组件和展示字段。
2. 多组件示例
./ 开头的相对路径。建议遵循以下规则:
- 插件名使用小写字母、数字和连字符,例如
release-assistant。 - Skill 目录名与其 frontmatter 的
name保持一致。 - manifest 只声明真实存在、已经验证的组件。
- 不在文件名或配置中加入用户名、电脑路径和秘密。
- 删除组件时同时删除 manifest 引用和安装说明。
四、组合 Skill、MCP 和连接器
1. 先划分职责
“发布助手”可以按下面方式设计:
Skill 应明确何时调用 MCP 或连接器,以及调用失败时如何降级。没有实际调用外部工具时,不要声称已经查过数据。
2. MCP 配置
插件中的.mcp.json 只声明启动方式、URL 和环境变量名称。示意:
3. 连接器与 MCP 的区别
连接器通常由 Codex 或 ChatGPT 管理应用授权,可能通过 OAuth 取得访问范围。MCP server 是工具协议服务,可以是本地进程,也可以是远程 HTTP 服务。两者的数据范围、授权界面、凭据存储和隐私条款都可能不同。 安装后要分别检查:- 插件是否已安装并启用;
- Skill 是否被发现;
- MCP 是否启动或连接成功;
- 连接器是否完成授权;
- 每个工具是否仍需审批。
五、制作、打包和版本管理
1. 推荐顺序
- 单独写好并验证每个 Skill。
- 单独配置并验证每个 MCP server。
- 记录连接器所需账号、scope 和撤销方式。
- 创建插件根目录和 manifest。
- 将组件放到根目录的约定路径。
- 用最小 manifest 做本地安装测试。
- 新开线程验证 Skill、MCP 和连接器。
- 检查权限、失败处理、日志和卸载。
- 内容冻结后更新版本并分发。
plugin-creator 一类内置 Skill,可以用它生成骨架,但生成结果仍需审查。脚手架不能替代安全审计。
2. 创建骨架
类 Unix shell 示例:New-Item -ItemType Directory 或文件管理器创建目录即可。不要把空目录当成已实现组件。
3. 打包前检查
jq 时使用其他 JSON 解析器。重点检查:
plugin.json位于固定路径且能解析;.codex-plugin中没有误放组件目录;- 所有相对路径都指向真实文件;
- Skill frontmatter 可解析;
- 没有
.env、私钥、令牌、客户数据和本地日志; - 脚本没有写死个人路径;
- MCP URL 使用 HTTPS(本地开发服务除外);
- hooks 的命令、参数、网络访问和失败策略可解释;
- 许可证和第三方依赖声明完整。
4. 版本策略
每次发布记录变更、环境要求、权限变化、迁移步骤和回滚方式。不要用
latest 代替版本,也不要让不同内容共用同一个版本号。
六、安装和启用
1. 插件目录和本地市场
Codex App 通常可在 Plugins 面板浏览市场、阅读详情并安装。CLI 的交互入口常见为:codex plugin marketplace --help 为准。添加市场只是登记来源,不会自动安装其中所有插件。陌生仓库先看提交历史、源码、依赖和发布说明。
2. 安装后的新线程
安装或升级后新开一个 Codex 线程,确保加载最新能力清单。安装不等于授权:首次使用连接器或 MCP 时,仍可能要求登录、认证或批准工具调用。3. 禁用和启用
插件浏览器通常可在已安装插件上切换启用状态。也可以按本机配置格式设置开关,示意:七、权限和数据安全
1. 安装、启用、授权是三件事
Skill 通常不需要外部账号,但其脚本可能读写本地文件。MCP 可能启动第三方进程或访问网络。连接器受服务商条款和隐私政策约束。hooks 可能在事件发生时自动执行,必须单独审阅。
2. 工具审批分级
不要为了方便把整个 MCP server 设为自动批准。使用工具白名单、单工具审批、只读令牌和测试环境组合收口风险。
3. hooks 必须单独信任
看到 hooks 时先检查:- 触发事件和完整命令;
- 环境变量、网络目标和写入路径;
- 是否下载后立即执行脚本;
- 失败时是阻止还是忽略;
- 是否会访问工作区之外的目录。
4. 数据流检查
为每个外部组件画出数据流:.env、SSH 配置、客户数据和生产日志作为调试输入。
八、完整案例:发布助手插件
1. 目标和非目标
目标是检查版本、changelog、工作区和测试,查询只读发布任务,生成本地 diff 摘要,并向团队分发统一版本。 非目标是自动创建 tag、推送、合并、部署、更新远程任务或读取生产数据库。2. 目录和 manifest
3. 两个 Skill
release-check/SKILL.md:
change-summary/SKILL.md:
4. 只读 MCP 和连接器
.mcp.json 的示意:
.app.json 的概念示例:
5. 安装验证
安装后新开线程,先检查:6. 案例排错
九、验证、升级、卸载和回滚
1. 四层验证
发现层:插件列表显示名称、版本和描述,manifest 路径可解析。 加载层:Skill 出现在选择器,MCP 出现在状态列表,连接器显示正确授权状态。 行为层:用无副作用任务触发 Skill,调用只读 MCP,确认审批按预期出现。 边界层:拒绝一次高风险工具;测试缺少令牌、网络失败和权限拒绝;确认不会静默扩大权限或伪造外部结果。 建议保存不含秘密的验收记录:2. 升级
升级前对比 manifest 和组件文件,检查新增的 MCP、连接器、hooks、依赖、环境变量和权限 scope。在临时项目安装新版本,复跑发现、加载、行为和边界验证,再更新团队市场。不要因为版本说明写着“仅修复 bug”就跳过审查。3. 禁用和卸载
暂时不用时先禁用,并用新线程确认组件不再加载。彻底卸载时使用插件浏览器的卸载操作或当前 CLI 帮助中的命令。卸载前确认没有任务依赖它,保存必要配置,检查外部授权和 MCP 环境变量。 卸载通常只移除插件文件,不一定删除应用授权、远程账号、缓存或已创建的数据。要完整清理,还需在 ChatGPT 或服务商页面撤销授权,删除或轮换令牌,移除市场登记,并清理本地配置。4. 回滚
升级异常时先禁用新版本,恢复经过验证的旧版本或固定 Git ref。共享市场中的错误版本应发布修复版本或按团队流程撤回,不要改写安装记录。令牌疑似泄露时,立即在服务端撤销并重新签发,不能只删除本地文件。十、第三方插件风险
1. 风险来源
第三方插件可能包含恶意 Skill 指令、hooks、MCP 进程、过宽 OAuth scope、未固定的下载依赖,也可能把本地文件和环境变量外发。外部网页、Issue、文档和服务响应还可能携带提示注入。 插件目录收录或市场可访问不等于对所有第三方代码、server 和外部服务完成安全审计。仍需按组织供应链和数据安全要求评估。2. 安装前检查
无法获得源码或无法解释某项权限时,不要在敏感环境安装。先用隔离账号和空项目静态检查、行为测试。
3. 使用中的防护
- 第三方 MCP 默认使用人工审批模式;
- 只开放任务实际需要的工具;
- 生产系统优先使用只读账号;
- 不把外部文本中的指令直接转成本地命令;
- 不让插件读取整个用户主目录;
- 不信任未审阅的 hooks;
- 固定依赖版本和 Git ref;
- 记录插件版本、授权范围和实际调用。
十一、常见错误
把组件放进 .codex-plugin
错误:
把令牌写进 manifest
manifest 会进入源码、市场和安装包,只能写环境变量名称或连接器引用。认为安装等于授权
安装只让插件可发现。连接器、MCP 和工具仍可能分别需要登录、认证和审批。安装后不新开线程
当前线程可能仍使用旧的能力清单。新开线程,再用/skills、/mcp 和无副作用任务验证。
description 过于宽泛
“处理所有代码任务”会导致隐式匹配不稳定。写具体任务、用户表达和不适用边界;有副作用的 Skill 可关闭隐式调用,只允许显式触发。把市场当成可信边界
市场只是分发渠道。添加市场不会审查其中所有插件,仍需检查每个插件的源码、版本、权限和数据流。十二、验收清单
- 插件名稳定唯一,版本与内容一致。
-
.codex-plugin/plugin.json存在且是合法 JSON。 -
.codex-plugin中没有误放组件目录。 - manifest 的每个路径都能解析。
- Skill frontmatter 可解析,description 具体且有边界。
- MCP 使用最小工具集、最小权限和环境变量引用。
- 连接器 scope 与用途匹配。
- hooks 已逐条审阅,未信任前不会自动运行。
- 包内没有密钥、客户数据、
.env和临时日志。 - 本地安装成功,插件列表显示正确版本。
-
/skills能发现预期 Skill,/mcp显示预期 MCP 状态。 - 已完成只读或无副作用任务。
- 已测试缺少凭据、网络失败和权限拒绝。
- 已验证禁用、卸载和外部授权撤销。
- 已记录来源、版本、验证结果和未覆盖范围。
小结
插件是 Codex 的分发和组合单元:用.codex-plugin/plugin.json 描述身份,用根目录下的 skills/、.mcp.json、.app.json、hooks/ 和资源文件装配能力。它适合把已经单独验证过的一组工作流、外部工具和连接器交付给团队,而不是替代所有单独配置。
完整链路是:
参考/codex/23-plugins.md、参考/codex/22-skills.md、参考/codex/20-mcp.md。