OpenRig权限与信任模型全解YOLO为何默认关闭danger-full-access的真实边界是什么【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig 是一个 AI 智能体团队编排工具它把 Claude Code、Codex 和 Pi 组成拥有角色分工、共享上下文和独立工作区的持久化团队。正因为这些智能体会在你的机器上直接执行命令OpenRig 设计了一套分层的权限与信任模型默认安全、逐级放权、全程可审计其中最具争议的 YOLO 模式默认关闭。本文带你从零看懂这套模型搞清楚danger-full-access到底给了什么、又没给什么。 第一眼看懂四档内置权限姿态OpenRig 用四个姿态posture来描述团队启动时的权限等级从紧到松依次是Locked → Standard → Open → YOLO姿态默认行为适合场景一句话理解Locked默认全拒deny仅允许工具链和 rig 生命周期命令不受信任的代码、敏感仓库最小爆炸半径⭐Standard默认放行push 放行开 PR、发布、合并、force-push 会询问人类日常交互式开发官方推荐默认80% 软件工厂姿态Open几乎全放行只有毁灭级操作会询问需要长时间无人值守的自治舰队YOLO 之下的一档YOLA全量绕过full bypass启动即最高放行你刻意信任的工作与环境明文命名的完全放手四份内置策略的完整定义可以逐一阅读locked.policy.mdstandard.policy.mdopen.policy.mdyolo.policy.md一个关键设计策略里区分ASK ≠ deny。Standard 对发布类操作的处置是交给人类决定而不是偷偷静默拦截——这是官方称之为best-effort-safe的原则。️ 永远存在的地板可用性底线Floor即使什么都不配置OpenRig 也为每个智能体保留一条始终开启的地板flag surface不依赖配置文件Claude--permission-mode acceptEdits—— 编辑可以顺畅进行但权限模式不越界Codex-s workspace-write—— 沙箱被显式限定在工作区内这是 OpenRig 主动写入的标志而不是 Codex 的默认值Pi--no-approve—— 注意这是**资源信任resource trust**姿态Pi 本身没有权限策略面。这条地板的意义在于权限策略是意图地板是硬约束。Locked 的智能体仍然可以编辑文件但它无法越出最小允许集去碰网络、密钥或远程操作。 YOLO 默认关闭开关、覆盖与优先级源码注释第一行就写明了态度OpenRig YOLO mode (opt-in, DEFAULT OFF)见 yolo-mode.ts。YOLO 开启后每个受管 seat 以各自运行时最大放行的启动标志启动运行时地板默认YOLOfull bypassClaude Code--permission-mode acceptEdits--dangerously-skip-permissionsCodex-s workspace-write-s danger-full-access -a neverPi--no-approve--approve全量资源信任优先级三层裁决顺序成员策略 rig 策略 环境开关某个 seat 挂载了自己的策略时它对该 seat 权威生效且双向覆盖OPENRIG_YOLO环境变量——全局开了 YOLO挂载了builtin:locked的 seat 依然保持地板反之挂载 full_bypass 策略的 seat 无需环境变量即可放行。YOLA 是确定性标志不经过技能翻译YOLO 属于surface: flag策略直接解析为稳定的启动标志由运行时确定性应用而 Standard/Open/Locked 这类配置面策略则由applying-a-permission-policy技能翻译成各运行时的具体规则见 applying-a-permission-policy/SKILL.md。零配置写入YOLO 路径不写任何权限配置文件它只选择启动标志。记录策略 ≠ 改写原生配置。官方文档在 README.md 中强调YOLO默认关闭只有被显式选择的 full-bypass 策略才会触发绕过。 解剖 danger-full-access它给了什么没给什么很多用户把danger-full-access理解为上帝模式但 OpenRig 对它划定了清晰边界它给了什么Codex 的最大化沙箱-s danger-full-access在 full_bypass 策略下还附带-a never即永不走审批Claude 跳过所有权限提示适用于你刻意信任的工作与环境源码原话Use only for work and an environment you deliberately trust。它没有给什么常见误解❌不替代原生托管限制YOLA 是启动参数各运行时的原生配置、托管策略仍然生效——选择策略不会把配置规则翻译成新的权限❌不是全局通行证独立运行codex --yolo并不等于 OpenRig 的配置仅靠遗留环境变量OPENRIG_YOLO1开启的路径甚至只选沙箱、不选审批策略❌不等于任务授权权限规则授予的是执行能力不是发明任务、发布成果或改动其他主机的权威。策略文档还特意澄清了 Pi 的措辞纪律--approve是资源信任不是权限策略——信任位与权限面在 OpenRig 中是两类控制不应混为一谈。 场景速查我该选哪一档陌生代码 / 敏感仓库选Locked。默认拒绝只放行构建、测试和 rig 启停。日常开发有你在场保持Standard默认。推送自由PR、发布、合并、强推会先问你一句。自治舰队无人值守选Open。毁灭级操作清空删除、丢弃持久存储、重置版本库会触发询问并故意冻结该 seat——这正是设计好的安全网。可信环境全速运行YOLA。记住代价没有任何停顿包括毁灭级动作。 判断口诀ASK 会冻结自治智能体。如果你的团队需要永不暂停那是 YOLO 的语义如果只是想少弹窗Standard 或 Open 就够了。️ 逐席精细控制与审计留痕团队级姿态之外OpenRig 支持按 seat 覆盖且必须留审计理由# 查看 / 应用 rig 级策略 rig policy permissions list rig policy apply yolo --spec ./my-rig/rig.yaml # 审计式修改某个 seat 的下次启动权限floor / full_bypass / inherit rig seat set-permissions ownerfirst-project --mode full_bypass \ --reason Operator selected broader access注意几个诚实的设计声明rig seat set-permissions不会重启 seat、不改写原生历史只记录期望选择下次启动时生效rig seat status会区分期望值与上次实际启动参数但两者都不等于原生强制的证据——OpenRig 从不假装能证明运行时的最终执行权限修改权限的正确姿势是先暂停工作、用原生/permissions检查而不是重启 rig重置权限。完整的权限操作指南见 getting-started.mdrig 规格中策略字段的定义见 rig-spec.md。总结OpenRig 的权限与信任模型可以浓缩成三句话默认不放任——地板恒开YOLO 默认关闭放行永远要显式选择权限分层清晰——启动标志、配置策略、原生托管限制是三条独立通道互相不替代诚实不越权——ASK 就是交给人类选策略不等于改写配置状态显示也不假装是原生强制的证明。理解danger-full-access的边界之后你才能真正回答那个问题这个团队、这个仓库、这个环境值不值得让智能体完全放手答案在四档姿态里选择权始终在你手里。【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考