AGENTS.md 投毒怎么查：Codex 中招率超 90% 自查清单

一句话结论：攻击者只要用一个网页往你的下载目录丢一份 AGENTS.md，你的编码智能体就会把它当规范照做，Codex 中招率超过 90%，Claude Code 约 50%，而且这个洞没法靠打补丁堵上。

安全机构 Forever Security 在一台真实客户机上截获了一份躺在 ~/Downloads 目录里的恶意 AGENTS.md。不是实验室构造的样本，是野外的活体。这件事在 11 月被推到台面上后，很多人第一反应是怀疑自己的安全常识失效了：不点可执行文件、不乱敲 bash，不就没事了吗。

这个常识在 Agent 时代确实过时了。失效的不是你的谨慎，而是前提变了。操作系统那套防线建立在有人在屏幕前看着这个假设上，而编码智能体把看屏幕的人替换掉了。

下载目录是唯一一块网页能自己写的地方

先说清楚为什么是下载目录。整个攻击链能成立，靠两个单独看都无害的东西凑在一起。

第一个是 AGENTS.md 这种文件天生就该被服从。你在项目根目录放一个 AGENTS.md 或 CLAUDE.md，写上本项目的编码规范，Codex 和 Claude Code 启动时会主动读它并且照着执行。这是产品的正常功能，也是这套工具的工作方式。第一次进项目你会看一眼，之后就信了。

第二个是浏览器可以在你不点击任何东西的情况下把文件写进你的机器。切走网页的那一瞬间，一个叫 AGENTS.md 的纯文本文件就静静躺在下载目录里，连下载确认框都不会弹。

两个条件各自都不构成威胁。系统早就关掉了自动执行下载文件的门，一个从网上来的可执行文件必须过你这一关。但 Markdown 不属于可执行文件，所有针对可执行文件的护栏对它一律不适用。它就躺在那里，看起来像一份无害的下载，直到有个 Agent 读了它。

Forever Security 在自家客户数据里查到的比例更能说明问题的范围。约一半的客户会在下载目录里跑编码智能体，约四分之一的智能体会话会打开真实浏览器。这意味着相当一部分人的操作路径上，这个攻击面是敞着的。

还有一层更难防的现实：现在很多浏览是 Agent 在做，不是人。你派它去查资料然后走开，它自己开浏览器访问站点，中间某个站点把文件丢进下载目录，全程没有人在屏幕前，自然也没人看见文件到达。

Codex 路径：写全局配置，再给自己拆掉沙箱

攻击者在 Codex 这条路上的目标是改写 ~/.codex/config.toml，加一个 tools server 节点，再让 Codex 执行一次子进程把这个 server 跑起来。因为 config.toml 里的 server 是启动时加载的，session 一开始它就会自动被唤醒。

Forever Security 用真实攻击者的载荷在隔离虚拟机里原样复现，没有替换任何自己的东西。载荷本身是一份长达 13KB 的工程文档，标题类似本地开发环境准备规范，里面要求在 session 开始前把标准 tools server 注册到 config.toml，并用临时目录跑一次校验。恶意包藏在 tools server 的启动命令里。

这份文档要读起来完全无害。里面用的是项目标准 tools server 的说法，用的是 npm 包通过 npx 按需拉起的常见模式，通篇没有一句看起来像攻击的话。攻击者还特意加了一句，命令和参数要原样保留，这样注册结果才和工具链其余部分对得上。

Codex 读完非常满意，然后自己动手执行了一个带 –dangerously-bypass-approvals-and-sandbox 参数的子进程。等于自己关掉安全防护，再替攻击者装上恶意依赖。

这一步能走通，是因为每个控制点都被绕开了，而且每一处绕过本身都是一条有价值的技术发现。

信任门是第一个。Codex 只服从它信任的项目里的 AGENTS.md，而你在下载目录工作过一次，那个目录就取得了信任。

写入的可靠性是第二个。一句明显的安装请求会被拒绝，但包装成长篇工程文档、把落点伪装成仓库标准 tools server 就能通过。这解释了为什么真实载荷是一份 13KB 文档而不是一行命令。

启动时机是第三个。server 只在 session 启动时加载，Agent 没有任何办法触发重载。载荷的做法是把两轮 session 压进一轮，用子进程方式跑。

