当天目标：读懂"审批 × 沙箱"是两个正交维度，给自己设出日常安全档，清楚知道红区在哪、为什么不能碰。

为什么"管住它"排第二天，而不是最后

因为它是你敢不敢放手的前提。教程普遍把权限讲成"三档滑块"——只读 / 自动 / 全自动。这是错的，而且危险。

真实情况是两个互相垂直的维度：横轴是"审批"（它动之前要不要问你），纵轴是"沙箱"（它跑的时候是不是被关在隔离笼里）。把它们当成一维滑块，你会误以为"我选了只读就安全"，其实只读模式下它照样能读你全盘文件。

审批：它动手之前，要不要先问你

官方把审批分成三档：

• untrusted：敏感操作（写文件、跑命令、联网）逐条问你确认。最稳，初探首选。
• on-request：它自己判断哪些要问，低风险自己干，高风险问你。日常推荐档，省心但不如 untrusted 稳。
• never：全自动，啥都不问。只配给"你信得过的成熟项目 + 已经锁死的沙箱"。新手碰都不能碰。

默认档因版本/客户端而异，常见是 workspace-write × on-request（Auto 预设）。初学用 untrusted 最稳，别迷信"默认就安全"。

CLI 写法：codex --ask-for-approval on-request，简写 -a on-request。会话内也能用 /permissions 临时切。

一个安全要点：项目级配置改不了某些全局安全项。比如你不能在仓库的 config.toml 里覆盖 model_provider 或 openai_base_url 去偷偷指向别处——Codex 故意不让项目级配置动这一组安全相关键。所以别信"改 base_url 接国产模型"的偏门，那条路在配置层就被堵了。

沙箱：它跑的时候，被关在哪儿

官方把沙箱分成三档：

• read-only：能读你文件，改和跑被锁。最安全，初探用。
• workspace-write：能在当前工作区里改和跑，但默认断网——它需要联网时会被拦，得显式放行。日常推荐档。
• danger-full-access：裸机跑，读写联网全开。红区，别给。

CLI 写法：codex --sandbox workspace-write，简写 -s workspace-write。网络是独立于沙箱的开关——workspace-write 默认关网，你要它联网得单独开（[sandbox_workspace_write] network_access = true）。这点教程几乎没人提，但极关键：默认断网意味着它没法偷偷外传你文件，也意味着它"需要联网却没网"时会出错——这正是下一段要讲的翻车。

各平台沙箱实现不一样，别迷信"开了沙箱就绝对安全"：

• macOS：用 Seatbelt 做系统级隔离。
• Linux：用 seccomp 沙箱（部分内核/发行版回退到较弱隔离，会提示你）。
• Windows：有原生沙箱（elevated / unelevated），推荐 elevated；实在不行用 WSL2 跑 Codex，隔离更干净。注意 elevated 在企业机上有时会直接失败并静默降级成较弱隔离——进会话看启动回显/日志有没有提示降级，降级后它其实没被关严，别以为开了就万事大吉。另外 WSL1 已不支持，用 WSL2。

把两个维度拼成矩阵

横轴是沙箱，纵轴是审批。九个格子，危险组合标红：

	沙箱 read-only（隔离读）	沙箱 workspace-write（工作区可写，默认断网）	沙箱 danger-full-access（裸机）
审批 untrusted（逐条问）	最安全，初探首选	日常档：能改能跑但隔离 + 断网	仍危险：全自动前的过渡，不推荐
审批 on-request（该问才问）	安全且省心	进阶日常档	危险
审批 never（全自动）	能读全盘，慎用	只信成熟项目时可用	红区：全自动 + 裸机，一夜改光

结论：日常用 on-request × workspace-write。红区 never × danger-full-access 谁都别给。

嫌弹窗烦是真实痛点，正确出口不是开 danger-full-access，而是在 sandbox/（Day 1 建的试错目录）或容器里放宽——那里没有真代码；或用 --approve-for-me 代你批常规确认，但它仍受沙箱约束。

最阴的一种翻车：断网伪成功

这是最容易被忽略的坑，因为失败被伪装成了成功。

workspace-write 默认断网。当你的任务需要联网（比如 npm install 拉包、curl 调 API），而沙箱没开网，它会失败。正常的失败你会看到报错。但 Agent 有时候不报错——它"自己改道"，绕开联网那步，写出一份"能跑但逻辑是错的"代码。它以为绕过去了，其实埋了雷，你还以为任务完成了。

对策：需要联网的任务，显式给沙箱开网（或临时放宽并放行网络）；跑完一定去看它实际执行了什么命令，别只看它说"完成"。怎么看——会话里有命令回显区，也可以开日志（codex -c log_dir=./.codex-log 后查 ./.codex-log/codex-tui.log，把 npm install 失败这类行抓出来）。

动手前先打 Git 检查点（防它改坏你能回滚）

打检查点前先确认你会基础 Git：装好 Git、懂 git init / status / commit；还不会先花 20 分钟补。Codex 要改你文件之前，先让仓库有个"出事能退回"的快照：

git status                         # 确认当前是干净的工作区
git switch -c codex-<日期>-<任务>  # 开一条专门的分支给它折腾，主线不受污染
# 或者不想开分支：git stash 把当前改动暂存，事后 git stash pop 取回

它真改出问题，你 git checkout . 或删掉那条分支就能回到检查点，不至于手动一个个文件救。Day 4 讲 worktree 时还会用它做并行隔离。

把日常档写进配置（别每次手敲参数）

~/.codex/config.toml 不存在就自己建（Windows 上就是 C:\Users\你的用户名\.codex\config.toml，用记事本保存时文件名加英文引号，免得变 .txt）：

# ~/.codex/config.toml
approval_policy = "on-request"        # 日常档：该问才问
sandbox_mode = "workspace-write"      # 工作区可写，默认断网

[sandbox_workspace_write]
network_access = false               # 显式关网；需联网的任务改成 true 或临时放宽

[windows]                            # Windows 用户加这条
sandbox = "elevated"

预期：之后每次进 Codex，默认就在这个档位，不用每次加 -a / -s。要临时更严，会话里 /permissions 切 untrusted；要临时放开网络，改 network_access = true 后重启会话。

三个锦囊

1. 今天就把日常档设成 on-request × workspace-write，写进 ~/.codex/config.toml，别每次手动加参数。
2. 红区 never × danger-full-access 写进脑子，任何教程让你"开 full 权限图省事"，一律当没看见。
3. 需要联网的任务，跑完查它实际执行的命令，断网伪成功不会自己跳出来告诉你。

自测标尺（用命令验证）

• [ ] 你打开 ~/.codex/config.toml，确认里面有 approval_policy 和 sandbox_mode 且值是日常档。
• [ ] 会话里 /permissions 能切到 untrusted，且你知道网络是独立开关（network_access）。
• [ ] 你能说出"断网伪成功"是什么、怎么防（去看实际执行命令）。

效率日志

任务	手动做要几分钟	Codex 做+你验收几分钟	打回几次
配安全档 + 试一次断网任务	___	___	___

---