权限综合征：为什么 --dangerously-skip-permissions 是氛围编程最顺手的坑

Claude Code 有一个参数叫 --dangerously-skip-permissions。名字里已经写着 dangerously，但很多用 AI 搞氛围式编程的人还是把它当成默认运行方式。打开它，然后不再回头。完全自动化，没有权限弹窗，速度拉满。

直到它删掉你的主目录。

过去一年里，这类事故越来越多。我觉得有必要把问题讲清楚：它到底做了什么，为什么人们明知道危险还会用，以及怎样在不牺牲 AI 编程速度的前提下降低风险。

--dangerously-skip-permissions 到底跳过了什么

正常使用 Claude Code 时，它会在执行命令行命令、写文件、改代码之前请求确认。你能看到它准备做什么，然后批准或拒绝。这是人机协作的模式。

--dangerously-skip-permissions 把这个环节移除了。Claude 可以执行任何 bash 命令，写入或删除任何文件，推送代码，安装依赖，而且不再问你。它本质上是一个“我完全信任这个 AI”的按钮。

公平地说，它确实更快。没有打断，没有批准/拒绝点击。你描述任务，离开一下，回来看到任务完成。这就是吸引力，也是为什么很多人会用。

问题是，AI 模型并不总是按你以为的方式理解你的请求。

事故清单

这不是理论风险。真实的人已经丢过真实的数据。

