陌生仓库别直接让 Agent 跑 setup

一个仓库看起来干净，不等于适合直接交给 coding agent 跑 setup。真正危险的时刻往往不是第一条命令，而是 setup 失败后，agent 按错误提示继续“自动修复”。

先只读审查

先让 agent 只总结 setup 文件、package scripts、install hooks、shell scripts、CI 文件和文档里的命令，不要执行。第一轮是源码审查，不是 bootstrap。

审失败后的路径

错误信息、init 命令、helper scripts 和 package lifecycle hooks 都可能变成 agent 的下一步指令。要看 setup 失败后它会跑什么，以及这条路径会不会在运行时拉取配置或代码。

• 错误提示建议跑哪条命令？
• 这条命令会调用哪些脚本或 package hooks？
• 运行时拉取的内容能不能不经过 Git commit 就变化？

Shell 和网络要窄批准

陌生仓库先用 read-only / plan-style 探索。不要在容器或 VM 之外用 broad permission bypass；package manager、shell wrapper、网络 fetch、可能碰凭证的命令都要单独批准。

第一次放进隔离环境

第一次 bootstrap 用一次性 container、VM、sandbox 或 throwaway worktree，不带生产凭证、不带真实浏览器 profile、不转发 SSH agent、不挂载 home directory。留下 transcript、diff、package scripts 和网络目标。

证据足够无聊再推广

团队复用前，setup 路径应该足够无聊：命令固定、网络调用清楚、脚本已审、回滚方式明确。如果 agent 是靠没人审过的“修复命令”跑通的，继续隔离。