给 Codex 装插件前要审什么？
Codex 插件安装或上线前，按来源、manifest、命令权限、网络访问、密钥读取、更新机制和回滚方案做安全评审。
适用场景：插件能提效，也可能扩大风险
这篇适合团队给 Codex 安装个人插件、内部插件、第三方工具包或自动化办公扩展之前阅读。插件可能带来快捷命令、固定提示、文件模板、外部服务连接和 AI API 接入能力，但它也可能读取工作区文件、执行命令、访问网络、保存日志或影响模型调用管理。很多事故不是插件本身恶意，而是安装时没有看清权限，后面又把它用在生产仓库、客户资料和含密钥目录里。
永沃云枢在 https://ai.jn83.com 维护 Codex 实操内容时，会把插件当成“代码和权限的组合”来审，而不是只看功能介绍。一个插件说自己能提升效率，不代表它适合进入所有项目。尤其是涉及 CCSwitch 配置、开发者 AI 调用、账单数据和客户文档的场景，默认要先从只读和测试仓开始。
操作步骤：安装前做一次轻量安全评审
第一步，看来源。确认插件来自可信仓库、内部负责人或明确版本包。不要从聊天记录、压缩包、网盘链接里直接安装。仓库里应有说明、变更记录和权限解释。没有维护者、没有版本号、没有源码或说明含糊的插件，不要进团队默认环境。
第二步，看 manifest 和脚本入口。重点关注它会注册哪些命令、读取哪些目录、是否需要网络、是否会写入配置、是否会上传内容。若插件声明要读取全盘文件或执行任意 shell，要问清楚具体功能为什么需要这个权限。
第三步，隔离试跑。新插件先在测试工作区运行，里面只放脱敏样本和可删除文件。让 Codex 执行最小任务，观察生成的文件、日志、网络请求和错误提示。不要在第一次运行时就给生产 API Key、客户合同、数据库连接串。
第四步，记录回滚方法。包括如何禁用插件、删除本地缓存、撤销环境变量、还原配置文件和通知团队。插件出问题时，最怕只知道“装过”，却不知道它改了哪里。
常见问题/避坑：功能越方便，越要看边界
一个常见坑是把插件和提示词混为一谈。提示词只是行为建议，插件可能真的执行代码、访问网络或写文件。另一个坑是团队里每个人各装一套插件，排查问题时无法复现。建议建立插件清单，记录名称、版本、安装来源、用途、权限和负责人。
还要小心自动更新。自动更新能修 bug，也可能在你没复核的情况下改变命令行为。对生产相关插件，更新前至少要看变更摘要，在测试仓跑一次固定样例。若插件会处理 AI 自动化办公文档，日志里不能保存完整敏感原文；若插件会调用 AI 模型接口，必须记录模型名、调用来源和费用归属。
检查清单：上线前至少问完这些问题
插件来源是否可信；版本是否固定；manifest 是否可读；是否需要网络访问；是否读取密钥；是否执行 shell；是否写入项目文件；是否有日志和缓存；是否能在测试仓复现；是否有禁用和回滚步骤；负责人是否明确；团队成员是否知道它的适用范围。
这份清单不需要变成复杂流程，但要写在插件安装说明里。对个人使用的轻量插件，可以简化为来源、权限、试跑、回滚四项；对团队共享插件，最好再加上审计记录和版本锁定。
FAQ：第三方插件一定不能用吗？
不是。第三方插件可以提升效率，关键是先把风险显性化。对只读文档整理、模板生成、代码片段辅助这类低风险场景，可以在隔离环境里试用。对生产发布、数据库、支付、客户资料和密钥管理场景，要更谨慎，必要时只使用内部审过的插件或把权限拆到更小。
插件安装后还要做一次巡检：确认它没有新增未知启动项，没有把日志写到公开目录，没有把配置文件改成全局可写。团队共享环境最好保留安装前后的配置快照，回滚时能快速知道要删哪些文件、恢复哪些权限。