夜雨聆风7 月 14 日，AsyncAPI 的四个核心 npm 包被塞进了木马，四个小时里被下载了 225 万次。这本来只是条供应链新闻，直到同一周，GitHub Copilot、Claude Code、OpenAI Codex 不约而同把发布重点从「更聪明」挪到了「上锁」。把这两件事串起来的，正是你让 coding agent 自动跑的那句 npm install。
过去一年，coding agent 的卖点一直是「更自主」：规划、编辑、运行、装依赖，最好一条指令全包。厂商比的是谁的 agent 更敢干、更会自己拿主意。本质上看，这条「越自主越好」的路线，恰恰是后面那场事故的温床——你给的权限越大，攻击面也越大。
AsyncAPI 这记攻击，把这层「自主」的底撕开了一道口子。攻击者没去硬撞 npm 的城门，而是往上游走了一步：利用 AsyncAPI 仓库一处配错的 GitHub Actions 工作流，偷到发布机器人的令牌，借着合法的 OIDC 发布流水线，打出了带有效数字签名的木马包。最阴的是，恶意代码不在安装脚本里，而是 import 时才执行。你就算加上 --ignore-scripts，照样中招。接着它从 IPFS 拉一个 sync.js 落地，化身远控木马，专门偷浏览器密码、SSH key、npm 和 GitHub token，还有云凭证。
为什么这事跟 coding agent 扯上关系？因为 AsyncAPI 正是「替你生成代码、装依赖」这类工具链的底层依赖。一个会自己 npm install 的 agent，只要在 7 月 14 日那个曝光窗口里跑上一回，就等于亲手把木马拉进你的工作站或 CI 流水线。攻击者要的从来不是你本人点错，而是你授权的那套自动化。
一周之内，三家的反应出奇地同步：
| 厂商 | 上的锁 | 关键动作 |
|---|---|---|
| GitHub Copilot CLI | 计划锁 + 沙箱 | plan 模式只规划不写文件；--deny-tool 优先级高于 --allow-tool；本地 /sandbox、云端 --cloud 沙箱 |
| Claude Code | hook 成地板 | 2.1.211 让 PreToolUse 钩子的「询问」变成 auto 模式也越不过的底线；同时中和权限预览里的零宽、双向覆盖、仿冒引号字符，堵住「你看到的批准文案被工具输入改写」的骗局 |
| OpenAI Codex | 命令检测 | 0.144.5 强化危险命令检测（据官方更新日志） |
本质上，这三道锁看着是在修 bug，其实是信任模型的一次转向。过去行业的潜台词是「信 agent 声称它改对了」，如今变成「在运行时封死它做错的可能」。Copilot 用 plan 模式把写文件挡在运行之前，Claude Code 让安全钩子成了不可逾越的地板，Codex 在命令落地前先过一道危险检测。路子不同，方向一致：别再赌模型「想对」，而是假设它会错，从机制上兜底。
有意思的是，大厂集体上锁的另一面，是开源把控制权还给了你。同日 github 选题里的 EasyCode、mlx-tune、unsloth-buddy 这批自托管 coding 工具，走的就是另一条路：运行时不在别人的云里，而在你自己的机器上，规则你审、边界你定。代价是，安全责任从厂商肩上挪回了你自己的审计流程——这未必更安全，但至少「出事你能查得到」。（同期 Claude Code 遥测回传的争议报道，本文未独立核实，仅作背景提及。）
所以这件事对选型意味着什么？判断很直接：如果你让 coding agent 碰客户数据、自动装依赖，那 runtime safety 已不是锦上添花，而是硬约束。工具安不安全，优先级头一回压过了功能强不强。对做 MES、LIMS 这类涉客户数据的系统，这点尤其实在。
你现在的 agent，敢让它自己 npm install 吗？还是每次都卡在人工确认那一步？你踩过最悬的那次，是依赖装错了，还是权限放太大了？
