本页要解决什么
第一次启动 Codex,最重要的不是马上提出一个大需求,而是先回答三个问题:- Codex 当前到底打开了哪个目录?
- 它可以读写哪些内容,哪些操作必须经过批准?
- 如果结果不对,我能不能明确地回到操作前?
codex --help 和子命令帮助为准。
先选择合适的项目
三种起点
根据任务风险,优先从下面三种起点中选择一种:
不要把包含客户数据、生产密钥、未备份成果或同事未提交改动的目录当作练习场。Codex 能读到工作区里的文件,不代表这些文件适合交给代理处理。
已有本地项目
先在终端确认目录,而不是凭窗口标题猜位置:git rev-parse --show-toplevel 应输出仓库根目录。若提示 not a git repository,说明当前目录不是 Git 仓库,先确认你是否进入了正确的目录,不要急着执行 git init。对已有项目擅自初始化 Git,可能制造错误的历史边界。
检查项目入口文件:
从远端克隆项目
克隆前先核对来源、协议和目标目录。示例使用公开 HTTPS 地址;真实项目请替换为已确认的仓库地址:less 时,可以用编辑器打开 README.md,或执行:
项目选择检查表
在启动 Codex 前逐项回答:- 目录路径是这次任务的目标目录。
- 远端 URL 与组织、项目名称一致。
- 当前账号有必要的访问权限,但不是不必要的管理员权限。
- 目录中没有必须保密的
.env、私钥、客户导出文件或生产数据。 - README 和构建文件已经读过,知道最小验证命令。
- Git 工作区状态已经记录,没有把别人的未提交改动误当成自己的。
信任边界:先决定 Codex 能做什么
工作区不是整台电脑
Codex 把当前项目目录当作工作区。workspace-write 通常允许它在工作区内修改文件和执行本地命令,但不会因此自动获得整台电脑的权限。它派生的测试、脚本和 Git 命令也受同一边界影响。
常见沙箱模式如下:
沙箱和审批是两件事。沙箱定义“能不能做”,审批策略定义“什么时候先问你”。日常可从
workspace-write 配合 on-request 开始;不要为了少几个提示就直接使用完全访问。
启动前确认模式
先查看可用选项:哪些动作必须停下来确认
下列动作不要仅凭 Codex 的一句“需要执行”就批准:
不确定时先拒绝,并要求 Codex 解释命令、路径、输入和预期副作用。批准一次命令,不等于批准后续所有命令。
Git 分支与初始检查点
为什么先建分支
main 或 master 通常是共享分支。修复、实验和 Codex 生成的功能应在独立分支进行,便于审查、比较和撤回:
switch,可使用:
test、tmp 这类无法辨认的名字。若工作区不干净,不要直接切换或创建分支前覆盖文件;先查看差异并确认这些改动属于谁。
在动手前保存检查点
确认工作区状态后建立一个清晰的提交:git log -1 应显示刚才的检查点。若项目不允许直接提交,至少保存补丁:
分支、工作区和 Worktree
一个普通工作区一次检出一个分支。同一分支不能同时在两个 Git worktree 中检出。需要并行任务时,优先使用桌面 App 的 Worktree,或先了解 Git 原生命令:../shop-codex-feature 两个工作树。两个目录拥有独立文件副本,但共享 Git 历史。不要让两个 Codex 线程同时改同一个目录;不要把同一个分支强行检出到两个工作树。
清理已经确认不再需要的 worktree:
.env、缓存和 node_modules 等被忽略文件通常不会随 Git 迁移;需要时用受控 setup 步骤重新生成,不要复制生产凭据。
AGENTS.md:让规则随项目生效
发现范围
Codex 会寻找项目说明文件AGENTS.md。常见层级如下:
AGENTS.override.md 和 AGENTS.md,通常优先使用前者作为该层文件。项目层从 Git 根目录逐级走到当前目录,每层选择一个适用文件;最终指导通常按从根到当前目录的顺序合并,越靠近当前目录的内容越具体,冲突时优先级越高。
AGENTS.override.md 只替代同一目录的常规说明,不会抹掉其他层级。它适合短期特殊规则,但容易被遗忘。查看当前项目实际有哪些文件:
怎么写才有用
项目根的AGENTS.md 应短小、可执行、经常更新。建议写:
~/.codex/AGENTS.md,不要把个人路径和凭据提交给团队。
验证 Codex 是否读到了规则
在项目根启动 Codex,先提出只读验证问题:- 确认当前目录在 Git 根目录下。
- 确认文件名大小写和扩展名正确。
- 检查文件是否为空或被
AGENTS.override.md替代。 - 检查是否通过
CODEX_HOME使用了另一套全局目录。 - 关闭并重新启动会话后再次验证。
.codex 与 ~/.codex 配置
这两个路径作用不同,不能混为一谈:
.codex 是否包含哪些文件,取决于 Codex 版本和桌面 App 功能。使用前先查看并阅读项目现有配置:
.codex 目录中。它可以用于新 worktree 创建后安装依赖或准备构建,但脚本仍然可能执行网络和任意项目命令,提交前必须审核。
用户级配置通常位于:
config.toml。先备份并查看帮助或官方文档:
.codex 适合可审查、可共享的项目设置;~/.codex 适合个人设置。两者都不应保存明文密钥。
workspace 与 read-only 的实际选择
推荐的切换顺序
对陌生仓库采用三步:read-only:读取说明、检查结构、让 Codex 出计划。workspace-write:只允许修改当前项目,执行小范围任务。- 需要联网或访问工作区外内容时:临时批准单个动作,完成后恢复限制。
用最小实验验证边界
在临时目录创建测试项目:workspace-write,该文件可能在工作区内被创建。再次测试后查看:
一次完整的工作区检查
启动 Codex 前,建议把下面命令保存为自己的检查清单:directory是任务目录,而不是用户主目录或桌面目录。root是你预期的 Git 根目录。- 当前分支是任务分支,不是无意间停留在共享分支。
git status的已有改动已经被识别和记录。git diff --check没有空白错误。- 能看到最近一次检查点提交。
- 能列出会影响当前目录的
AGENTS.md文件。
临时练习项目:第一次使用的默认选项
没有把握时,创建一个三行代码的练习项目:main.py 和 .git,工作区干净。先做只读任务:
main.py 发生预期修改,Python 编译检查成功。若 diff 包含其他文件,或者出现依赖、配置和删除操作,先停止并回滚,不要因为任务很小就跳过检查。
失败、回滚与恢复
未提交改动的回滚
先查看范围:git restore . 会丢弃已跟踪文件的所有未提交修改;git clean -nd 只是预览未跟踪文件。确认清单后,才考虑使用会删除未跟踪文件的命令。不要在同事可能正在使用的目录中执行批量回滚。
已提交改动的回滚
如果改动已经提交但还没有共享,先查看提交:不确定时保留证据
在回滚前保存:最终验收
在把项目交给下一步任务前,逐项确认:- Codex 从正确项目目录启动,路径已用命令验证。
- 当前分支是任务分支,或你明确批准在现有分支工作。
- 动手前已有 Git 提交或可用补丁检查点。
-
AGENTS.md的全局、仓库和子目录层级已检查,冲突规则已理解。 -
.codex与~/.codex的用途没有混淆,配置变更已备份并在重启后验证。 - 陌生项目先用过
read-only,实际修改只在必要时切到workspace-write。 - 没有把
.env、令牌、私钥、客户数据或缓存提交进 Git。 -
git diff --stat和git diff只显示预期文件。 -
git diff --check通过,且至少运行了一条项目规定的最小测试或构建命令。 - 失败时知道使用单文件
git restore、补丁或git revert的哪一种恢复方式。
本页小结
选择项目时先看来源和数据敏感度;进入项目后先看路径、Git 状态和说明文件;让 Codex 先在read-only 下建立认识,再在 workspace-write 下做小修改;用 AGENTS.md 固化项目规则,用 .codex 保存可审查的项目设置,用 ~/.codex 管理个人配置;每次重要操作前都留 Git 检查点。
最小可靠流程可以压缩为:
参考/codex/02-core-concepts.md、参考/codex/06-first-task.md、参考/codex/11-agents-md.md、参考/codex/25-worktrees.md。动态命令、参数和界面以本机 Codex 版本及官方文档为准。