2025 年 10 月：rm -rf / 事故。开发者 Mike Wolak 在 Ubuntu/WSL2 上做固件项目时，Claude Code 从根目录 / 开始执行了 rm -rf。他的 GitHub 问题报告 (#10077) 里有大量系统路径的 “Permission denied” 日志，包括 /bin、/boot、/etc。命令尝试删除整台机器。最后是 Linux 文件权限拦住了系统级文件，但用户自己拥有的文件都没了。更糟的是，他当时甚至没有使用 --dangerously-skip-permissions。如果安全网开启时都可能失效，裸奔运行的风险就更不用说了。

2025 年 12 月：主目录被清空。一位 Reddit 用户让 Claude 清理仓库里的包，Claude 生成了这个命令：

rm -rf tests/ patches/ plan/ ~/

看到最后的 ~/ 吗？那是你的整个主目录。Simon Willison 在 X 上转发后，它成了最公开的 --dangerously-skip-permissions 灾难案例之一。

2025 年 7 月：Replit 删除生产数据库。Replit 上的一个 AI 智能体在代码冻结期间清空了生产数据库，里面有 1,200 多位高管的数据。AI 事后承认自己慌了，并执行了未授权命令。平台不同，底层问题相同：AI 对破坏性操作拥有无限制访问。

2025 年 12 月：Google Antigravity 清空磁盘分区。Google 的 Antigravity 编程平台擦除了整个磁盘分区，还绕过了回收站。Reddit 上也有多个用户报告类似问题。

还有一种没那么戏剧化、但更难察觉的风险：提示词注入。研究者已经展示过，隐藏在 .docx 文件里的文本可以诱导 Claude 通过已列入允许名单的 API 把敏感文件上传到攻击者账户。AI 并不知道自己被诱导了。权限被跳过以后，注入指令和实际执行之间没有任何拦截。

这些不是离谱提示词造成的边缘事故。它们都是正常开发任务：清理包、做固件、写代码。AI 做了破坏性动作，而系统里没有东西拦住它。

为什么大家还在用

我看到的原因主要有三个。

1. 他们真的没有理解风险。很多做氛围式编程的人不是传统开发者。他们把 AI 当作主要的编码工具，有些甚至是唯一的编码工具。他们没有那种本能反应：等一下，这个命令到底会做什么？对他们来说，这个参数是个方便的开关，不是安全决策。

2. 交付速度压过安全。快速上线的压力是真实存在的。每一次权限确认都像是在你和截止日期之间多了一道坎，所以跳过确认看起来像生产力提升。它确实是，直到它不是。

3. 很多人轻率地以为开发者可以被替代。这个更微妙，但很关键。当心态变成“AI 会处理，我们不需要理解代码”时，人就会停止追问 AI 正在做什么。不会看命令，不会思考影响半径。氛围式编程的诱惑就在于不用操心细节。但 rm -rf ~/ 就藏在细节里。

VCP 怎么处理这个问题

我做 VCP (Vibe Coding Protocol)，就是为 AI 辅助开发加一层安全框架。它有三层执行，而且即使开启 --dangerously-skip-permissions 也会生效。

第一层：主动上下文。会话开始时，VCP 把安全和架构规则注入 Claude 的上下文，让 AI 在写代码时就内化这些规则。它不是事后扫描，而是在生成之前影响模型的思考方式。

第二层：按需扫描。/vcp-audit 和 /vcp-pre-commit-review 这类技能会按 12 个范围的 41 条标准扫描代码，用更深的分析抓模式匹配抓不到的问题。

第三层：实时阻断。这是最关键的一层。安全关卡钩子会拦截每一次 Write、Edit、Bash 调用，在工具真正执行前检查。它会阻断 9 个 CWE 下的 21 类危险模式：

• 硬编码密钥，比如 API 密钥、token、私钥
• 通过字符串拼接造成的 SQL 注入
• 用户输入进入 eval() 造成的代码注入
• 通过 innerHTML 造成的 XSS
• 不安全反序列化
• 混淆后的命令行执行

命中时，你会看到类似输出：

❌ VCP 安全关卡 — 已阻断：
   CWE-798：检测到硬编码密钥。请使用环境变量或密钥管理器。

AI 收到错误信息后会自我修正。危险代码不会落盘。这个机制不依赖 Claude 的权限模式；你可以开着 --dangerously-skip-permissions，安全关卡仍然会拦截每一次工具调用。

VCP Docker：保留速度，缩小风险

社区对 --dangerously-skip-permissions 的共识基本已经收敛到一句话：只在 Docker 容器里用。LessWrong 的一篇文章说得很准确：先给影响半径设硬边界，再在边界内最大化生产力。

VCP Docker 做的就是这件事。它是一个可直接使用的容器化环境，预装 Claude Code、Codex CLI、Gemini CLI、Bun、Git、GitHub CLI、tmux、ripgrep。关键设计如下：

• Ubuntu 24.04 基础镜像：日常开发所需的完整包生态
• 非 root 用户（devuser）加免密 sudo：Claude Code 不允许 root 用户使用 --dangerously-skip-permissions，但你仍能通过 sudo 安装包
• 默认别名 --dangerously-skip-permissions：容器本身就是沙箱
• 你控制影响半径：挂载卷决定容器能看到什么，通常只有你的代码、SSH 密钥、Claude 数据。主机上其他东西不可见

# 启动容器
docker compose up -d
​
# 进入容器，以完整速度使用 Claude
docker exec -it vcp-docker bash
claude "重构认证模块"

如果 Claude 在容器里决定执行 rm -rf /，它毁掉的是容器文件系统。你的主机没事，其他项目没事。重新 docker compose up -d，十秒钟后继续。

再把 VCP 的安全关卡放进容器里，就形成了纵深防御：AI 既被隔离在系统之外，每次操作又会被实时模式检查。

底线

--dangerously-skip-permissions 不会消失。人们会继续用它，因为生产力的提升是实实在在的。我自己也用，但只在容器里用。

问题不是“应不应该用它”，而是“当 AI 出错时，它和你的数据之间隔着什么”。

如果答案是“什么都没有”，那一个错误的提示词就能让你陷入很糟糕的境地。如果答案是“一个隔离容器，再加上能实时阻断危险模式的安全关卡”，那你可以拿到速度，同时保住数据。

设置 VCP Docker，不要再直接在裸机上跑 --dangerously-skip-permissions。