第一次安全使用 Codex：目录、Git、权限和回滚

这是 Codex 系列的第 3 篇。

第 1 篇讲心智：Codex 不是一个更会写代码的聊天框，而是工程 Agent。第 2 篇讲入口选择：什么时候用 App、CLI、IDE、Web / Cloud。

到了这一篇，问题变得更现实：

我第一次真正让 Codex 进项目，怎么不把现场搞乱？

我觉得新手最容易犯的错，不是 Prompt 写得不够漂亮，而是开局没有边界：目录随手选、Git 状态没看、权限默认放大、回滚方式没想。然后 Codex 一旦改多了，用户自己也分不清哪些是原有改动，哪些是 Agent 新改动。

这篇只解决一件事：建立第一次安全使用 Codex 的起手式。

整理日期：2026-06-29。Codex 的权限、沙箱、命令和入口可能继续变化；本文涉及当前能力的事实，以 OpenAI 官方文档和你账号实际可用能力为准。

这篇解决什么问题

读完这篇，你应该能带走三样东西：

这一篇会比“教程”更像操作手册。很多地方看起来有点啰嗦，但这些啰嗦是为了换来一个结果：你敢让 Codex 动手，同时知道怎么把它停下来。

1. 先记住四个护栏

第一次安全使用 Codex，我会先检查四件事：

目录边界 -> Git 基线 -> 权限模式 -> 回滚路径

这四件事不是理论。它们决定你能不能把 Codex 当成工程 Agent，而不是一次豪赌。

官方文档里把 Codex 的安全控制拆成两层：Sandbox mode 决定它技术上能做什么，Approval policy 决定它什么时候必须停下来问你。我的理解是：沙箱是围栏，审批是门禁。你不能只靠其中一个。

2. 目录边界：不要把整台机器交给它

第一次用 Codex，不要从这些地方开始：

更稳的选择是：

一个实用判断是：

如果你不愿意对这个目录整体做 git diff，就不要把它当作 Codex 的工作区。

因为 Codex 的交付物最终要落到文件变化上。目录边界太散，你连 diff 都看不舒服，后面的验收就会变弱。

3. Git 基线：开始前先拍一张现场照片

我会把 Git 基线理解成“现场照片”。让 Codex 动手前，先知道现在是什么样。

最少跑这几条：

git status --short
git branch --show-current
git diff --stat
git diff
git diff --staged

如果你在 Windows PowerShell 里，也一样可以跑：

git status --short
git branch --show-current
git diff --stat

你要看的不是命令本身，而是三个问题：

如果当前工作区是干净的，你可以直接开始。

如果已经有你自己的改动，我建议先做三选一：

比如你可以在 Prompt 里写：

注意：当前工作区已经有我的未提交改动。

请先运行 git status 并区分：
1. 哪些文件可能是我原本的改动。
2. 哪些文件与你计划修改有关。

在我确认前，不要修改已有未提交文件。

这句话很有用。它会逼 Codex 先看现场，而不是假设它是唯一正在工作的人。

4. 新项目先做一个安全分支

如果是一个已经有 Git 的项目，我通常会先建一个分支：

git switch -c codex/safe-first-run

或者：

git checkout -b codex/safe-first-run

分支名不重要，重要的是你知道这轮任务是一个可丢弃的实验。

如果是练习目录，可以从零开始：

New-Item -ItemType Directory -Path "$HOME\Codex-Labs\safe-first-run"
Set-Location "$HOME\Codex-Labs\safe-first-run"
git init

写一个最小文件。PowerShell 里可以这样创建 README.md：

@'
# Safe First Run Lab

This is a tiny practice project for learning Codex safely.
'@ | Set-Content -Encoding utf8 README.md

然后提交基线：

git add README.md
git commit -m "chore: initial safe codex lab"

如果你还不想提交，也至少确认：

git status --short

第一次练习的目标不是完成多厉害的功能，而是跑通一轮：

清楚起点 -> 让 Codex 计划 -> 让 Codex 小步修改 -> 看 diff -> 验证 -> 决定保留或回滚

5. 权限模式：新手默认保守一点

Codex 的本地使用里，最常见的安全组合是：

codex --sandbox workspace-write --ask-for-approval on-request

我的理解是：

官方文档里也提到，版本控制目录通常会推荐类似 Auto 的体验，也就是工作区可写加按需审批；非版本控制目录更适合先用 read-only。

权限可以按这张表选：

这里的 never 只是关闭审批提示，不等于任务天然安全。第一次使用 Codex 时，我更建议把它当成之后自动化阶段才会用到的选项。

如果只是让 Codex 看项目，直接说：

codex --sandbox read-only --ask-for-approval on-request "请只读当前项目，输出目录结构、运行命令和风险点，不要修改。"

