陌生仓库开 agent，别太顺手

作为一个长期做资产配置、也看过不少技术风险案例的人，我试了一下“把陌生 Git 仓库丢给 AI coding agent 做项目理解”这件事。结论：不建议小白这么干。AI coding agent 是能在电脑里读代码、跑命令的助手；Git 仓库是代码版本文件夹。个人学习、机器没密钥，可以试；一旦有云凭证、登录密钥，风险收益比很差。我管家族办公室的钱，从资产配置角度看，这类工具不能只买效率，也要买隔离。

我这几天在试几个 agent 类工具，因为 LLM 刚上手，不敢直接连真实仓库。我在终端建空目录，手动 git init，复制 README 和几个小文件，假装是外部仓库。界面只显示 agent 正在读取项目结构。我以为危险点在我输入“帮我总结”之后，结果报告说，这类被叫作 GitSpawn 的问题在于，agent 会在后台运行 git 命令收集上下文，有时在 prompt、workspace-trust 弹窗之前就会跑。

恶意 .git config 可能让 agent 在信任或审批机制生效前执行攻击者控制的命令。

卡点是“看不见”。workspace-trust 弹窗是工具问你是否信任目录，但 git 配置里哪些 hook、别名、fsmonitor 会被触发，不能只靠弹窗判断。惊喜是：放进隔离环境后，agent 仍能给出文件树和修改计划，效率价值是真的。但它给不了我“安全边界生效”的证据。

我把权限降下来，不让它写文件，不让它执行任意命令，也不放云凭证。这样它只能摘要和计划，不能自动修代码。对成熟团队，“先只读、再审批、再执行”比单靠弹窗靠谱。报告提到 Claude Code、Goose、Qwen Code、Grok Build、Hermes 状态不一致，有的修了核心路径，有的还没补，说明不能把默认设置当安全保证。

从投资视角看，壁垒不在会不会写代码，而在能不能把不可信输入变成可验证流程：隔离、最小权限、人工审批、可回滚日志。谁能低摩擦做成这些，谁才有长期价值。普通用户先别急着让 agent 跑，先让它“看”，别让它“动”。

你拿到一个看起来很正常的仓库，会不会因为“别人都在用”而少点一次信任确认？

---

📌 本文编译自 Hacker News，原文：https://www.manifold.security/blog/ai-coding-agents-git-hijack

版权归原作者所有，本文为基于公开报道的编译与独立分析。