第一次安全使用 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 动手前先过一遍
权限选择速查表	知道 read-only、workspace-write、on-request、danger-full-access 该怎么选
回滚决策表	改坏后知道继续修、局部回滚、整轮回滚还是丢弃 worktree

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

1. 先记住四个护栏

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

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

护栏	你要回答的问题	没做好会怎样
目录边界	Codex 这次能看到、能改哪里	读太多无关文件，或者误改不该碰的目录
Git 基线	当前改动是谁的，起点在哪里	回滚时分不清用户改动和 Codex 改动
权限模式	它能不能写文件、跑命令、联网、越界	小任务变成大权限任务
回滚路径	失败后怎么撤销、保留或重来	改坏后只能靠记忆手动修

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

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

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

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

不建议的目录	原因
桌面	文件混杂，不像一个项目边界
下载目录	临时文件、安装包、个人资料太多
用户根目录	范围过大，隐私和误改风险都高
多项目大目录	Codex 很难判断哪个才是任务现场
公司核心仓库	新手阶段不适合把风险放大

更稳的选择是：

场景	推荐目录
第一次练习	新建一个空白练习目录
小项目修 bug	项目的 Git 根目录
monorepo 里的单个 app	只打开对应 package / app 目录，或者在 Prompt 里明确范围
博客写作	只让它看 drafts、content/blog、AGENTS.md 等必要目录
多方案尝试	App Worktree 或单独实验分支

一个实用判断是：

如果你不愿意对这个目录整体做 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

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

问题	为什么重要
当前有没有未提交改动	有的话，先分清这些改动是谁的
是否已经在正确分支	不要在 main 上随手做实验
是否有 staged 文件	staged 状态容易被误以为是 Codex 刚改的

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

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

选择	适合什么情况
先提交	你自己的改动已经完整，值得留下一个基线 commit
先 stash	改动还没准备好，但想暂时收起来
明确告知 Codex 不要碰	改动很少、范围清楚，你愿意人工盯着

比如你可以在 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

我的理解是：

参数	含义
workspace-write	可以在工作区内读写、运行常规命令
on-request	需要越界、联网或执行高风险动作时停下来问你

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

权限可以按这张表选：

模式	我会什么时候用	适合新手吗
read-only	只想让 Codex 读项目、解释代码、列计划	适合
workspace-write + on-request	常规本地开发、写文档、修小 bug、补测试	适合
workspace-write + never	无网络、无删除、无发布、目录可丢弃且验证充分的非交互任务	谨慎
danger-full-access	外部已经隔离好的临时环境，且你明确需要全权限	不建议新手

这里的 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 本地执行命令时，默认网络访问通常是关闭的。这个默认值很合理。

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

网络动作	风险
安装依赖	触发安装脚本，引入未知代码
拉取远程脚本	可能执行不可信内容
调用外部 API	可能发送项目内容或环境信息
访问私有服务	可能越过你原本没想打开的边界

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

类型	做法
查官方文档、搜索资料	优先让 Codex 用内置 web search 或你提供链接，不一定打开命令网络
项目命令必须联网	明确说明目的、域名、命令，并让它先请求批准

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

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

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

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

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

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

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

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

你要看	例子	判断
命令是什么	npm test、git diff、Remove-Item -Recurse	读命令意图
作用路径	当前项目、上级目录、用户目录	是否越界
是否联网	package manager、curl、远端 API	是否真的需要
是否破坏性	删除、重置、迁移、部署	是否可回滚

可以粗略分成三档：

档位	例子	处理
低风险	git status、npm test、npm run lint	通常可以批准
中风险	安装依赖、修改配置、访问网络	先看理由和范围
高风险	删除目录、重置 Git、改数据库、部署生产	默认拒绝或要求方案

我会特别警惕这些命令：

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 restore path/to/file
staged 了但不想提交	git restore --staged path/to/file
整轮改动都不要了	确认无用户改动后再考虑 git restore .
新增了很多未跟踪文件	先 git status，确认后再处理未跟踪文件
已经提交但不想保留	公开分支优先 git revert <commit>
App Worktree 里试错	不合入 Local，丢弃或归档这条尝试
Cloud 任务结果不好	不开 PR，或不合并 PR

注意，我这里故意没有把 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. 告诉我如果不满意怎么回滚。

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

步骤	你要做什么
开始前	看目录、看 Git、选权限
执行中	让 Codex 只改一个文件
执行后	看 diff、读 README、确认没有编造命令
不满意	用局部回滚撤掉 README 改动

如果这轮你跑顺了，再逐步尝试补测试、改小组件、修小 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 Local	先看 Git 面板和 diff；小任务可以 Local，大任务考虑 Worktree
App Worktree	适合多方案尝试；不满意就不要 handoff 到 Local
CLI	先 git status，再用 --sandbox workspace-write --ask-for-approval on-request
IDE Extension	明确 @file 和选区边界；跨文件任务切到 CLI/App 更稳
Web / Cloud	确认远端环境、setup script、测试命令；不要依赖本机未提交文件

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

我的用法是：

任务	我会怎么选
改一篇草稿	Local，改完看 diff
同一篇文章试两种结构	Worktree 或复制草稿
改博客发布脚本	新分支或 Worktree
修生产相关 bug	先 Cloud/分支/PR，再本地验证
涉及账号、密码、后台发布	浏览器操作前明确目标，完成后验证公开页

12. 常见误区

误区	问题	更稳的做法
“我只是让它看看，没风险”	看也可能涉及隐私和密钥	先选目录边界，不把敏感目录交进去
“Git 会帮我回滚，所以随便改”	没有基线时，Git 也救不了混乱现场	开始前看 status，必要时提交或 stash
“审批弹窗都点同意”	审批失去意义	看命令、路径、网络、破坏性
“全权限省时间”	省掉的是边界感	新手默认 read-only 或 workspace-write/on-request
“Codex 说完成了就完成了”	总结不是验收	看 diff、跑命令、手动检查
“改坏了就 reset hard”	容易抹掉用户改动	先保存 diff，再逐文件回滚

我自己的经验是：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 的“可控感”强很多。不是因为你学会了某个神奇命令，而是你知道它每一步在哪里发生、怎么停、怎么撤、怎么验收。

收藏清单

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

问题	做法
第一次用 Codex 选哪里	低风险目录或清晰 Git 项目
开始前跑什么	git status --short、git diff --stat、git diff
只想了解项目	read-only
常规本地修改	workspace-write + on-request
不清楚任务范围	先让 Codex 只读计划
审批前看什么	命令、路径、网络、破坏性
不满意怎么撤	先保存 diff，再局部回滚
什么不要新手直接用	danger-full-access、跳过审批、整仓 reset

下一篇会讲“别急着写 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