TL;DR省审批的正确姿势不是 --yolo 一关了之，而是给 --full-auto 配好护栏。清单来自社区安全实践与已验证行为：选对场景、留好退路、认真对待弹窗、验收产出。
来源信号 SOURCES
以下内容整理自社区公开讨论，本页只做拆解与核实，不搬运原帖；观点归属原作者。
CodeAgentSwarm · Use --full-auto Safely · 安全与审批实践查看原帖 ↗GitHub (openai/codex) · yolo 模式沙箱失败仍请求审批的已知行为记录查看原帖 ↗
事实性知识 FACTS
这些说法可回到所列来源核对；涉及限额算法时，官方账户页面优先于社区归纳。
- 官方口径里，
--yolo/ --dangerously-bypass-approvals-and-sandbox 会同时关掉沙箱与审批两层，风险最高。 - 已验证行为：on-failure 策略下，沙箱失败的命令仍会请求审批——即便是自动档，审批弹窗也未必归零，GitHub 有对应记录。
- 社区安全实践文章专门讨论如何安全使用 --full-auto，把护栏当作开自动档的前置条件，而不是可选项。
- workspace-write 沙箱（macOS 用 Seatbelt 实现）是护栏的物理基础，它划出了自动执行的活动边界。
概念性知识 CONCEPTS
社区讨论里的概念不全是事实——每条都标注了它的性质，读之前先看标签。
--full-auto来源可核对
低摩擦的自动执行档：沙箱内自动干活、失败才请示。社区把它当日常主力档位使用，前提是护栏到位。
护栏（guardrail）个人观点
开自动档前铺好的安全网：干净的 git 状态、独立分支、敏感文件离场、明确的任务边界。实践共识，不是官方要求。
可丢弃环境个人观点
出事也不心疼的环境：独立克隆、一次性副本、无敏感数据的项目。社区建议自动档先在这类环境里跑熟。
审批疲劳待验证假设
弹窗频繁导致的无脑放行倾向。社区把它当真实风险讨论，但目前缺少量化研究。
场景 SOP STEP BY STEP
目标在保留审批兜底的前提下，用 --full-auto 把日常小任务的打断次数降下来。
前提已了解沙箱与审批两层机制（建议先读本站分层配置 SOP）；仓库有版本控制。
- 01圈定场景
只给范围明确、可回滚、不碰敏感数据的任务开
--full-auto；涉及发布、删除、改生产配置的任务永远不开。 - 02留好退路
git status确认工作区干净，切一个独立分支再开工，出问题整支丢掉。 - 03清场
密钥、.env、生产配置移出工作区。别赌沙箱替你保密——最稳的一层，是让敏感文件根本不在场。
- 04带边界开工
codex --full-auto启动，任务描述里写明「只改哪些目录、不碰什么」，边界写进任务而不是靠事后纠正。 - 05认真对待弹窗
on-failure 下沙箱失败会请求审批（已验证行为）。先看失败原因再决定放行，别养成秒批的习惯。
- 06闸门验收
产出必须过仓库的测试与检查命令，再人工过一遍 diff，确认没夹带私货才合并。
- 07规则成文
把「何时可用 --full-auto、何时必须手动档」写进 AGENTS.md 或团队 README，让判断有据可查。
结果--full-auto 成为有边界的日常档：弹窗变少但每次都被认真处理，产出经过测试闸门与人工 review。
看完之后 NEXT
想知道今天的重置判定？回到 首页实时雷达。