如果准备让它改，但仍然保留审批：

codex --sandbox workspace-write --ask-for-approval on-request "请先阅读项目并输出计划，等我确认后再修改。"

不建议第一次就用：

codex --sandbox danger-full-access --ask-for-approval never

或者任何“跳过沙箱和审批”的快捷方式。不是说永远不能用，而是你要先有外层隔离，比如一次性容器、临时虚拟机、专门实验仓库。日常个人项目里，它通常不值得。

6. 网络访问：默认不要随手打开

Codex 本地执行命令时，默认网络访问通常是关闭的。这个默认值很合理。

网络访问不是“查资料”这么简单。它也可能意味着：

所以我会把网络请求分成两类：

如果你准备在配置里长期打开命令网络，不要只把 network_access = true 当成结束。更稳的做法是同时配置 network proxy / domain allowlist，只允许这轮任务需要访问的域名。全网放开应该是例外，不应该是默认姿势。

如果真的要打开命令网络，Prompt 里要写清：

如果需要联网，请先说明：
1. 为什么必须联网。
2. 需要访问哪些域名或服务。
3. 会不会上传项目代码、日志、环境变量或个人数据。
4. 有没有不联网的替代方案。

在我确认前，不要执行联网命令。

这不是不信任 Codex，而是把数据边界说清楚。

7. 审批请求：不要机械点同意

Codex 停下来问你，本来就是为了让你判断风险。不要把审批提示当成弹窗噪音。

每次审批前，我会看四件事：

可以粗略分成三档：

我会特别警惕这些命令：

rm -rf
Remove-Item -Recurse
del /s /q
git reset --hard
git clean -fdx
curl ... | bash
npm install / pnpm install / pip install
database migration
deploy / publish / release
chmod / chown
读取 .env、密钥、token、浏览器 cookie

不是这些命令一定不能用，而是它们需要更明确的上下文和人工判断。

8. 回滚不是最后一步，而是开始前就要想

我建议在开始前就问自己：

如果这轮 Codex 做坏了，我准备怎么撤？

最常见的回滚方式有几种：

注意，我这里故意没有把 git reset --hard 放在默认做法里。它不是不能用，而是太容易把你没注意到的改动一起抹掉。新手阶段先用更窄的回滚动作。

回滚前先做三件事：

git status --short
git diff --stat
git diff --binary --output=codex-failed-attempt.patch

这会把失败尝试保存成 patch。相比直接用 shell 重定向，--output 在不同终端里的编码和换行风险更少一点；--binary 也能保留二进制变更的信息。即使你最后不要这轮改动，也能从里面捞出有价值的部分。

如果工作区混有你自己的改动，不要整仓回滚。先让 Codex 帮你读 diff：

请只读当前 git diff，帮我区分：
1. 哪些变化看起来是我原有改动。
2. 哪些变化看起来是你这轮任务产生的。
3. 如果我要只回滚你这轮任务，建议逐文件怎么处理。

不要执行回滚命令。

这类只读分析非常适合 Codex。它能帮你减少混乱，但最终执行回滚前，你自己要确认。

9. 第一次安全练习：做一个低风险 README 任务

这一篇的练习很小。不要上来就让 Codex 改应用逻辑。

找一个低风险项目，或者新建练习目录。确认 Git 基线后，给 Codex 这个任务：

请先只读当前项目，不要修改。

目标：
帮我判断这个项目是否适合做一次 Codex 安全练习。

请输出：
1. 当前目录是否像一个清晰项目。
2. 当前 Git 状态是否适合开始。
3. 你建议使用 read-only 还是 workspace-write。
4. 如果要做一个低风险 README 修改，你会修改哪些文件。
5. 完成后我应该怎么验证和回滚。

等它回答后，再给第二段：

可以开始一个小修改。

目标：
给 README 增加一段“如何运行或预览本项目”。

约束：
1. 只根据项目里真实存在的脚本和文件编写，不要编造命令。
2. 不要修改 README 以外的文件。
3. 不要新增依赖。
4. 不要联网。

完成标准：
1. README 中新增内容清楚、短小。
2. 总结你修改了什么。
3. 告诉我如何用 git diff 检查。
4. 告诉我如果不满意怎么回滚。

这个任务看起来很小，但它会训练完整流程：

如果这轮你跑顺了，再逐步尝试补测试、改小组件、修小 bug。

10. 给 AGENTS.md 加一段安全规则

如果一个项目会长期让 Codex 参与，我会把安全规则写进 AGENTS.md。不用复杂，先写最重要的几条：

## Codex Safety Rules

