「危险跳过权限」这个名字背后的诱惑

在YouTube上搜索Claude Code教程，会发现不少视频使用了 --dangerously-skip-permissions 这个标志。加上这个标志后，Claude会自动执行文件修改、命令运行、软件包安装等所有操作，无需任何审批。画面看起来很干净，工作一气呵成，中间不会断。

但这个标志的名字里带着「dangerously（危险地）」这个词。这不是随便起的。它意味着Claude可能误删重要文件、执行意料之外的系统命令、在没有人确认的情况下对生产服务器造成影响。

想快点把活干完，这心情谁都懂。但在速度和安全之间，有更聪明的平衡办法。

四级自主性模型

Claude Code的权限设置分为四个等级，每个等级代表赋予智能体的自主程度。

第一级：Plan（规划）

限制程度最高的模式。Claude可以读取和分析文件，但不做任何修改。不写代码，不执行命令。只负责制定计划并汇报。

适合用来了解新项目的结构，或者讨论复杂问题的解决思路。

第二级：Ask Before（事前审批）

Claude可以执行操作，但每一步都需要用户批准。「可以修改这个文件吗？」「可以运行这条命令吗？」逐一询问。

安全，但慢。用户必须一直坐在屏幕前点批准按钮。在重要系统上进行敏感操作时，选这个模式。

第三级：Auto Edit（自动编辑）

这个等级下，文件编辑自动完成，但系统命令的执行仍然需要审批。代码的编写和修改可以自由进行，而 rm、npm publish、git push 之类的命令，要经过人工确认才能执行。

对大多数日常开发工作来说，这是一个恰到好处的平衡点。

第四级：Bypass（绕过）

所有限制全部解除。相当于 --dangerously-skip-permissions 对应的等级。Claude自动执行一切操作。

这个模式只应在用户坐在屏幕前实时监督时使用。人离开了还让智能体在Bypass模式下运行，是很危险的事。

[图31-1] 四级自主性模型示意图，Plan、Ask Before、Auto Edit、Bypass

用允许列表和拒绝列表做精细控制

需要比四级模型更精确的控制时，可以用允许列表（allow list）和拒绝列表（deny list）。

这不是「全部放行或全部拦截」的二选一，而是「只放行确认安全的命令，明确拦截危险命令」的精细化配置。

允许列表里放 git commit、npm test、npm run build 这类安全命令，拒绝列表里放 rm -rf、git push --force、DROP TABLE 这类破坏性命令。

这里有一条关键规则：拒绝列表的优先级高于允许列表。即使允许列表中包含 rm，只要拒绝列表中也有 rm，就会被拦截。安全机制永远胜出。

这样配置之后，速度几乎和 --dangerously-skip-permissions 一样快，但致命命令被挡在了门外。不牺牲速度就能保住安全，这是最务实的做法。

{ "permissions": { "allow": [ "git commit", "git add", "npm test", "npm run build", "npm run dev" ], "deny": [ "rm -rf", "git push --force", "git reset --hard", "DROP", "DELETE FROM" ] } }

[图31-2] 允许列表与拒绝列表配置示例界面

VPS托管与远程运行Claude Code

合上笔记本电脑，Claude Code的会话就断了。如果需要长时间运行或持续监控，这就成了限制。

把Claude Code装在VPS（Virtual Private Server，虚拟专用服务器）上，问题就解决了。服务器24小时运转，合上笔记本会话也不会中断。通过SSH（Secure Shell）远程连接，随时随地都能接上之前的会话。

如果配好了Telegram联动，还能在手机上给Claude Code下指令。上班路上在地铁里问一句「昨晚跑的验证结果怎么样？」，回复就来了。

Claude Code还有远程控制（remote control）功能。在本机上运行的会话，可以通过浏览器或手机来操控。代码不离开本机，只是控制权交到了远端。在办公室启动一项工作，出去喝咖啡的路上用手机调整方向，完全可以做到。

运行长期会话时，权限设置要格外谨慎。用户不在屏幕前，智能体却在持续运转，Bypass模式就不合适了。应当精心配置允许列表和拒绝列表，必要时让智能体在需要审批的操作前等待，这样才安全。

[图31-3] 在VPS上远程运行Claude Code的架构图

团队环境中的安全

一个人用和团队一起用，安全的层级完全不同。一个人的失误可能波及整个团队。

API密钥管理

在团队项目中，把API密钥直接写进代码里，这件事绝对不能做。一个人硬编码了密钥并提交，那个密钥就永远留在Git历史里了。即使是私有仓库也不安全。

API密钥应当通过环境变量来管理。把密钥存在 .env 文件中，这个文件必须加入 .gitignore。每位团队成员在本机管理自己的 .env 文件，密钥本身通过安全渠道（密码管理器、加密消息等）共享。

settings.local.json的使用

Claude Code的配置文件分两种：适用于整个项目的共享配置，以及只作用于个人环境的本机配置。

settings.local.json 是个人配置文件。里面放的是个人权限设置、环境专属路径、个人MCP连接服务器配置等只和自己环境相关的内容。这个文件不提交到Git。

项目公共配置放在另外的共享配置文件中并提交。所有团队成员在同一套基本规则下工作，个人差异则在 settings.local.json 中处理。

最小权限原则

团队环境下权限设置的基本原则很简洁：只给每个角色所需的最低限度权限。

前端开发者的Claude Code会话没有理由能执行数据库删除命令。非部署负责人的会话也没有理由被允许运行生产环境部署命令。按角色分别配置允许列表和拒绝列表，就能从结构上限制失误造成的影响范围。

[图 31-4] 团队环境中的权限设置结构，共享设置与个人设置的分离

安全不是速度的敌人

花时间做权限设置和安全管理，可能让人觉得麻烦。「直接用 --dangerously-skip-permissions 不行吗？」这种念头很容易冒出来。说实话，个人项目里做个小实验，这样做确实不会出什么大问题。

但项目规模变大、团队成员增加、生产服务器开始介入之后，没有安全设置就往前冲，跟不系安全带上高速公路没什么两样。出事之前只觉得碍事，出了事就什么都晚了。

把允许列表和拒绝列表仔细配置一次，之后的工作速度几乎和旁路模式一样快，同时致命失误会被拦截。前期投入一个小时，换来此后每次会话的安全保障。很难找到比这更划算的时间投资了。

如果你打算认真使用Claude Code，权限设置就不是可选项，而是基本功。工具的力量越强，控制这股力量的体系也必须越强。

具备了技术能力和安全意识之后，还剩下一个阶段：把这些能力转化为实际业务。光会操作Claude Code是不够的。掌握这项技术的人，如何在市场上获得第一个客户、如何定价、如何建立可持续的商业模式，回答这些问题，就是下一段旅程的起点。

人工智能专家 金京镇律师

AI法律政策专家 · 前国会议员 · 著作等身

如果这本书曾在你身边停留片刻，请支持我们，让下一个故事也能与世界见面。

（自愿赞助账户：农协 302-1096-0948-81 户名：金京镇）