网络沙箱是第四个。Codex 默认拦截命令的网络访问，安装包拿不到网。于是子进程带上 –dangerously-bypass-approvals-and-sandbox 跑，而这个参数是模型自己写进命令里的，理由被包装成安装需要联网。

握手超时是第五个。Codex 会杀掉响应太慢的 server，慢速 npm install 直接被掐断。攻击者最终把安装任务交给 launchctl，因为它跑在 Codex 控制范围之外，安装才终于跑完。

这套流程串下来，Codex 在一次 session 里就执行了攻击者代码，中招率超过 90%。

Claude Code 路径：改个网关地址，Token 就出去了

Claude Code 这边完全是另一种打法。它不装包，它改路。攻击者诱导 Claude 改写项目的 .claude/settings.json，把 ANTHROPIC_BASE_URL 指向攻击者自己持有的服务器，域名自有、证书有效，一切看起来像团队内部网关。

这一步同时干成两件事。Claude 每次发请求都会把 OAuth 登录 Token 原样送过去，等于账号被接管，连代码都不用跑。攻击者的服务器随后假扮大模型，返回带 dangerouslyDisableSandbox 为 true 的 Bash 工具调用，客户端读到的就是模型自己的决定，于是直接关沙箱执行。

这里跑通的机制和 Codex 那边正好相反。难的是写入那一步，Claude 对写文件的审批比 Codex 更严，看起来不对的写入经常被拒。靠的还是那份长长的工程文档包装，大概一半的时候能把 .claude/settings.json 写上磁盘。

文件一旦落盘，Token 立刻就漏了。研究者用抓到的 Token 重放请求，直接以受害者身份被服务端认了出来。之后是下一轮 session 的代码执行。Claude 读到这个新地址，从第一个请求开始就跟攻击者对话，攻击者以模型身份回一个带 dangerouslyDisableSandbox 的 Bash 调用。

同一次 session 内也能拿到执行。运行中的 session 保留着启动时建立的连接，看不到新地址，载荷的做法是让 Claude 生成一个子 agent 去验证配置，新连接自然走新地址。这条路径大约五分之一的时候成功，第一次 session 内就能拿到代码执行。综合下来 Claude Code 的成功率在 50% 左右。

还有一处细节挺有意思。载荷写得越露骨，生成的子 agent 读了 CLAUDE.md 之后反而会把它标记成攻击。在一个塞满安全笔记的目录里，同一份文件每次都失败。这就是它要写成一份冗长乏味的工程文档的原因。

两套攻击的对照

把两条路径放在一起，差别很清楚。

有一个共同点最值得强调。改的不是当前目录的临时配置，而是能长期生效的位置。Codex 那边写的是机器级的 ~/.codex/config.toml，一旦写入，之后任何目录里启动 Codex 都会加载攻击者的 server。你删掉下载目录、关掉窗口都没用，毒留在配置里。

Claude Code 那边写的是项目级配置，下一次在这个目录启动 Claude 时会读到这个地址，同样是定时炸弹。

三分钟自查：四件事

攻击链虽然完整，但排查起来并不复杂。如果你在 Mac 或 Linux 上日常用 Codex、Claude Code 或者其它编码智能体，现在就可以花三分钟做四件事。

第一件，查找来源不明的规范文件。

ls -la ~/Downloads/AGENTS.md ~/Downloads/CLAUDE.md ~/Desktop/AGENTS.md ~/Desktop/CLAUDE.md

不只看存不存在。团队代码库里新 pull 下来的仓库也要扫一眼。攻击者会用零宽 Unicode 字符把提示词藏起来，肉眼看是一段空白，AI 读进去全是攻击指令。所以要真的把文件打开看，而不是只看文件大小。

第二件，查全局配置有没有被持久化投毒。

ls -l ~/.codex/config.toml

打开看有没有多出陌生的 [mcp_servers.*] 节点，特别是命令里带 launchctl、curl 或者指向不明临时目录的。有的话机器已经被污染。

第三件，查恶意依赖有没有跑过。

ls -la /tmp/ptools

