装 Codex 插件，会不会把公司数据全交出去？

Codex 现在有了 Plugin Directory。你可以装一个插件，让它查 GitHub、读 Slack，或者从 Google Drive 找资料。

问题也跟着来了：点下“安装”，是不是相当于把整个公司账号交给了 Codex？

先说答案：不会因为安装一个 Plugin，就自动获得公司里的全部数据。

但这句话只说了一半。Plugin 如果带有 App，而 App 已经启用，用户也完成了连接，那么它确实可能读取这个账号原本有权访问的内容，或者执行管理员允许的动作。

判断一个 Plugin 的访问范围，要把这次访问拆开看：它经过了哪几层权限，每一层放行了什么？

先用 60 秒分清三个词

Codex 的 Plugin 可以理解成一个可安装的工作流能力包。它可能装进下面两类东西。

Skill 提供的是可复用的说明、步骤和参考资料，告诉 Codex 遇到某类任务时怎么做。它本身不是 Slack 或 GitHub 账号，也不会凭空带来外部数据。

App 才负责连接外部系统的数据与动作。一个 Plugin 如果需要查仓库、读消息或处理文档，通常要依赖相应的 App。App 可能需要管理员启用，也可能要用户自己登录授权。

有些 Plugin 还带 App template。它只是配置模板，不是一条已经接通的数据连接。管理员可能仍要填入组织配置、创建并发布 App，再把访问权分配给成员。

如果你从 Claude Code 迁移过来，先不要把两边的 Plugin 当成完全相同的东西。本文只讲理解 Codex 数据权限所需的部分；两套机制的完整对比留到下一篇。

第一层：Plugin 带来了什么

安装前，最先看的是 Plugin 里面有什么。

只包含 Skill 的 Plugin，主要改变 Codex 处理任务的流程。包含 App、connector 或 MCP server 的 Plugin，则可能连接项目以外的系统。

Plugin 安装和底层 App 访问是两个开关。 OpenAI 的官方说明把两者分开管理。管理员可以让某个 Plugin 对成员可用，同时关闭里面不需要的 App；也可以只允许部分角色使用某个 App。

因此，看到一个 Plugin 出现在目录中，不代表它包含的每项能力现在都能运行。真正使用时，还要继续通过下一层。

第二层：App 被允许做什么

App 决定工作流能接到哪里，也决定它能对外部系统发起哪些操作。

在支持相应控制的 App 中，管理员可以限制哪些用户或角色能用它，允许只读还是写入，也可以决定某类动作执行前是否询问。同步型 App 还可能限定文件夹、仓库、space 或 channel。

这些设置常被统称为“管理员授权”，实际管的是几件不同的事：

• • RBAC 决定谁能使用这个 App；
• • Action control 决定它可以执行哪些动作；
• • App permissions 决定运行某些动作前是否询问。

并不是每个 App 都支持完全一样的动作控制，设置入口也会随套餐、workspace 和产品上线范围变化。因此，通用文章无法替代具体 App 的权限页面。

第三层：你在源系统里本来能看什么

即使 Plugin 和 App 都已打开，Codex 也不会因此获得一个权限更高的 Slack、GitHub 或 Drive 账号。

OpenAI 的官方说明很明确：批准 App 不会覆盖连接系统原有的权限。用户看不到的文件、仓库、记录或 channel，不应因为安装 Plugin 而变得可见。

如果用户本来就能读取某个私有仓库，App 已被管理员开放，而且连接时使用的正是这个账号，那么依赖该 App 的工作流可能读取仓库中被授权的内容。

这也是为什么“不会自动获得全部数据”不能被写成“绝对不会碰到敏感数据”。访问范围最终取决于具体账号、外部系统的访问控制、App 请求的权限范围，以及管理员对 App 的限制。

第四层：这次运行还能不能被拦住

当 Plugin 的能力通过 Codex host 执行时，sandbox、approval policy 和本地管理策略仍然生效。

它们可以继续限制文件读写、命令执行、网络访问或需要人工确认的动作。不过，这一层只能约束本次运行，不能反过来给用户增加 workspace 功能，也不能授予外部系统的数据权限。

这几层像四道门：Plugin 让工作流出现，App 让外部工具可用，源系统账号决定能看到哪些资源，运行策略再限制这一次可以怎么做。最终权限取它们共同放行的范围。

安装、连接、使用，分别看什么

面对一个陌生 Plugin，不必从一长串安全术语开始。按三个时点看，通常更清楚。

安装前：看它带了什么

先区分 included skills、required apps、optional apps 和 app templates。纯 Skill 工作流与需要外部 App 的工作流，数据边界不同。

不要从 Plugin 名称猜权限。一个名为“销售助手”的 Plugin 可能组合多个 App；真正的数据范围要回到每个 App 的说明和配置中核对。

连接时：看账号和动作范围

确认 App 是否对当前角色开放，是只读还是允许写操作，哪些动作会要求确认。如果 App 支持同步范围或来源限制，再看它覆盖的是哪些文件夹、仓库、space 或 channel。

还要确认连接的是哪个外部账号。公司账号和个人账号在源系统里的权限不同，Codex 最终能获得的内容也不同。

使用与退出时：看一次动作和连接生命周期

使用时，读取一份文档和发送一条消息不是同一类操作。前者取回信息，后者会在外部系统产生效果。管理员设置和运行时批准会影响这类动作是否执行。

退出时还有一个反直觉的细节：OpenAI 的 Codex 文档说明，卸载 Plugin 不会自动断开它包含的 connector。Plugin bundle 被移除后，已有连接仍要在 ChatGPT 中单独管理。

Plugin、App 与外部账号连接有各自的生命周期。卸载 Plugin 后，外部授权未必已经撤销。

把“安不安全”换成四个具体问题

“装这个 Plugin 会不会把公司数据全交出去”听起来直接，却把几层权限揉在了一起。换成下面四个问题，会更容易得到可验证的答案：

1. 1. 这个 Plugin 具体带了哪些 Skill、App 或模板？
2. 2. 底层 App 对哪些角色开放，允许读取还是写入？
3. 3. 当前连接账号在源系统中原本能访问哪些资源？
4. 4. 这次运行还受哪些 sandbox 和 approval 限制？

Plugin 安装不是数据权限总开关。它也不是一张“装了就安全”的保证书。真正的访问范围，来自多层控制共同允许的那一部分。

如果要把这篇文章转给同事，最合适的人可能不是普通使用者，而是负责 App 授权、源系统权限或安全审核的人。大家先确认讨论的是哪一层，很多争论会简单不少。

下一篇继续回答迁移用户更容易混淆的问题：从 Claude Code 转到 Codex，Plugin 还是同一种机制吗？

参考资料

• • OpenAI：Plugins in ChatGPT and Codex
• • OpenAI：Admin controls, security, and compliance for plugins and apps
• • OpenAI Codex Manual：Plugins
• • OpenAI Codex Manual：Roles and workspace permissions