OpenAI Codex 仓库里，有条看起来很小的功能请求：给 Codex 加一个 .codexignore。

小到像工程洁癖。实际卡住的是 AI 编程代理最硬的一道门槛：它越会读项目、搜文件、改代码，越必须证明有些东西它绝对不能碰。

这条 Issue #2847 于 2025 年 8 月 28 日打开。当前仍是 open 状态，标签是 enhancement 和 sandbox，没有分配负责人，也没有关联 PR。材料只显示用户提出防护需求，不代表已经发生敏感文件泄露，也不能据此断言 Codex 会上传所有文件。

Issue #2847 要的不是提醒，而是两层禁区

用户要的功能很明确：让 Codex 支持仓库级 .codexignore，再支持一个全局 ignore 文件。

前者给团队用。规则写进项目，大家共享。

后者给个人用。跨项目生效，给每个开发者留一层默认防线。

机制请求内容解决什么问题
仓库级repo-local .codexignore团队共享规则，避免每个人各管各的
全局级global ignore file个人默认规则，跨项目保护敏感路径
示例路径.env、.env.、.pem、id_*、.aws/、.ssh/凭据、私钥、云账号配置、SSH 相关文件
当前状态open、无 assignee、无 PR仍停在功能请求阶段

这个请求还有一个细节很关键：用户并不是要求 Codex 少读所有东西。

比如 node_modules/，有时保留搜索能力反而有用。开发者可能希望代理查实现细节、定位依赖行为。

但 .env、私钥、SSH 配置、AWS 配置不一样。这些文件不该进入模型上下文，也不该被代理随手读取。用户要的是确定性禁止，而不是一句“请注意安全”。

相关旧 issue #205 曾讨论过类似方向：防止敏感数据发给模型，也排除大文件或无关文件。后来它因 Rust 版 codex-rs 的实现方向而关闭。

按这次请求者的说法，截至 2025 年 8 月 28 日，codex-rs 中似乎仍没有对等可用的 ignore 功能。这个说法来自社区用户观察，不是官方结论。但它至少说明，需求没有消失。

真正受影响的是两类人：开发者和工具链负责人

这件事最先影响使用 Codex 或类似 AI agent 处理真实项目代码的开发者。

个人项目里，.env 可能只是测试 token。企业项目里，它可能连着数据库、云资源、内部 API、第三方服务。代理一旦能遍历工程，敏感文件就不能只靠开发者临场记忆来挡。

开发者现在能做的动作很现实：

  • 不把真实密钥留在工作目录里；
  • 用脱敏副本或最小化项目上下文跑代理；
  • 对 agent 的文件访问范围做额外限制；
  • 在工具没有硬边界前，避免让它直接碰生产仓库。

这不是保守。是基本卫生。

另一类人是负责代码安全、开发工具采购和内部平台治理的团队。

他们不会只问“模型写代码准不准”。他们会问更麻烦的问题：哪些路径永远不能被读取？规则能不能随仓库下发？个人能不能加默认策略？触发拦截有没有日志？规则冲突谁优先？

如果这些问题答不上来，采购会延后，试点会缩小，落地范围会被限制在 demo 仓库、沙盒仓库或低风险项目。不是大家不想用 AI，而是不敢让一个边界不清的代理进主干流程。

这里要承认一个现实约束：从这条 issue 本身，看不出 Codex 当前所有文件访问机制，也看不出 OpenAI 的完整安全设计。不能把 open 状态解读成官方拒绝，更不能写成安全事故。

但 issue 的价值正在这里。它把一个抽象问题拆成了工程问题：不要空谈“信任 AI”，请给出可配置、可审计、可验证的禁区。

信任门槛不在模型智商，在权限边界

我不太买账的一点是，把这类功能放进“体验增强”里。

它不是体验增强。它是基础设施。

Git 有 .gitignore。Docker 有 .dockerignore。npm 发布也有 files 白名单或 ignore 规则。它们表面是在排除文件，底层是在划边界：哪些东西能进协作链路，哪些东西永远不要进入那条管道。

AI 编程代理现在也走到同一个路口。

不完全一样的是，Git 忽略的是版本控制，Docker 忽略的是镜像上下文。AI agent 面对的是模型上下文和工具执行空间。它不是一次性打包，而是在对话中动态读、搜、判断、行动。

边界一软，用户甚至不知道哪一步越界。

“天下熙熙，皆为利来。”这句话放在 AI 编程工具上很合适。产品天然想看更多上下文，因为看得越多，回答越准；权限越大，自动化越强；接入越深，用户越难离开。

这个方向本身没错。问题是，商业激励会把代理推向更大的可见性、更强的操作权。对应的刹车，也必须做成产品能力。

不是隐私政策里的一段话。不是文档里的安全建议。也不是让开发者每次启动前默念“别把 .env 发出去”。

真正有用的是几件硬东西：

需要观察的变量为什么重要
是否支持 repo-local ignore团队能不能把规则写进仓库治理
是否支持 global ignore个人能不能跨项目保留默认防线
规则优先级是否清楚冲突时不能靠猜
拦截是否可见、可审计安全团队需要证据，不只要承诺
是否有明确失败提示被挡住时要让用户知道原因

接下来真正该看的，不是这条 issue 什么时候被回复一句“thanks”。

该看的是 OpenAI 是否把这类 ignore 机制做成一等能力：默认可用、规则清楚、触发可见、和 sandbox 权限体系打通。只做半截，就还是软边界。

模型更聪明当然重要。但真实工程里，信任门槛经常不在智商，而在权限。

一个能力有限但边界可验证的工具，企业还能慢慢放权。一个边界模糊的聪明代理，只会让安全团队把门关得更紧。

这条 issue 仍只是一个 open 的功能请求。OpenAI 最后怎么设计、何时处理、会不会合并，目前都看不出来。

但问题已经摆在桌面上：AI 编程代理要进入真实项目，就不能只证明“我能帮你改多少代码”。它还得证明：我不该看的东西，你凭什么相信我真的没看。