本地指令文件诱导编程助手安装恶意包

一份落在 Downloads 文件夹里的 AGENTS.md，试图让 AI 编程助手修改设置，并安装与恶意软件活动有关的 npm 包。安全工具拦下了这次尝试，但研究人员的受控测试显示，类似指令仍可能被编程助手执行。

这件事值得程序员关注的地方，是攻击入口变成了本地说明文件：当助手把读到的文字当成操作授权，原本用于指导开发的机制，也可能被用来安装软件、修改配置。

一份说明文件，怎么变成了安装指令

原文描述的攻击载体是 AGENTS.md。它出现在用户的 Downloads 文件夹中，要求 OpenAI 的 Codex 向自身设置添加一个服务器，并安装名为 function-color 的 npm 包。

攻击链没有停在安装依赖这一步。按原文说法，function-color 会自动下载另一个程序，后者把与 MALFEX 恶意软件活动有关的 Windows 代码带到设备上。原文没有给出具体安装命令、包版本，也没有交代后续代码是否成功执行。

AGENTS.md 这类文件承担的是给编程助手提供工作说明的角色。攻击者利用的正是这个入口：把自己的操作要求写成助手可能遵循的本地指令。

能被助手读取的文件，不应自动获得替用户授权的资格。

这里需要分开看：读到「请安装这个包」，和用户确实要求安装这个包，是两回事。攻击试图把两者连在一起。

Downloads 为什么会成为攻击入口

研究人员认为，这条攻击路径依赖两个条件：助手信任工作目录里的指令文件，以及网站能够把文件自动下载到用户的 Downloads 文件夹。

他们制作了一个测试页面，演示仅访问网页就自动下载该文件的可能性。不过，研究人员没有确认真实事件中的 AGENTS.md 究竟如何进入客户电脑。因此，网页投放是经过演示的可行路径，并非已经查明的事件来源。

危险发生在后续衔接处：文件落地后，用户又在这个目录启动编程助手，助手随即读取并遵循其中的要求。

Downloads 通常混放着浏览器下载的文件，来源复杂。在这里启动助手，可能让外部文件进入助手的指令读取范围。原文没有说明测试所用的浏览器配置，也没有展开各工具如何寻找指令文件，不能据此认定所有环境都会出现同样的结果。

超过 90% 的执行率，究竟说明了什么

原文给出了两组受控测试结果：

• Codex 在超过 90% 的测试中遵循了文件要求，并执行相关命令。
• 针对 Claude Code 的类似测试约有一半成功。该测试试图向项目设置添加一个 Web 服务器地址，目标涉及截取连接密钥；原文将较低的成功率归因于系统需要用户批准这类操作。

这两组数字说明，在研究人员构造的环境里，本地文件中的恶意要求确实可能转化为实际操作。批准请求也可能成为阻断环节。

但原文没有提供样本量、工具版本、权限配置或完整测试流程，也没有说清 Claude Code 测试中的连接密钥类型及截取方式。两组攻击目标也不完全相同，不能拿来直接排名，更不能把超过 90% 当成所有 Codex 使用场景的风险概率。

另外，真实事件中「安全工具拦截了尝试」，与受控测试中「助手执行了命令」描述的是不同环节。助手执行命令，不等于后续恶意软件已经成功运行。

我的判断

这篇报道抓住了一个实在的问题：本地文件也可能是不可信输入。对前端和 Node 开发者来说，安装 npm 包、修改工具配置都是常见动作，恶意要求混在开发说明里，容易显得顺理成章。

但原文援引专家称，这不是 OpenAI 或 Anthropic 需要修复的技术错误，因为工具只是在正常遵循指令。这个判断过于绝对。

功能按设计运行，并不能单独证明设计中的信任边界足够合理。哪些文件可以提供操作指令、哪些设置变更需要确认，仍然是产品可以约束的地方。只是原文材料不足以判断具体实现是否存在缺陷。

保留批准请求有测试结果提供方向性支持；检查陌生指令文件、避免在 Downloads 启动助手，则属于研究人员提出的防护建议。原文没有给出这些措施之间的对照数据，不能替它们承诺防护效果。

能拿来做什么

• 在明确的项目目录中启动 AI 编程助手，避免直接把 Downloads 这类混合来源目录作为工作目录。
• 接手下载或解压得到的项目时，先检查 AGENTS.md 等指令文件，重点看是否要求安装陌生依赖、添加服务器或修改助手设置。
• 保持批准请求开启。遇到 function-color 这类与当前任务无关的安装要求，先核对要求来自用户任务，还是来自助手刚读到的文件。
• 审查助手操作时，把「是否执行了安装命令」和「后续下载了什么、运行了什么」分别确认，避免只看一次执行成功就结束检查。