- Before editing, inspect the current Git status and mention any existing user changes.
- Keep changes scoped to the requested files and task.
- Do not add dependencies without explaining why and waiting for confirmation.
- Do not run destructive Git commands such as reset/clean/checkout unless explicitly requested.
- Do not read or print secrets, tokens, cookies, or private environment files.
- For network access, explain the destination and purpose before running the command.
- After editing, summarize changed files, verification commands, and rollback options.

这段规则不是为了限制 Codex 的能力，而是为了让每轮任务都有同样的起跑线。

这个博客项目也适合加类似约束：

## Blog Publishing Safety

- Do not publish drafts unless the user explicitly asks.
- Do not overwrite unpublished drafts or personal notes.
- For AI product posts, verify current facts against official sources.
- Before browser-based publishing, confirm images use site-hosted URLs.
- After publishing, verify the public URL, title, images, and local path leaks.

你会发现，很多“Prompt 技巧”其实应该沉淀成项目规则。Prompt 负责本次任务，AGENTS.md 负责项目长期习惯。

还有一个小细节：AGENTS.md 更像“新任务启动时加载的项目说明”，不是你改完后立刻追溯影响已经跑到一半的上下文。官方文档的口径是 Codex 在每次 run 或 TUI session 开始时构建 instruction chain。改完规则后，最好开一个新会话，或者让 Codex 明确列出它本轮加载了哪些 instruction sources。

11. App、CLI、IDE、Cloud 的安全差异

第 2 篇讲过入口选择，这里只补安全视角。

App Worktree 是很好的安全工具。它让 Codex 在一个隔离 checkout 里试错，不打扰你的 Local。官方文档里也提到，Worktree 基于 Git worktree，不同 worktree 有自己的文件副本，但共享 Git 元数据。

我的用法是：

12. 常见误区

我自己的经验是：Codex 大多数失败都不是突然发生的，前面通常已经有信号。比如任务说不清、目录太大、Git 状态很乱、审批请求看不懂、验证命令缺失。安全使用不是等出事再补救，而是开局把这些信号处理掉。

13. 一张安全启动清单

发布前或者执行前，可以直接复制这张清单。

## Codex 安全启动清单

- [ ] 我确认这次只在目标项目目录里工作。
- [ ] 我已经看过 `git status --short`。
- [ ] 我知道当前未提交改动是谁的。
- [ ] 我知道这轮任务会改哪些文件或目录。
- [ ] 我选择了合适权限：read-only 或 workspace-write/on-request。
- [ ] 我没有默认打开命令网络访问。
- [ ] 我写清了目标、上下文、约束和完成标准。
- [ ] 我要求 Codex 先计划，复杂任务不直接改。
- [ ] 我知道不满意时怎么局部回滚。
- [ ] 我会在结束后看 diff、跑验证、人工检查关键路径。

这张清单不需要每次都形式化填写。用熟以后，你会在脑子里自然过一遍。新手阶段建议真的复制到任务里，让 Codex 也一起遵守。

30-60 分钟练习

这一篇的练习是：跑完一轮“安全启动 -> 小修改 -> 验证 -> 回滚演练”。

1. 新建一个练习目录。
2. 初始化 Git。
3. 写一个 README 并提交初始 commit。
4. 用 read-only 让 Codex 只读检查目录和 Git 状态。
5. 切到 workspace-write/on-request，让 Codex 只改 README。
6. 看 git diff。
7. 如果满意，提交。
8. 如果不满意，先保存 patch，再用 git restore README.md 回滚。
9. 写一条复盘：这轮任务哪些地方应该写进 AGENTS.md。

你可以用这个记录模板：

## Codex 安全练习记录

- 日期：
- 项目目录：
- 当前分支：
- 开始前 Git 状态：
- 使用入口：
- 权限模式：
- 任务目标：
- Codex 修改文件：
- 验证方式：
- 是否需要回滚：
- 回滚命令或保留原因：
- 下次要写进 AGENTS.md 的规则：

这个练习跑完后，你会对 Codex 的“可控感”强很多。不是因为你学会了某个神奇命令，而是你知道它每一步在哪里发生、怎么停、怎么撤、怎么验收。

收藏清单

如果只收藏这一篇，记住这几条：

下一篇会讲“别急着写 Prompt：先让 Codex 读懂项目”。也就是在安全边界搭好以后，怎么让它真正理解项目结构、运行方式、约束和不确定问题。

参考资料

• OpenAI Codex docs
• OpenAI Codex manual
• OpenAI Agent approvals & security
• OpenAI Sandboxing
• OpenAI Codex CLI reference
• OpenAI Codex App Worktrees
• OpenAI Custom instructions with AGENTS.md
• OpenAI Codex best practices
• CodexGuide 学习路线
• bozhouDev/codex-orange-book