TRAE-AI编程
Codex CLI 沙箱靠两个开关配合：--sandbox 决定"它能碰到多大范围"，--ask-for-approval 决定"动手前问不问你"。前者管能力边界，后者管确认时机，两者缺一不可。官方给的低风险日常组合是 workspace-write 配 on-request——围栏锁在工作目录里，要出圈时才弹出来问。
想长期生效就把这两项写进配置文件，临时改就在命令行加参数。真正该花时间想的不是"怎么开最方便"，而是"哪些目录绝对不该让它写"——沙箱的价值体现在排除项上，而不是便利度上。
本文给出三档沙箱的取舍表、命令行与会话内两种改法、四种典型失败分支的排查方式，以及一份开完之后的验证清单。
先看结论
三档沙箱的选择很直接：只想让它读代码、出方案，用 read-only；日常开发、允许它改工作目录里的文件，用 workspace-write；danger-full-access 只在已经做好外部隔离的环境里用，日常别碰。
还有一个必须点名的开关：--dangerously-bypass-approvals-and-sandbox（别名 --yolo）会绕过全部审批和沙箱，每条命令直接跑。官方原话是"只在已经做好外部隔离的环境里用"，新手阶段当它不存在。
命令结构想对照原文核的，可以翻 Codex CLI 教程 逐条对。
一、先看两个开关各管什么
这是最容易混的一对概念，先分清：
- 沙箱（sandbox） 管的是能力边界：能读哪些目录、能写哪些目录、能不能联网。
- 审批（approval） 管的是确认时机：动手前要不要先摆给你看、等你点头。
codex --sandbox workspace-write --ask-for-approval on-request "修一下这个 bug"
这条命令做的是：把可写范围限定在当前工作目录，并要求它在执行不受信操作前先请求批准。选项有长短两种写法，--sandbox 可简写成 -s。
三档沙箱与三档审批的取值如下：
| 开关 | 取值 | 含义 |
|---|---|---|
--sandbox |
read-only |
只读，改文件会被拦 |
--sandbox |
workspace-write |
可写当前工作目录 |
--sandbox |
danger-full-access |
放开全部读写，需外部隔离 |
--ask-for-approval |
untrusted |
遇到不受信操作就问 |
--ask-for-approval |
on-request |
它主动请求时才问 |
--ask-for-approval |
never |
不问，直接执行 |
exec 这种无人值守跑法通常配 never，因为没人在场点头——这也意味着它默认更放得开，务必配合合适的沙箱策略一起用。
二、命令行改与会话内改
两种方式适用时机不同：启动前确定用命令行，中途调整用斜杠命令。
codex -s read-only "只帮我审一下别动手"
codex --cd ~/proj --add-dir ../shared "讲讲这项目"
第一条做的是：以只读方式启动，让它只分析不改文件。第二条做的是：用 --cd 直接指定工作目录、用 --add-dir 额外放开一个共享目录——这两个选项决定了工作目录的边界在哪，是沙箱生效的实际依据。
进了交互界面之后，用 /permissions 当场切换审批模式，用 /status 查看当前会话用的是哪个模型、哪种审批策略、有哪些可写目录。不确定现在是什么配置时，先看一眼 /status 最省事。
/status这条斜杠命令会打印出当前会话概况，包括审批策略与可写目录列表。它是排查"为什么它又能改文件了"的第一站。
三、取舍建议：按场景选档位
选档位的判断依据只有一条：这次任务里，它需要在哪些路径下产生副作用。
- 只想看方案、看 diff：
read-only。做代码审查、让 AI 解释陌生项目时用，最省心。 - 日常开发、需要它改代码跑测试：
workspace-write配on-request。这是官方推荐的日常组合，安全又不烦。 - 跑测试需要装依赖、写临时文件：仍用
workspace-write，但要确认工作目录就是你的项目目录，别把主目录设成工作目录。 - CI 或脚本里无人值守：
exec配never，但一定要配合沙箱档位，并且只在隔离容器里跑。
需要它访问工作目录之外的路径时，用 --add-dir 显式追加，而不要直接升到 danger-full-access。多开一个目录比全盘放开可控得多。
四、四个失败分支与排查方式
4.1 失败分支一：它说没有权限写文件
现象是任务卡在写文件那一步并提示被拦。多数情况是工作目录设错——你启动时的目录不是项目目录。排查方式是先跑 /status 看可写目录列表，再用 --cd 显式指定。
4.2 失败分支二：Windows 上报 1385
这是沙箱命令执行失败，通常是本机策略不给沙箱用户登录权限。排查方式：公司机器找 IT 加权限；急用先切 unelevated 沙箱档位。Windows 上优先用原生 elevated 沙箱，需要 Linux 工具链时才上 WSL2。
4.3 失败分支三：命令找不到
which -a codex
codex --version这两条做的是：列出 PATH 上所有的 codex 可执行文件、打印当前版本。若列出来不止一个，说明装了好几份在打架，只留官方脚本装的那份即可。
4.4 失败分支四：改了配置但没生效
命令行参数只对本次生效，下次启动会回到配置文件的设置。想长期生效必须写进配置文件，改完用 /status 复核。
4.5 开完沙箱之后的验证清单
- 检查：
/status里的审批策略与可写目录是否符合预期 - 检查：
--cd指向的是项目目录而不是主目录 - 运行：让它执行一次会改文件的任务，观察是否被正确拦截或正确放行
- 预期：
read-only下写文件被拦；workspace-write下工作目录内可写 - 失败：
read-only下仍改了文件 → 检查是不是有别的配置项覆盖了 - 修复：调整档位或清理重复安装后重跑
- 验证：动手前先打一个 Git 检查点，跑完用
/diff审一遍改动
最后这条是真正的安全网：沙箱是预防，git 检查点加 /diff 审查才是兜底。两者都要有。
总结
Codex CLI 沙箱由 --sandbox 与 --ask-for-approval 两个开关共同决定，日常用 workspace-write 配 on-request 最稳，danger-full-access 和 --yolo 只在隔离环境里用。工作目录的边界由 --cd 和 --add-dir 决定，它是沙箱真正发挥作用的地方。
三条要点带走：
- 沙箱管能力边界，审批管确认时机，两者要一起配；
- 需要多访问一个目录用
--add-dir，不要直接升到全放开； - 再严的沙箱也要配 Git 检查点与
/diff审查兜底。
下一步建议把常用组合写进配置文件，只在高风险任务时临时收紧。安装与登录细节记不住时，翻 Codex 安装指引 最快。
常见问题
Q：read-only 模式下它还能跑命令吗？
A：只读限制的是写入，命令执行仍受审批策略约束。想完全不让它动手，把审批设成每次都问，并逐条核对它摆出来的动作。
Q：为什么改成 danger-full-access 之后反而更麻烦？
A：因为它不再有任何围栏，任何一次误判都会直接作用到你的文件系统。除非跑在容器或虚拟机里，否则不推荐。
Q：沙箱和审批到底有什么区别？
A：沙箱决定它能碰到多大范围，审批决定动手前问不问你。前者是能力边界，后者是确认时机，两者不能互相替代。
Q：在 CI 里无人值守跑，应该怎么配？
A：用 exec 跑法配 never 审批是对的，但必须同时指定合适的沙箱档位，并且只在隔离容器里执行。没有隔离就放开审批，风险极高。
延伸学习
想把权限与安全这块补齐，可以按这个顺序来：
