Codex 能读代码，改代码，跑命令，这些都是它自带的本事。插件加的是另一层东西：让它连上浏览器，连上邮箱，连上仓库，或者拿到某个专项能力。

它和 Skill 容易被混在一起说。简单讲，Skill 是工具箱里的一本说明书，插件是装着说明书和各种工具的那个箱子。装一个插件，等于一次性把一套流程和它需要的连接配置都带了进来，不用再逐个目录复制。

插件能补上哪些能力

插件类型	能让 Codex 做什么
Chrome	打开网页，检查页面，配合浏览器调试
Gmail	总结邮件，草拟回复
Google Drive	读取文档，表格和幻灯片
Slack	总结频道消息，草拟团队回复
Security	检查代码里的安全问题
Computer Use	操作电脑上的应用

换个角度看，插件页里的能力方向大致分几类。

能力方向	包含插件	适合做什么
浏览器与电脑操作	Chrome，Computer Use	网页测试，自动点击，软件操作
代码与项目协作	GitHub	管理仓库，修 bug，创建 PR
前端与设计	Build Web Apps，Figma	生成网页，设计稿转代码
办公交付	Documents 与 Presentations，Spreadsheets	文档，PPT，表格分析
视频生成	HyperFrames，Remotion	用代码或 HTML 生成视频

插件目录会跟着版本，工作区和账号权限变化，实际能装什么以当前插件页为准。

插件，Skill，MCP 各管一层

对比	插件	Skill	MCP
一句话	能力安装包	一套固定工作方法	连接外部工具的接口
解决什么	安装和分发能力	同类任务怎么做	连接什么工具或数据
范围	最大，可以打包 Skill 和 MCP	较小，单类任务的流程	单个外部工具或数据源
谁用	普通用户也能一键安装	普通用户也能用	偏开发者和团队配置
举例	GitHub 插件，Figma 插件	README Skill，代码审查 Skill	数据库 MCP，文档 MCP

插件可以把 Skill 和 MCP 打包成更容易安装的能力包。要判断一个需求落在哪一层，看它问的是怎么做，还是连什么工具。前一个问题用 Skill，后一个问题用 MCP。

在 App 和 CLI 里安装

桌面端从插件页搜索或者浏览，点开详情能看到它要什么权限，确认之后再点添加。装完新开一个 thread 才会生效。

CLI 里进入项目目录启动 codex，输入 /plugins 打开列表。搜索和查看详情在同一处，安装和卸载各有对应项，空格键用来对已装的插件启用或者停用。

插件里装的是什么

一个插件能打包的东西不止 Skill。规范的插件目录里，.codex-plugin/plugin.json 是必需入口，其余文件按需要存在。

目录或文件	打包什么
skills/	可复用的任务流程
hooks/	在生命周期事件里自动运行的检查
.mcp.json	MCP 服务的连接配置
.app.json	外部应用集成，比如 GitHub 和 Slack
assets/	图标，logo 和截图

最小的 plugin.json 只声明名称，版本和描述，再加一条 skills 路径就够了。需要更多能力再往下加字段。interface 用来控制插件在安装界面里的名称，描述，图标和默认提示词。除 plugin.json 放在 .codex-plugin/ 里，其他文件都放在插件根目录，路径用 ./ 开头。

装之前和装之后要注意什么

安装插件不等于自动获得权限，权限设置，沙盒和审批策略都还管着它，外部服务的登录状态也一样。

插件里如果包含 Hooks，不应该默认信任。非托管的 Hook 通常要经过用户审查才会运行。

涉及浏览器，邮箱，知识库或者项目管理工具的插件，先确认它是只读还是可写。会写回外部系统或者要共享给团队的时候，最好保留一次人工复核。

团队共享的 Skill 和插件不要写个人路径，也不要把个人 token 或者只在某台电脑上存在的脚本打进去。

收尾

如果只是想试用，先去插件页找一个和自己工作流对得上的装上，用几次再决定要不要自己做。要自己做的，从 Skill 起步就够了。等到这套能力要分享给团队，或者得和 MCP，Hooks 和 App 集成一起分发，再考虑打成 Plugin。