乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > Codex App Plugins 使用教程:装插件之前,先把权限看明白

Codex App Plugins 使用教程:装插件之前,先把权限看明白

当前时间： 2026-08-17 17:52:10 分类：办公文件 评论(0)
Codex App Plugins 使用教程:装插件之前,先把权限看明白

前几篇我们讲了 Codex App 的 MCP 和 Skills。

这篇继续往外扩一层，聊聊 Plugins 和 Connectors。

这两个词很容易混。

我刚开始用时，也会把 GitHub 连接、Skill、MCP 全叫成“插件”。实际用下来，最好还是分开理解。

最简单的记法是：

  1. Plugin是能力包。
  2. Connector/App是外部账号和数据的连接入口。
  3. Skill是一套可复用的做事方法。
  4. MCP 是给Codex提供工具和上下文的协议。

一个 Plugin 里可以同时装进 Skill、App 和 MCP server。

所以，安装插件不等于已经连接账号，更不等于它能直接读取你的所有数据。

这篇只解决三个问题：

  1. 插件怎么选
  2. 连接器怎么安全授权
  3. 第一次使用怎么验证

一、Plugin 到底是什么

Plugin 是一个可以安装、分发和关闭的能力包。

它可能只带一个 Skill。

也可能把多种能力放在一起：

  1. Plugin
  2. ├─Skills：固定工作流
  3. ├─Apps：GitHub、Slack、GoogleDrive等连接
  4. └─ MCP servers：额外工具或外部上下文

比如一个 PR Review Plugin，可能包含：

  1. 读取GitHub PR 的App
  2. 审查代码的Skill
  3. 查询内部规范的 MCP server

安装后，Codex 就多了一套可调用的 PR 审查能力。

这里有个很实用的判断标准：

如果你还在一个仓库里反复调整流程，先写 Skill。

当这套流程需要跨团队分发，或者需要连外部账号、附带 MCP 配置，再考虑做成 Plugin。

二、Connector 又是什么

Connector 在当前 Codex 文档里通常以 App integration 的形式出现。

它负责把 Codex 和外部服务连接起来。

常见场景包括：

  1. GitHub：读取 issue、PR 和评论
  2. Slack：整理频道讨论，起草回复
  3. GoogleDrive：查找Docs、Sheets和Slides
  4. Gmail：读取或处理邮件

它解决的是“数据从哪里来，以及可以做哪些动作”。

这和 Skill 不一样。

Skill 告诉 Codex 怎么完成一类任务，Connector 让 Codex 能接触到任务需要的外部信息。

举个例子。

你让 Codex 审查一个 PR：

  1. GitHubConnector提供 PR 描述和评论。
  2. 本地项目提供代码与 diff。
  3. PR ReviewSkill规定审查步骤和输出格式。

这三部分组合起来，才是一条完整工作流。

三、安装、授权、调用不是一回事

这一点最容易弄混。

一个插件从出现在目录里到执行任务，大致会经过这些步骤：

  1. 在Plugins目录找到插件
  2. →查看插件包含的能力
  3. →安装插件
  4. →登录或授权需要的外部App
  5. →新建线程
  6. →用自然语言或@显式调用
  7. →按权限和审批执行任务

安装，只是让插件里的工作流出现在 Codex 中。

如果插件包含 GitHub、Gmail 或 Google Drive，通常还要单独登录或授权。

有些插件会在安装时要求认证。

有些会等到第一次使用时再提醒。

所以遇到“插件已经安装，但读不到 GitHub”的情况，先别急着重装。更常见的原因是外部 App 还没连接，或者授权范围不包含目标仓库。

四、在 Codex App 里安装 Plugin

打开 Codex App，在侧边栏进入 Plugins。

插件目录通常会按来源分组：

  1. CuratedbyOpenAI
  2. Sharedwith you
  3. Createdby you

打开一个插件详情页，先看它包含什么。

不要只看名字和简介。

我会重点看这几项：

  1. 有没有外部App
  2. 有没有 MCP server
  3. 会不会运行本地命令
  4. 第一次使用需要什么账号权限
  5. 不用以后从哪里卸载或撤销授权

确认后再点击加号或 AddtoCodex。

安装完成后，新建一个线程再使用。

插件安装、启用或升级后，旧线程的能力列表未必会立即刷新。看不到插件时，新开线程往往比反复点击更有效。

五、第一次使用，先做只读试跑

插件刚装好，不要马上让它评论 PR、发送消息或修改外部文档。

先选一个只读任务。

以 GitHub 为例，可以这样写：

  1. 请读取这个 PR 的标题、描述和评论。
  3. 只做摘要，告诉我：
  4. 1.这次改动要解决什么问题
  5. 2.目前还有哪些未处理意见
  6. 3.哪些地方需要我人工判断
  8. 不要评论 PR，不要修改文件，不要创建分支。

这个任务能一次检查四件事：

  1. 插件是否可见
  2. 账号是否连接
  3. 目标数据是否有权限读取
  4. Codex是否遵守只读边界

四项都正常，再逐步开放写操作。

六、什么时候用 @ 显式调用

安装插件以后，你可以直接描述任务，让 Codex 自己选择合适的工具。

也可以输入 @，明确指定某个 Plugin 或它携带的 Skill。