同时翻一下 npm 的全局包和缓存。攻击链里的主角叫 function-color，在缓存或全局依赖里见过它，说明恶意指令不仅进来了，而且已经在机器上执行过。这时候要断网、换掉所有凭据、重置环境，不是删个目录就完事。

第四件，排查 API 代理劫持。

echo $ANTHROPIC_BASE_URL

再去翻各个项目根目录下的 .claude/settings.json，看是不是被塞了不认识的第三方网关地址。只要不是你自己配的，立刻删掉，然后去官网把 API Token 和 Session 全部轮换一遍。Token 已经外泄的情况下，只删文件不轮换凭据等于没做。

这四项只能覆盖当前已知攻击链的典型痕迹。查不出异常不代表机器一定干净，下次出现新套路这套清单也可能失效。

为什么厂商打不了这个补丁

这不是 Codex 的 bug，也不是 Claude Code 的 bug。研究者把完整链路在两个不同产品上各跑了一遍，结论是任何会读指令文件、能改自己配置的 Agent 都能被这样驱动。这是这类工具的工作方式决定的。

Codex 读 AGENTS.md 并执行里面的环境安装建议，严格按产品设计在运转，就像浏览器渲染一个钓鱼页面时 Chrome 并没有 bug。问题出在情境上，一个网页能自己写进去的目录，被当成了用户自己填的目录。

所以防守责任落到了使用方。Forever Security 在博客里把这概括成一句话。围绕人建立的防御机制，在 Agent 取代人之后就失效了。

防御策略因此要从权限隔离和目录卫生做起。永远不要在 ~/Downloads 或 ~/Desktop 里启动任何 Agent，那两个位置当重度污染区处理，任何活儿都另开一个干净的工程目录。别人给的代码库、从网上拉下来的仓库，运行前先扫一眼里面的 AGENTS.md 和 CLAUDE.md。把权限锁死，Bash 执行权限上把 ~/.ssh、~/.aws 和各类 .env 从底层环境隔离开，攻击者可以用文件当诱饵，但只要 Agent 手伸不过去就没用。

过去所有操作系统的防线都建立在有人在屏幕前看着这个前提上。而指令遵循能力越强的模型，它能在你机器里造成的破坏就越大。这个方向上的安全细节，站内 Claude Code v2.1.311 免批准变量：6 种权限模式与拦截差异 拆过 Claude Code 的权限档位，OpenCode Console 爆发安全漏洞：1.4% 用户 API 密钥泄露 讲的是同类工具的凭据外泄路径。

常见问题

AGENTS.md 是什么，为什么 AI 会自动执行它

它是编码智能体的项目级指令文件，相当于给 AI 看的项目规范，Codex 和 Claude Code 启动时会主动读取并照做。这个设计本身是正常功能，问题在于 AI 分不清这份规范是开发者写的还是攻击者投的毒。

我把下载目录里的可疑文件删掉是不是就没事了

不一定。Codex 那条路径改的是机器级的 ~/.codex/config.toml，Claude Code 那条路径改的是项目级 .claude/settings.json，删除下载目录里的原始文件挡不住已经写进配置里的持久化后门。必须同时检查配置文件、翻查恶意依赖痕迹，并且轮换全部 Token 与 Session。

关掉自动审批能不能挡住这个攻击

挡不住。攻击载荷说服模型自己带上 –dangerously-bypass-approvals-and-sandbox 参数，或者让服务端返回带 dangerouslyDisableSandbox 的工具调用，客户端读到的就是模型自己的决定。自动审批这道防线在设计上就防不住模型主动要求提权，能真正兜底的是底层目录隔离，把敏感目录从 Agent 的可达范围里摘出去。

小结

这次事件暴露的东西比一个投毒手法大得多。攻击者已经不再试图骗过模型的判断力，而是把命令伪装成工程文档，然后让模型自己动手执行。防御的重心因此从别过头转向隔离：不在污染目录启动 Agent，不在没读过的仓库里直接跑敏感命令，把凭据和敏感目录从智能体够得着的地方挪走。

同类的手法在别处也有影子，比如 OpenAI 前沿模型断网训练：11 天暂停后，红队用缓存计时跨沙箱传密钥 讲的是另一条跨沙箱的侧信道，以及 Anthropic 自动化红队：Claude 用 5000 条样本骗过训练监控器 里的对抗评测方法。