OpenCode 权限配置指南：跳过提示前先做 7 个安全判断

OpenCode 权限的安全默认值很直接：不了解仓库时保持 ask；只有重复、可逆、范围明确的动作才考虑 allow；删除、部署、迁移、访问外部目录或接触密钥的动作优先 deny。官方权限文档把动作分成 allow、ask、deny，并说明 --auto 会自动批准没有被明确拒绝的请求。因此 --auto 只是便利模式，不是安全策略本身。

Similarweb 显示，权限相关搜索集中在 `opencode dangerously skip permissions`、`opencode always allow permission`、`opencode allow once not working` 和中文的 `opencode命令执行权限`。这些词背后的意图不是了解产品简介，而是想减少重复确认、修复权限循环，或者判断跳过权限是否安全。

这篇文章不鼓励一键绕过提示，而是给出面向真实项目的 OpenCode 权限配置流程。它适用于本地仓库、VS Code、Ollama、agents、MCP server 和接近 CI 的开发任务，目标是在减少噪音的同时保留对危险命令、外部目录、密钥、生成产物和部署步骤的人工审查。

OpenCode 权限不是装饰配置，而是执行策略。官方文档里的核心动作是 allow、ask 和 deny。allow 表示无需确认直接执行，ask 表示先询问用户，deny 表示阻止动作。配置前先问清楚：这个工具为什么应该被允许？如果理由说不清，就保持 ask 或 deny。很多人把所有确认都当成阻碍，但有些提示正是在提醒边界变化：编辑文件、运行 bash、抓取 URL、访问项目外目录、或让某个 agent 使用额外工具。更好的问题不是“怎样不再询问”，而是“哪些动作重复、可逆、范围清楚，值得免确认”。

安全的权限文件从真实重复工作出发。读文件、搜索仓库、总结代码通常风险较低；小范围文档或源码编辑可以先 ask，再根据稳定模式收窄 allow；安装依赖、改 lockfile、删除文件、部署、迁移数据库、写生产配置或访问密钥，应保持 ask 或 deny。不要只按工具分类，还要看业务风险。一个打印版本号的 bash 命令和一个发布命令不是同一类风险。

当前官方文档说明 `opencode --auto` 会自动批准没有被明确 deny 的权限请求。这对低风险批处理有用，但前提是 deny 规则真实存在。如果先打开 --auto 再想规则，就等于把许多本来可见的确认变成静默执行。使用 --auto 前，至少应拒绝破坏性 shell 模式、生产环境文件、密钥路径、项目外目录，以及不该由 agent 修改的部署产物。

仓库规则应该靠近仓库，方便团队审查；个人工作站偏好可以放全局配置；agent 特例应该贴近对应 agent 定义。不要把密钥写进 `opencode.json` 或权限文件。权限规则描述 OpenCode 可以做什么，不应该保存 provider key、token、私有 base URL 或代理凭据。每条规则旁边最好能说明动作、原因、测试命令和回滚步骤。

Agents 和 MCP server 会改变权限边界。代码审查 agent 可能只需要大量读取、不需要写入；迁移 agent 也许可以编辑窄目录，但不应该部署；MCP 工具名字看起来可能很轻，但背后可能会改数据库、设计稿或工单系统。给每个 agent 的权限要符合角色，不要因为一个流程需要就给所有角色放宽。

准备一个一次性仓库，放一个源码文件、一个生成目录、一个 `.env.example` 和一个无害测试命令。分别跑应该 allow、应该 ask、应该 deny 的任务。好的规则会让预期小任务通过，让危险路径被拦住，并给出能看懂的提示。如果 deny 静默失效，或 allow 覆盖范围比想象大，就继续收窄模式。

OpenCode 一直询问同一动作时，不要立刻放宽全局权限。先记录提示里的工具、命令、路径和 agent，再检查 working directory、外部目录触发、MCP server、plugin hook、command wrapper 和项目配置。`allow once not working` 常见原因是路径或命令包装发生了细微变化。修匹配规则要窄，不要为了一个提示批准整个 bash 类别。