AUTONOMY
Goal 自主任务
长任务不用一句句盯着:/goal status 随时看进度,pause 与 resume 随时叫停或续上。
大多数终端助手是一问一答,Codex CLI 多了一层 Goal:你给一个目标,它拆成步骤、逐步执行、把过程和结果回报给你。代价是你必须先把「什么算完成」说清楚。目标写得含糊,它跑得越久偏得越远——手册因此把「什么样的目标适合交给 Goal」单列了一节,写目标这道功夫省不掉。
所以手册把审批与沙箱放在 Goal 之前讲。三种审批模式从每一步确认到全程自动,按任务风险切换;沙箱在各平台用的是系统自己的机制:macOS 走 Seatbelt,Linux 走 bubblewrap,Windows 用原生沙箱。默认它在沙箱里跑,越界要经你同意。
它也是四本里最贴近「多人共用一套规矩」的一本:config.toml 管个人偏好,requirements.toml 让管理员下发强制约束,Profiles 让同一台机器上不同项目走不同的模型与权限。团队要统一口径,这三章是关键。
WHAT IT DOES
八项能力,手册里各有专章:配在哪个文件、命令怎么写、边界怎么定。
AUTONOMY
长任务不用一句句盯着:/goal status 随时看进度,pause 与 resume 随时叫停或续上。
SANDBOX
macOS Seatbelt、Linux bubblewrap、Windows 原生沙箱,用的是系统自己的隔离机制。
APPROVAL
手册给了三种模式的对照表,说明各自放开了什么、还拦住什么,换一条命令就能切。
MODELS
OpenAI、Ollama、LM Studio、Bedrock 与自定义供应商,本地模型也能接。
CONFIG
五层配置从 CLI 参数排到系统默认,优先级列成一张表;项目级不能覆盖安全敏感字段。
PROFILES
把一整套模型、权限与供应商存成一个预设,换项目时切换一条命令。
MEMORY
按发现链合并多层项目约定,支持子目录 Override,跨会话自动提取项目知识。
SPEED
启动快、内存占用低,代码开源可审计——这是它相对同类工具最直接的差别。
THE COURSE
三级各有一套实验、一件可见产物和一张验收清单。做不完上一级的清单,就不要开始下一级。
STARTER3–4 小时
装好 Codex CLI、完成登录、在默认沙箱下跑通第一个任务,并能用自己的话说清 sandbox_mode 与 approval_policy 各自管什么。
前置一台 macOS 或 Linux 机器(官方 CLI 页给出的安装脚本面向 macOS 与 Linux;Windows 请按官方 CLI 页的 Windows 说明操作);一个可用于登录的 ChatGPT 账号,或官方支持的其它登录方式;会用 git 的基本命令。
curl -fsSL https://chatgpt.com/codex/install.sh | sh。同一条命令也用于升级。mkdir ~/codex-lab && cd ~/codex-lab && git init。codex。首次运行时选择 **Sign in with ChatGPT** 或其它可用登录方式。/status,记下当前会话的模型、沙箱模式与审批策略——后面每改一次配置都回来看这里验证。workspace-write,且网络访问默认关闭。写一个 hello.py,列出当前目录下所有 .md 文件的文件名,然后运行它。~/codex-lab 之外,或让它联网装一个包。观察它如何请求升级、你如何逐次批准。/permissions,看看「不问就能做的事」具体可以改成什么。git status 与 git diff,逐行核对它改了什么。做完你手上会多出~/codex-lab 里一个能独立跑通的 hello.py、一份 /status 的截图或抄录(含沙箱模式与审批策略)、一次越界请求的处理记录(它想做什么、你批了还是拒了)。
codex 能在终端直接启动,不是 command not found/status 能显示当前会话配置git diff 的改动范围与预期一致codex: command not foundpip install / npm install,一直失败danger-full-access,或者你批准过一次升级。回到 workspace-write,越界的事让它每次申请、你每次决定。sandbox_mode 管技术上能碰什么,approval_policy 管什么时候停下来问你。把 approval_policy 设成 never 并不会放宽沙箱边界,反过来也一样。安全默认的 workspace-write + 网络关闭是官方给的保守起点,第一天不要动它。看到升级请求先读清楚要执行的命令再决定——批准一次升级和永久放开边界是两件事,别为了图快把 approval_policy 直接改成 never。
ADVANCED6–8 小时(建议拆成两天)
用 AGENTS.md 把项目约定写下来,用分层 config.toml 与 profile 让不同项目走不同的边界,独立完成一次带代码审查的真实交付。
前置已完成入门级;有一个你有写权限的真实仓库;理解 sandbox_mode 与 approval_policy 的分工(入门级验收里那一条)。
/init 生成 AGENTS.md,写清构建命令、测试命令、命名与目录约定。AGENTS.md 与某个子目录的 AGENTS.md 各写一条互相冲突的规矩,然后进子目录开会话,验证「靠近当前目录的文件后出现、因而覆盖前面的」。AGENTS.override.md:同一目录下它比 AGENTS.md 先被检查,适合临时压过既有约定。project_doc_max_bytes(默认 32 KiB)就不再往后加,空文件会被跳过。写太长等于后面的白写。~/.codex/AGENTS.md(临时覆盖用 ~/.codex/AGENTS.override.md)。~/.codex/config.toml 里设 approval_policy 与 sandbox_mode。改完开新会话用 /status 验证生效。~/.codex/paranoid.config.toml,写 sandbox_mode = "read-only" 与 approval_policy = "untrusted",然后用 codex --profile paranoid 启动,/status 核对。.codex/config.toml。注意它只在受信任的项目里生效。--config → 项目 .codex/config.toml(从根往当前目录,最近的胜出)→ --profile 指定的 profile 文件 → 用户 ~/.codex/config.toml → 系统配置与内建默认。/review 针对未提交改动,或用 codex review 子命令;也可以指定某个提交或基线分支。做完你手上会多出仓库里的 AGENTS.md(根目录一份 + 至少一个子目录一份)与 .codex/config.toml;本机的 ~/.codex/config.toml 与一个 profile 文件;一次 /review 的输出记录,以及一个你审过的 PR。
/init 生成的 AGENTS.md 已按你的项目改写,不是模板原样codex --profile paranoid 启动后,/status 显示的是 read-only + untrusted.codex/config.toml 在受信任项目里确实生效(/status 验证过)/review 的输出,且你能说清哪几条采纳、哪几条不采纳及原因AGENTS.override.md → AGENTS.md → project_doc_fallback_filenames 里配的备选名。用了别的文件名又没配备选名,就是不会被读到。project_doc_max_bytes(默认 32 KiB)就停止追加。把长篇背景挪走,只留它每次都要遵守的硬规矩。.codex/config.toml 不生效--profile 想压过项目配置是压不过的,顺序反了。~/.codex/<名字>.config.toml,且必须用 codex --profile <名字> 显式选用,不会自动套用。安全AGENTS.md 是要提交给团队的,别把只对你成立的偏好写进去。配置分层里越靠上的越强,所以真正的安全边界不能只写在 ~/.codex/config.toml——那一层任何人都能自己改回来,硬约束要等精通级用 requirements.toml 下发。
MASTERY8–10 小时
用 codex exec 把 Codex 接进脚本与 CI,用子 Agent 与 MCP 扩展它的能力边界,并用 requirements.toml 给团队定下用户改不动的硬约束。
前置已完成进阶级;有一个可以改的 CI 流水线;能在一台机器上写 /etc/codex/ 下的文件(需要管理员权限);能找到公司里负责设备管理的人对一次话。
codex exec(简写 codex e)把一个任务写成可重复执行的命令,先在本地跑通,再放进脚本。codex resume 按 ID 接着上一次的交互式会话往下做。.codex/agents/(项目级)或 ~/.codex/agents/(个人级)放定义文件,必填三个字段——name(派发时引用的标识)、description(什么时候该用它)、developer_instructions(它的职责与行为)。/subagents 或 /agent 切换当前 Agent 线程,把审查、调研这类任务派出去。codex mcp 子命令管理服务器,会话里用 /mcp 查看。/goal:给它一个目标而不是一串指令,用 /goal pause 暂停、/goal resume 续上、/goal clear 清掉。注意它被官方标为实验特性,需要 goals 功能已启用,且目标文本有长度上限(约 4000 字符),更长的说明写进文件再让目标指向那个文件。codex cloud 浏览或执行云端会话,codex apply 把云端产生的 diff 落到本地仓库。requirements.toml):至少禁掉 approval_policy = "never" 与 sandbox_mode = "danger-full-access",再加一份 MCP 服务器允许清单。/etc/codex/requirements.toml,Windows 放 %ProgramData%\OpenAI\Codex\requirements.toml。软默认(用户可改)放 managed_config.toml:Linux/macOS 在 /etc/codex/managed_config.toml,Windows 与其它非 Unix 在 ~/.codex/managed_config.toml。approval_policy 改成 never,确认真的被挡下。没验过的约束不算约束。做完你手上会多出一个能在 CI 里跑的 codex exec 脚本、至少一个子 Agent 定义文件、一份 MCP 配置、一份 requirements.toml 草案与一份 managed_config.toml,以及一次「硬约束真的挡住了越权配置」的终端记录。
codex exec 能在没有人盯着的情况下跑完一个任务并给出结果codex resume 能接上之前的会话/mcp 里能看到你接的服务器requirements.toml 已放到正确路径,且反例验过:越权配置被挡下(有终端记录)requirements.toml 写了,用户还是能改成危险配置/etc/codex/,Windows 在 %ProgramData%\OpenAI\Codex\)。另外「省略的键保持不受约束」——你没写进去的东西不会被自动收紧,得逐条列出来。managed_config.toml 当成硬约束requirements.toml。两个文件放错,等于什么都没管住。codex exec 在 CI 里卡住不动/goal 找不到或不生效name 字段才是权威标识,文件名只是给人看的。派发时引用的是 name;description 写得含糊,它也不知道什么时候该轮到自己。安全这一级把 Codex 放进了无人值守的环境,所以每一条约束都必须配反例记录。requirements.toml 一旦下发用户改不动——先在一台机器上完整验证再铺开,否则全公司一起被卡住。云端会话与 codex apply 会把仓库之外产生的 diff 落到你本地,落之前要像审外部 PR 一样审一遍。
SYLLABUS
小节顺序就是学习顺序。四本用同一份目录,读完一本,第二本可以直接跳到你要的那一节。
OpenAI 的终端 Agent。它能在你的仓库里读文件、改文件、跑你机器上已经装好的工具,也能针对未提交改动、指定提交或基线分支单独做代码审查。它最有辨识度的地方是把边界拆成两个正交的开关:沙箱管「技术上能碰什么」,审批策略管「什么时候停下来问你」——这两件事在很多工具里是揉在一起的。
Codex 的安装本身不复杂,真正该在装之前想清楚的是两件事:这台机器上的沙箱走哪条路径,以及你打算用哪种方式登录。沙箱机制是随系统走的,装错平台后面绕不过去。
官方 CLI 页给出的安装命令,同一条既装也升级——不用记两条。装完之后不要急着开始干活,先用 /status 把当前的模型、沙箱模式与审批策略看清楚,这三个值是你后面每次改配置的对照基准。
第一个项目要达成的不是产出,是让你亲眼看到两个开关如何分工。所以任务本身要小,但必须包含一次「越界」——只有它请求升级、你做决定的那一刻,边界才变成你能感知的东西。
项目约定写在 AGENTS.md 里,Codex 在开工之前先读它。规则不复杂,但有三个细节决定它到底有没有被读到:文件名的检查顺序、多层合并的方向、以及总大小上限。
这一节是整本课程的核心。沙箱与审批是两个正交的开关:sandbox_mode 决定技术上能碰什么,approval_policy 决定什么时候停下来问你。把其中一个开到最松,另一个不会跟着松——这也意味着,只调一个是管不住的。
内建能力之外,外部系统走 MCP 接入,另有插件机制。管理员可以对可用的 MCP 服务器与插件市场来源下允许 / 阻断清单——这一点在选型阶段就该跟安全同事说清楚。
跨会话的项目知识靠 AGENTS.md;跨会话的对话线索靠 codex resume;单次会话里的上下文压力用 /compact 缓解。长任务另有一条实验路线:/goal——给目标而不是给指令。
子 Agent 用于把审查、调研这类任务从主线程里拆出去。定义文件只有三个必填字段,门槛很低;难的是把 description 写得足够具体,否则它不知道什么时候该轮到自己。
自动化的入口是 codex exec——非交互模式,可以写进脚本与 CI。但非交互意味着没人能批准升级请求,所以自动化的前提是先把沙箱与审批配到「不需要临时升级」的组合。顺序不能反。
排查顺序固定:先看 /status 里的三个值(模型、沙箱、审批)对不对,再看配置是从哪一层来的,最后才怀疑任务本身。多数「它不听话」的现象,追到底都是某一层配置压过了你以为在生效的那一层。
个人配置和团队约束是两回事。写在 ~/.codex/config.toml 里的东西,任何人都能自己改回来;真正改不动的硬约束要由管理员通过 requirements.toml 下发。这两个文件放错,等于什么都没管住。
入门级看的是你有没有建立「两个开关」的直觉,而不是任务做没做完。六条全部为真才算过。
进阶级验收的是配置层次的掌握程度。所有结论都要用 /status 验证过,不能只看配置文件推断。
精通级验收自动化与治理。判定标准比前两级严:每一条约束都要有对应的反例记录,没跑过反例的一律不算通过。
下面 cheatsheet 与 glossary 两个字段是这一节的正文。所有命令名、配置键与路径都在 2026-08-15 对过 OpenAI 官方文档;核不到出处的旧说法已经从这份速查里删掉,不做保留。
INSIDE THE MANUAL
从装环境到 Goal 模式,收尾一章对照 Claude Code。
装好、认证、跑出第一个结果
先把边界与配置定下来
把长任务交出去,再和同类工具对照一遍
14 道题,答对才解锁下一题:入门 5 题、进阶 5 题、精通 4 题。每题都给解析,答错能直接定位到对应章节。
WHERE TO START
先在最保守的审批模式下把它跑通,再决定要不要打开 Goal。
需要 Node.js 22 以上。执行 npm i -g @openai/codex,macOS 也可以用 Homebrew;手册另给了从源码与二进制安装的路径。
手册 · 第 2 章
用 ChatGPT 账号走 OAuth 登录(Plus / Pro / Team / Edu / Enterprise),或填 API Key。
手册 · 第 3 章
手册的第一个实战是让它写一个脚本并运行。观察审批与沙箱的实际行为,确认边界符合预期,再考虑放开 Goal。
手册 · 第 4 章
OPEN THE MANUAL
网页版手册,点开链接直接读,不用装任何东西。
NEXT STEP
带一个真实的业务问题来,我们和你的团队一起判断这些工具该落在哪一步。