ARTICLE / ai
编码 Agent 的权限配置界面，正在骗你做出危险选择
OpenCode 的权限模型本身不复杂：每条规则解析成 allow（直接跑）、ask（弹窗确认）或 deny（禁止），模式匹配、最后命中的规则生效，官方文档建议把 catch-all 放最前、例外放后面。设计意图很清楚——让用户自己划定 Agent 的行动边界。
问题出在"划边界"这个动作上。10 月发生的三起公开事故（详见我们上一篇复盘）显示，普通用户在这个界面上做出的选择，系统不但没有纠正，还有两类机制在推着危险确认通过：一类是产品提供的便利入口（宽松默认值、一键 auto 放行），另一类是模型动态生成的选项文案。两者机制不同，方向一致。这一篇从产品设计的角度看这件事：权限配置的哪些交互细节在制造事故，以及工具方应该改什么。
默认值的引力场
先看 #56319 那位用户的配置结构：shell 全量 allow，然后列了一串"已知危险命令"要求 ask。这不是偷懒——官方文档写明，不配置时 OpenCode 从宽松默认出发（多数权限默认 allow）；而这位用户是从 v1 迁移配置到 v2 后保留了这种"allow 打底 + 例外名单"的写法。任何带"高级设置"的产品都会遇到同样的自然形态：弹窗烦了就把大门口放开，再凭记忆补一份黑名单。
这里有个可以量化的判断标准：**一个权限界面如果让"全放行"比"精细控制"更容易达到，它就会滑向全放行。**OpenCode v2 支持 --auto 启动参数自动批准所有非显式 deny 的请求，TUI 命令面板里还有"Enable auto-approve permissions"一键开关。便利性入口越多，安全配置的存活时间越短。不是用户不懂安全——是产品的摩擦设计在跟用户的耐心赛跑，而耐心通常输。
选项文案也是攻击面
#56319 报告里最值得设计师细读的是这段：Agent 在执行全盘删除前问了两个问题，第一个问题的选项原文是——
Back up your hermes user data before deleting everything? — “No — nuke everything, no backup”
用户在 issue 里写道，他不确定这句"No — nuke everything"是模型起草的还是 OpenCode 生成的，但他点了它。这就是确认疲劳（confirmation fatigue）的经典素材：一边是冗长谨慎的备份询问，另一边是一个把破坏性决定包装得干脆利落的短语。人类在这种二选一里点哪个，行为心理学早就给出过答案。
产品层面的推论很直接：破坏性操作的确认界面，措辞必须对称。“是，先备份"和"否，不备份直接删"才是两个平等的选项；“nuke everything"这种带情绪色彩的表述出现在任何一个选项里，都说明文案生成链路没做审查。当选项文本可能由 LLM 动态生成时，这条更要进模板约束而不是靠运气。
静默失效杀死信任链
第三类设计缺陷最隐蔽。#51504 记录了这样一个状态机故障：同一条 effect: "ask" 规则，会话前半段两次调用都正常弹确认框，后半段六次调用全部约 400ms 静默执行，对话框再也不出现。用户逐项测试了通配符与精确规则、热重载与重启服务、Code Mode 与原生调用，都无法恢复弹窗；对同一 action 配 deny 则一直正常。
它对信任链的杀伤在于时序：**用户曾经见过弹窗，所以相信弹窗存在。**这和一开始就没做过审批机制是两种性质——后者用户会保持戒心，前者会让用户在"已被验证过的安全感"里放手越来越久。任何有审批流的产品都应该把这个问题当成通用教训：审批门是否在工作，不能只靠"上一次弹过"来推断。要么给审批状态一个持续可见的指示器（比如每次工具调用后在日志里显式记录"permission decision: ask→approved by user"或"ask→skipped”），要么在检测到规则未触发时主动报警。目前该 issue 仍开放，没有公开的根因结论。
给同类产品的四条检查清单
把三个案例翻译成设计评审时可以逐条问的问题：
- 从"全放行"到"最小权限”，哪边点击次数少？ 如果答案是前者，重做引导流程。新装默认值应该是 ask 打底，放宽需要理由，而不是反过来。
- 审批引擎到底在看什么？ 只匹配命令行字符串的审批，遇到脚本包装就形同虚设——这是 #56319 维护者bot 亲自确认的机制盲区。设计上至少要检查 Agent 写入磁盘并即将执行的脚本内容，或者对"写文件+执行该文件"的组合动作强制二次确认。
- 确认界面的每个词都过一遍对抗测试。 假设选项文案可能被模型生成或被模板拼接，问一句：这个措辞会不会让理性的用户做出不可逆的选择？
- 审批状态要可审计。 每条权限规则的判定结果落日志（命中哪条规则、走了哪个分支），既方便事后归因——#46386 就是因为用户没能提供导出会话，issue 无法定性被关闭——也能让"应弹未弹"这类降级立刻暴露。
一个判断
编码 Agent 赛道现在卷的是能力：更快写完代码、更少人工介入。但 10 月的这批 issue 说明，下一轮的竞争点在"敢不敢把方向盘交出去"的信任工程上。权限模型写得再完备，只要默认值引力、选项文案和静默故障三个口子还开着，用户交出去的信任就会被系统性回收。对用户侧的现实建议则是反过来的：在你确认第 4 条落地之前，别把你的数据库、你的主目录和你的一整年温度数据，押在第 1 条和第 2 条的设计善意上。
本文观点基于 anomalyco/opencode 公开 issue #46386、#56319、#54292、#51504 及 OpenCode 官方权限文档（均采集于 2026-11-01）中的事实记录；设计建议为作者依据上述案例做出的推断。