第一次使用时，我更建议显式调用。

比如：

  1. @github请读取当前 PR 的评论。
  2. 只总结讨论，不修改文件，也不要回复评论。
  3. 如果无法读取，请告诉我缺少登录、权限还是目标资源访问。

这样做不是为了让提示词显得专业。

它只是减少歧义，方便确认这次任务到底用了哪个能力。

等工作流稳定以后，再改回自然语言也可以。

七、授权时到底要看什么

连接器接触的是你的真实账号。

点授权之前，至少看清四件事。

1. 数据范围

它能读取全部仓库，还是指定仓库？

能看到整个工作区，还是你主动引用的文档？

2. 动作范围

只有读取权限，还是可以评论、修改、发送消息？

只做总结的任务，不需要写权限。

3. 组织限制

公司 GitHub、Slack 或 Google Workspace 可能有管理员策略。

账号登录成功，不代表每个仓库和频道都能访问。

4. 撤销入口

在使用之前就要知道怎么关。

通常要同时检查 Codex 的插件页面，以及外部服务自己的授权管理页面。

权限不确定时，先选更小的范围。

后面确实需要，再增加。

八、GitHub Connector 的最小可用流程

GitHub 是最适合练手的连接器之一。

可以按这个顺序测试：

  1. 1.在Plugins中找到包含GitHubApp的插件
  2. 2.安装插件
  3. 3.完成GitHub登录或授权
  4. 4.确认允许访问的仓库范围
  5. 5.新建线程
  6. 6.引用一个 issue 或 PR
  7. 7.先做只读摘要
  8. 8.确认结果后，再决定是否允许评论或修改

一个更接近开发工作的提示词是：

  1. 读取当前 PR 的描述、review 评论和本地 diff。
  3. 请判断：
  4. 1.哪些 review 意见已经在本地改动中处理
  5. 2.哪些意见仍未处理
  6. 3.哪些结论缺少证据
  8. 只读，不提交，不推送，不回复GitHub评论。

这里最好把“本地”和“外部”分开看。

PR 评论来自 GitHub。

代码和 diff 来自当前项目。

最终判断由 Codex 根据两边信息完成。

九、插件装好了，为什么还是不能用

先按层排查，不要一上来就卸载重装。

插件目录里看不到

检查插件来源是否已经加入，安装后是否重启 Codex，或者是否需要新建线程。

能看到插件，但 @ 找不到

确认插件是否已安装并启用。

然后新开一个线程再试。

插件可调用，但读不到外部数据

检查外部 App 是否已登录、授权范围是否足够、组织策略是否拦截，以及当前账号能否访问目标资源。

Skill 可以用，MCP 工具不可见

插件携带的 MCP server 可能仍需要配置或认证。

安装 Plugin 不会替你跳过 MCP 的启动和鉴权要求。

读取正常，写操作失败

这通常是写权限不足，或者动作需要额外审批。

先确认这次任务是否真的需要写入，再调整权限。

十、卸载插件，不一定等于断开账号

这是第二个容易忽略的地方。

在 Codex 中卸载 Plugin，会移除这个能力包。

但插件安装过的外部 App 可能仍然保留。

如果你不再使用它，完整的下线流程应该是：

  1. 在Codex中卸载或禁用Plugin
  2. →在ChatGPT或外部服务中管理并移除App
  3. →撤销OAuth或账号授权
  4. →检查相关 MCP 配置
  5. →检查Automation是否仍在引用它

只删掉插件入口，不能代替外部服务的权限撤销。

如果只是暂时停用，也可以在 ~/.codex/config.toml 中关闭插件：

  1. [plugins."gmail@openai-curated"]
  2. enabled =false

修改后重启 Codex。

十一、Plugin、Skill、MCP 怎么选

最后用实际任务来判断。

一次性任务

直接写 prompt。

团队反复执行同一套步骤

先做 Skill。

需要浏览器、数据库或内部工具

考虑 MCP。

需要连接 GitHub、Slack、Drive 等账号数据

使用 App 或 Connector。

想把工作流、外部 App 和 MCP 一起安装、分享和管理

再做 Plugin。

插件不是越多越好。

先写清楚任务，再找最小的能力组合。

十二、团队使用插件，要多做一步

个人试用可以简单一点。

插件进入团队以后，最好留一份很短的登记：

  1. 插件名称
  2. 来源
  3. 维护人
  4. 主要用途
  5. 包含哪些Skills、Apps和 MCP
  6. 默认是只读还是允许写入
  7. 授权范围
  8. 如何停用和撤销

插件升级后，也要重新做一次只读试跑。

因为升级可能新增 MCP server、外部 App、本地命令，或者改变 Skill 的默认行为。

这不是为了增加流程。

团队需要的是：谁都知道它能做什么，也知道出问题时怎么停下来。

总结

Plugin 是能力包，Connector / App 是外部账号连接。

安装插件、授权账号和执行任务是三个不同阶段。

第一次使用时，先做只读试跑，再逐步开放评论、提交、发消息等写操作。

最后再提醒一次：

  1. 装之前看来源和权限。
  2. 第一次只读验证。
  3. 不用以后，插件和外部授权都要检查。

做到这几步，Plugin 才会从“多装了一个功能”，变成一套可控、可复用的工作流。