AI Agent-CLI 的启动命令与跳过权限模式
文章目录
- [AI Agent-CLI 的启动命令与跳过权限模式](#AI Agent-CLI 的启动命令与跳过权限模式)
-
- 先分清:你说的"完全授权"到底是哪一层
- 最常用命令速查:正常启动、自动化与完全旁路
- [Claude Code:正常启动与跳过权限](#Claude Code:正常启动与跳过权限)
- [Codex CLI:推荐的无确认模式与真正的无沙箱模式](#Codex CLI:推荐的无确认模式与真正的无沙箱模式)
-
- 正常启动与恢复会话
- [B 档:无人确认,但只允许工作区写入](#B 档:无人确认,但只允许工作区写入)
- [C 档:跳过审批并关闭沙箱](#C 档:跳过审批并关闭沙箱)
- [Gemini CLI:YOLO 与沙箱是两个独立开关](#Gemini CLI:YOLO 与沙箱是两个独立开关)
- [GitHub Copilot CLI:`--yolo` 是 allow-all,不是去沙箱](#GitHub Copilot CLI:
--yolo是 allow-all,不是去沙箱) - [Qwen Code:优先在会话内使用 `/approval-mode`](#Qwen Code:优先在会话内使用
/approval-mode) - [OpenCode 与 Aider:一个是可配置权限引擎,一个是确认自动回答](#OpenCode 与 Aider:一个是可配置权限引擎,一个是确认自动回答)
- 选择建议:不要为了少点几次确认而交出主机权限
- 证据、验证方式与版本漂移处理
- 结论
主结论: "全自动"不等于"无沙箱完全授权"。Claude Code、Gemini CLI、Qwen Code、OpenCode、Copilot CLI 的 YOLO/自动批准模式主要取消工具调用确认;Codex 的
--dangerously-bypass-approvals-and-sandbox才明确同时跳过审批和 OS 沙箱。日常开发优先选择可写工作区但保留沙箱的模式;真正的无边界模式只应放进独立虚拟机、容器或短生命周期 CI Runner。
**核对范围:**本文于 2026-08-27 依据各产品官方 CLI/权限文档和本机帮助编写。本机已验证 Claude Code2.1.231、Codex CLI0.150.1;其余产品以官方文档为准。版本、操作系统、企业策略和安装渠道会改变可用参数,执行前始终以<工具> --help为最终依据。
先分清:你说的"完全授权"到底是哪一层
不同 CLI 的同一类宣传词常常对应不同安全边界。最容易出错的前提是把"自动批准编辑"或"YOLO"理解为"能无约束地访问电脑"。实际上至少有四层:
| 层次 | 它控制什么 | 常见名称 | 不代表什么 |
|---|---|---|---|
| 工作区信任 | 是否加载项目内的规则、插件、MCP、hooks | trust / skip trust | 不等于允许任何 shell 命令 |
| 工具审批 | 编辑、命令、网络请求是否逐次询问 | auto-edit / allow-all / yolo | 不等于解除 OS 文件或网络隔离 |
| OS 沙箱 | shell 子进程能读写哪些路径、能否联网 | sandbox | 通常只约束 shell,不一定约束每个内置工具 |
| 组织策略 | 管理员的硬性允许/拒绝规则 | managed policy | 用户参数通常不能覆盖 |
所以应把使用方式分成三档,而不要只问"要不要跳过权限"。
| 档位 | 行为 | 适合场景 | 代表命令 |
|---|---|---|---|
| A:人工确认 | 修改/命令按需询问 | 新仓库、生产配置、外部系统 | claude、codex -s workspace-write |
| B:无人值守但有边界 | 自动编辑和/或自动命令,但保留沙箱或拒绝规则 | 日常开发、受控 CI | codex -s workspace-write -a never、gemini --approval-mode=yolo --sandbox |
| C:无审批且无沙箱 | 工具不再确认,shell 不受工具自身沙箱限制 | 专用 VM/容器、可销毁 Runner | codex --dangerously-bypass-approvals-and-sandbox |
"B 档"通常才是想要的效率模式:因为代码代理需要频繁写文件、跑测试,但绝大多数项目并不需要拿到家目录、SSH 密钥、浏览器会话或宿主机全部网络的访问权。
最常用命令速查:正常启动、自动化与完全旁路
下表给出每个工具最实用的三种启动方式。提示词是可选的首条任务;先 cd 进入仓库,或使用各工具的工作目录参数。
| 工具 | 普通交互启动 | 自动批准的常用写法 | 最强权限/短写法与边界 |
|---|---|---|---|
| Claude Code | claude |
claude --permission-mode acceptEdits(只自动编辑) |
claude --dangerously-skip-permissions;跳过工具确认,非"关闭 OS 沙箱"的同义词 |
| Codex CLI | codex |
codex -s workspace-write -a never |
codex --dangerously-bypass-approvals-and-sandbox;短写法 codex --yolo,同时跳过审批和沙箱 |
| Gemini CLI | gemini |
gemini --approval-mode=auto_edit |
gemini --approval-mode=yolo;旧短写法 gemini -y / --yolo 已废弃;需要时另加 --sandbox |
| GitHub Copilot CLI | copilot |
copilot --allow-tool='shell(git:*)'(精细放行) |
copilot --allow-all 或 copilot --yolo;开放工具、路径、URL,不等价于关闭沙箱 |
| Qwen Code | qwen |
会话内 /approval-mode auto-edit |
会话内 /approval-mode yolo;官方当前文档以会话指令或设置文件配置,未把 CLI 短参数列为正式入口 |
| OpenCode | opencode |
opencode --auto |
opencode --auto 是"除显式 deny 外自动批准",不是关闭系统隔离;也可配置 permission: "allow" |
| Aider | aider |
aider --yes-always |
同左;仅自动回答确认,不提供类似 Codex 的内置 OS 沙箱旁路参数 |
以下内容解释每个命令真正放开的范围,避免误用。
Claude Code:正常启动与跳过权限
日常启动
bash
cd /path/to/repository
# 正常交互;编辑和风险操作按当前权限策略请求确认
claude
# 带第一条任务进入交互会话
claude "检查当前未提交改动,先给出最小修复方案"
# 延续当前目录最近会话
claude -c
# 非交互执行后退出,适合脚本
claude -p "只分析当前代码中的空指针风险,不修改文件"
权限档位
Claude Code 的官方 CLI 参考列出 default、acceptEdits、plan、auto、dontAsk、bypassPermissions 等模式。应按需求选择:
bash
# 文件编辑不用逐次确认;shell/其他敏感能力仍走相应规则
claude --permission-mode acceptEdits
# 由自动模式判断可放行的动作;保留风险护栏
claude --permission-mode auto
# 跳过所有 permission prompts,等价于 bypassPermissions
# 仅限外部隔离、无互联网的受信任环境
claude --dangerously-skip-permissions
# 同一含义的显式模式名,适合读配置时辨识
claude --permission-mode bypassPermissions
--allow-dangerously-skip-permissions 不是 直接跳过权限:它只让你可以在会话中切换到 bypassPermissions,启动时仍处于其他模式。
bash
# 可以在会话中切到 bypassPermissions,但并非一启动就跳过确认
claude --permission-mode plan --allow-dangerously-skip-permissions
**边界与风险:**Claude 的权限规则、工作区信任和 Bash 沙箱是相互补充的层。--dangerously-skip-permissions 等价于 bypass permission mode,但不能据此推导"所有组织规则都失效"或"所有层面的 OS 隔离都已关闭";管理员策略和 deny 规则仍可能限制行为。对陌生仓库,尤其含 .claude 配置、MCP 或 hooks 的仓库,先普通启动并审阅信任提示。
Codex CLI:推荐的无确认模式与真正的无沙箱模式
正常启动与恢复会话
bash
cd /path/to/repository
# 交互式启动
codex
# 带首条任务
codex "修复当前测试失败;只改根因相关文件并运行对应测试"
# 指定目录但不切换终端目录
codex -C /path/to/repository
# 续接当前目录最近一次交互会话
codex resume --last
B 档:无人确认,但只允许工作区写入
这是本机开发中优先推荐的组合:取消审批等待,但仍由 Codex 沙箱把写入范围限制在工作区。
bash
# 交互式:允许在工作区读写,不请求人工批准
codex -s workspace-write -a never
# 非交互/CI:相同边界
codex exec -s workspace-write -a never \
"运行相关测试,修复失败;不得访问工作区外文件。"
可选的沙箱级别为:
bash
codex -s read-only # 仅分析/审查
codex -s workspace-write -a never # 无确认,但限制在工作区(常用)
codex -s danger-full-access -a never # 无确认且可访问全系统;仍不等于跳过所有配置/策略
--approve-for-me 是另一种折中:审批交给自动审查,并使用 workspace-write 沙箱。它并非"永不请求"的同义词,更适合希望让工具对危险操作保留自动判断的人。
C 档:跳过审批并关闭沙箱
bash
# 官方完整写法:明确、适合脚本和团队文档
codex --dangerously-bypass-approvals-and-sandbox
# 本机 Codex CLI 0.150.1 已验证可接受的短写法
codex --yolo
此模式同时关闭确认和命令沙箱,官方标记为"EXTREMELY DANGEROUS"。它应只在独立 VM、容器或可销毁 CI Runner 中使用。不要在个人主机上做永久 alias,例如 alias codex='codex --yolo':一次错误提示、被污染的仓库规则或供应链脚本就可能以你的账户权限读写工作区外文件、删除数据或发起网络请求。
**重要事实:**当前本机 codex --full-auto --help 返回"unexpected argument",说明 --full-auto 不是此版本 Codex CLI 的有效参数;不要把其他产品的术语照搬到 Codex。
Gemini CLI:YOLO 与沙箱是两个独立开关
普通与非交互启动
bash
cd /path/to/repository
gemini
# 首条任务后继续交互
gemini "解释当前项目的构建流程"
# 非交互执行
gemini -p "检查 TypeScript 类型错误并给出修复建议"
四个审批模式
Gemini CLI 官方参考列出 default、auto_edit、yolo、plan。其中 auto_edit 只解决频繁编辑确认,常是本机的合适起点:
bash
# 自动接受文件编辑,其他高风险工具按模式处理
gemini --approval-mode=auto_edit
# 自动批准所有动作
gemini --approval-mode=yolo
# 旧简写仍可见但已标为 Deprecated;新脚本不要使用
gemini -y
Gemini 的沙箱是独立参数。因此如果你确实要无确认运行,但仍希望有执行隔离,应显式叠加:
bash
# 自动批准动作 + 由沙箱限制实际执行环境
gemini --approval-mode=yolo --sandbox
# 仅跳过首次工作区信任检查;它不是权限全开
gemini --skip-trust
取舍: --approval-mode=yolo 减少对话中断,但不应被描述为"自动开启沙箱"或"关闭沙箱"。是否有 OS 级约束由 --sandbox 和当前运行环境另行决定。
GitHub Copilot CLI:--yolo 是 allow-all,不是去沙箱
日常启动与会话内切换
bash
cd /path/to/repository
copilot
进入会话后可使用:
text
/permissions show
/permissions assisted
/permissions allow-all
# aliases:
/allow-all
/yolo
运行前完全放行与更安全的精细放行
bash
# 所有可用工具、路径与 URL 都不再逐次请求确认
copilot --allow-all
# 同义短写法
copilot --yolo
# 更推荐:只放行该仓库的 Git 子命令;其余能力仍按默认策略
copilot --allow-tool='shell(git:*)'
官方说明中,--allow-all / --yolo 等价于同时使用 --allow-all-tools、--allow-all-paths、--allow-all-urls。这确实比"自动编辑"宽得多,但仍不能推导为关闭 OS 沙箱。GitHub 反而建议在 allow-all 时配合 local/cloud sandbox,并明确不建议把此类参数设置成永久 alias。企业管理员也可能禁用这些选项。
Qwen Code:优先在会话内使用 /approval-mode
启动与非交互模式
bash
cd /path/to/repository
qwen
# 适合脚本或批处理
qwen -p "分析此模块的依赖关系,不修改文件"
五档权限模式
Qwen Code 的官方文档把权限分为 Plan、Ask Permissions(底层值为 default)、Auto-Edit、Auto、YOLO:
text
# 当前会话切换
/approval-mode default # 每次编辑与 shell 操作确认
/approval-mode auto-edit # 编辑自动通过,shell 仍确认
/approval-mode auto # 分类器放行安全操作,不确定时拒绝/询问
/approval-mode yolo # 编辑与 shell 操作全部自动通过
可将选择写入项目或用户级 .qwen/settings.json:
json
{
"tools": {
"approvalMode": "auto"
}
}
对受控自动化环境才改为:
json
{
"tools": {
"approvalMode": "yolo"
}
}
Qwen 的 auto 比 YOLO 更适合长期本机任务:文档说明其分类器会默认阻断不可逆删除、curl | sh、凭据外传、未经授权的持久化、弱化安全、向主分支 force-push 等行为,并在不确定时 fail-closed。YOLO 则按照你的终端账户权限执行任意命令;它是"工具审批全开",不是天然隔离环境。
OpenCode 与 Aider:一个是可配置权限引擎,一个是确认自动回答
OpenCode
bash
cd /path/to/repository
opencode
# 自动通过所有未被明确 deny 的权限请求
opencode --auto
# 非交互执行同样支持
opencode run --auto "重构这个模块并运行测试"
OpenCode 的权限动作有 allow、ask、deny 三种。--auto 只把原先会 ask 的请求自动放行,显式 deny 仍然生效;因此它不是"取消一切限制"。若项目确实要把所有工具设为 allow,使用配置文件而不是模糊猜测参数:
json
// opencode.json
{
"permission": "allow"
}
更可审查的写法是仅放行需要的动作、拒绝破坏性命令:
json
{
"permission": {
"*": "ask",
"bash": {
"git *": "allow",
"npm test": "allow",
"rm *": "deny"
},
"edit": "allow"
}
}
Aider
bash
cd /path/to/repository
aider
# 对确认提示一律回答 yes
aider --yes-always
Aider 的 --yes-always(环境变量 AIDER_YES_ALWAYS)语义很直接:永远同意确认提示。它适用于已限定文件、已提交/备份的短任务;并不像 Codex 一样内置一个"关闭审批加关闭沙箱"的独立危险开关。若要自动执行,还应靠容器、权限较小的 CI 用户或 Git worktree 提供外部边界。
选择建议:不要为了少点几次确认而交出主机权限
日常本机开发
优先顺序是"自动编辑 → 受沙箱保护的无确认 → 全权限"。可直接采用:
bash
# Claude Code
claude --permission-mode acceptEdits
# Codex
codex -s workspace-write -a never
# Gemini CLI
gemini --approval-mode=auto_edit
# Qwen Code(进入会话后)
/approval-mode auto
# OpenCode
opencode --auto
原因是编译与测试通常是开发任务的一部分,而写入范围外的系统目录、访问网络、读取凭据并不是。把审批取消但将 shell 约束在工作区,能保留大部分效率,同时限制一次异常代理行为的影响半径。
CI、批处理或一段确定的自动化
建议为每次任务创建新的容器/虚拟机或短生命周期 Runner,使用最小权限账户、临时 token、无生产凭据、可回收工作目录。然后可以采用更高自动化档位:
bash
# 受限 runner 中的 Codex
codex exec -s workspace-write -a never \
"运行测试并修复;不得推送、不发布、不访问生产环境。"
# 已隔离 runner 中确有必要时的 Codex 全旁路
codex --dangerously-bypass-approvals-and-sandbox \
"执行预定义的测试修复任务;禁止读取或输出任何凭据。"
后一条不应成为本机默认。真正降低风险的是外部隔离和凭据最小化,不是把"dangerously"换成更短的别名。
永远保留的三项约束
- 不给代理长期可用的生产密钥、SSH 私钥或云平台全权凭据;需要时提供最小作用域、短期凭据。
- 不在未经审阅的仓库上开全自动:项目规则、hooks、MCP 和下载脚本都可能扩大行动面。
- 自动执行不等于无需验收:至少检查
git diff、测试结果、依赖变动和任何外部副作用;涉及git push、部署、数据迁移仍应单独设人为关口。
证据、验证方式与版本漂移处理
本文的关键命令来自官方一手资料:
| 工具 | 主要核对来源 | 本次确认的关键事实 |
|---|---|---|
| Claude Code | CLI reference、Permissions | --dangerously-skip-permissions 等价 bypassPermissions |
| Codex CLI | Developer commands 与本机 codex --help |
0.150.1 存在危险长参数和 --yolo;没有 --full-auto |
| Gemini CLI | CLI reference | --approval-mode=yolo;--yolo/-y 已废弃;沙箱独立 |
| GitHub Copilot CLI | CLI reference、Allowing tools | --allow-all 与 --yolo 开放工具/路径/URL |
| Qwen Code | Approval Mode | default、auto-edit、auto、yolo 的职责边界 |
| OpenCode | CLI、Permissions | --auto 自动通过非 deny 请求 |
| Aider | Options reference | --yes-always 永远回答确认 |
每次升级某个 CLI 后,执行下列最小验证。它实际证明的是"你安装的版本识别这些参数",不能证明某项动作在某个企业策略、网络、操作系统或外部系统中必然可用。
bash
claude --help | rg 'permission-mode|dangerously-skip'
codex --help | rg 'sandbox|ask-for-approval|bypass'
gemini --help | rg 'approval-mode|sandbox|yolo'
copilot --help | rg 'allow-all|yolo|sandbox'
qwen --help
opencode --help | rg -- '--auto'
aider --help | rg 'yes-always'
**未验证项:**本文没有在真实生产环境、带组织强制策略的账号或真实破坏性命令上运行这些模式;也不应这样验证。若你的团队有企业策略,先在无敏感数据的测试仓库、最小权限账号和隔离环境里做一条无害任务验证。
结论
最短答案是:
bash
# Claude Code:正常 / 跳过权限
claude
claude --dangerously-skip-permissions
# Codex:正常 / 无审批但保留工作区沙箱 / 真正全旁路
codex
codex -s workspace-write -a never
codex --yolo # = --dangerously-bypass-approvals-and-sandbox
# Gemini CLI:正常 / 自动编辑 / YOLO(沙箱另开)
gemini
gemini --approval-mode=auto_edit
gemini --approval-mode=yolo --sandbox
# Copilot CLI:正常 / 全工具、路径、URL 放行
copilot
copilot --yolo
# Qwen Code:正常 / 会话内 YOLO
qwen
/approval-mode yolo
# OpenCode:正常 / 自动通过非 deny 请求
opencode
opencode --auto
# Aider:正常 / 自动确认
aider
aider --yes-always
但实际工作中,更稳妥的默认选择是 codex -s workspace-write -a never、claude --permission-mode acceptEdits、gemini --approval-mode=auto_edit 或 Qwen 的 auto。只有 Codex 的危险旁路明确同时取消审批和沙箱;把它留给外部已隔离的自动化环境,才不会为了减少一次确认而把风险扩大到整台机器。