汉兴人工智能OPEN CAIO启动企业 AI 诊断
启动企业 AI 诊断

MANUAL 02 · CODEX CLI

设定目标,然后放手让它跑

OpenAI 开源的终端 Agent,用 Rust 写成。分水岭功能是 Goal 模式:你描述要达到的结果,它自己拆解、执行、回报,而不是一句一句等你下指令。

出品
OpenAI 开源 · Rust 构建
手册
16 章,分入门 / 进阶 / 精通三段
自测
14 道闯关题,答对才解锁下一题
适合
想把长任务整段交出去的人

WHAT IT SOLVES

放手的前提是围栏

自主执行不是胆子大,是把边界先配好——手册的顺序也是这样排的。

大多数终端助手是一问一答,Codex CLI 多了一层 Goal:你给一个目标,它拆成步骤、逐步执行、把过程和结果回报给你。代价是你必须先把「什么算完成」说清楚。目标写得含糊,它跑得越久偏得越远——手册因此把「什么样的目标适合交给 Goal」单列了一节,写目标这道功夫省不掉。

所以手册把审批与沙箱放在 Goal 之前讲。三种审批模式从每一步确认到全程自动,按任务风险切换;沙箱在各平台用的是系统自己的机制:macOS 走 Seatbelt,Linux 走 bubblewrap,Windows 用原生沙箱。默认它在沙箱里跑,越界要经你同意。

它也是四本里最贴近「多人共用一套规矩」的一本:config.toml 管个人偏好,requirements.toml 让管理员下发强制约束,Profiles 让同一台机器上不同项目走不同的模型与权限。团队要统一口径,这三章是关键。

WHAT IT DOES

手册里讲透的八件事

八项能力,手册里各有专章:配在哪个文件、命令怎么写、边界怎么定。

AUTONOMY

Goal 自主任务

长任务不用一句句盯着:/goal status 随时看进度,pause 与 resume 随时叫停或续上。

SANDBOX

多级沙箱

macOS Seatbelt、Linux bubblewrap、Windows 原生沙箱,用的是系统自己的隔离机制。

APPROVAL

三种审批模式

手册给了三种模式的对照表,说明各自放开了什么、还拦住什么,换一条命令就能切。

MODELS

多模型接入

OpenAI、Ollama、LM Studio、Bedrock 与自定义供应商,本地模型也能接。

CONFIG

配置分层

五层配置从 CLI 参数排到系统默认,优先级列成一张表;项目级不能覆盖安全敏感字段。

PROFILES

Profiles 预设

把一整套模型、权限与供应商存成一个预设,换项目时切换一条命令。

MEMORY

AGENTS.md 记忆

按发现链合并多层项目约定,支持子目录 Override,跨会话自动提取项目知识。

SPEED

Rust 原生

启动快、内存占用低,代码开源可审计——这是它相对同类工具最直接的差别。

THE COURSE

从装好,到能带团队用

三级各有一套实验、一件可见产物和一张验收清单。做不完上一级的清单,就不要开始下一级。

STARTER3–4 小时

入门上手

装好 Codex CLI、完成登录、在默认沙箱下跑通第一个任务,并能用自己的话说清 sandbox_mode 与 approval_policy 各自管什么。

前置一台 macOS 或 Linux 机器(官方 CLI 页给出的安装脚本面向 macOS 与 Linux;Windows 请按官方 CLI 页的 Windows 说明操作);一个可用于登录的 ChatGPT 账号,或官方支持的其它登录方式;会用 git 的基本命令。

跟做实验

  1. 01装:curl -fsSL https://chatgpt.com/codex/install.sh | sh。同一条命令也用于升级。
  2. 02开一个干净的实验场:mkdir ~/codex-lab && cd ~/codex-lab && git init。
  3. 03在这个目录里跑 codex。首次运行时选择 **Sign in with ChatGPT** 或其它可用登录方式。
  4. 04输入 /status,记下当前会话的模型、沙箱模式与审批策略——后面每改一次配置都回来看这里验证。
  5. 05确认默认状态:沙箱是 workspace-write,且网络访问默认关闭。
  6. 06第一条任务原样输入:写一个 hello.py,列出当前目录下所有 .md 文件的文件名,然后运行它。
  7. 07做一次越界实验:让它把文件写到 ~/codex-lab 之外,或让它联网装一个包。观察它如何请求升级、你如何逐次批准。
  8. 08输入 /permissions,看看「不问就能做的事」具体可以改成什么。
  9. 09退出会话,跑 git status 与 git diff,逐行核对它改了什么。

做完你手上会多出~/codex-lab 里一个能独立跑通的 hello.py、一份 /status 的截图或抄录(含沙箱模式与审批策略)、一次越界请求的处理记录(它想做什么、你批了还是拒了)。

验收清单

  • codex 能在终端直接启动,不是 command not found
  • 登录完成,/status 能显示当前会话配置
  • 你能说出当前的 sandbox_mode 和 approval_policy 分别是什么值
  • hello.py 能在你自己的终端里独立跑通
  • 你至少经历过一次「它请求升级、你做决定」的完整过程
  • git diff 的改动范围与预期一致

常见错误

codex: command not found
安装脚本放二进制的目录不在 PATH 里。重开一次终端;仍不行就重跑一遍同一条安装命令——它同时承担安装、修复与升级三件事。
让它 pip 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 的分工(入门级验收里那一条)。

跟做实验

  1. 01在仓库根目录跑 /init 生成 AGENTS.md,写清构建命令、测试命令、命名与目录约定。
  2. 02做一次分层实验:根目录 AGENTS.md 与某个子目录的 AGENTS.md 各写一条互相冲突的规矩,然后进子目录开会话,验证「靠近当前目录的文件后出现、因而覆盖前面的」。
  3. 03试 AGENTS.override.md:同一目录下它比 AGENTS.md 先被检查,适合临时压过既有约定。
  4. 04注意上限:多份文件合并后达到 project_doc_max_bytes(默认 32 KiB)就不再往后加,空文件会被跳过。写太长等于后面的白写。
  5. 05全局约定放 ~/.codex/AGENTS.md(临时覆盖用 ~/.codex/AGENTS.override.md)。
  6. 06写个人默认:在 ~/.codex/config.toml 里设 approval_policy 与 sandbox_mode。改完开新会话用 /status 验证生效。
  7. 07做一个保守 profile:新建 ~/.codex/paranoid.config.toml,写 sandbox_mode = "read-only" 与 approval_policy = "untrusted",然后用 codex --profile paranoid 启动,/status 核对。
  8. 08做项目覆盖:在仓库里加 .codex/config.toml。注意它只在受信任的项目里生效。
  9. 09把优先级背下来(高到低):CLI 参数与 --config → 项目 .codex/config.toml(从根往当前目录,最近的胜出)→ --profile 指定的 profile 文件 → 用户 ~/.codex/config.toml → 系统配置与内建默认。
  10. 10跑一次代码审查:/review 针对未提交改动,或用 codex review 子命令;也可以指定某个提交或基线分支。
  11. 11自己 review 一遍它的审查意见,采纳该采纳的,提交,开 PR。

做完你手上会多出仓库里的 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.md 写了,它像没看见
先确认文件名和位置:同一目录下的检查顺序是 AGENTS.override.md → AGENTS.md → project_doc_fallback_filenames 里配的备选名。用了别的文件名又没配备选名,就是不会被读到。
多层 AGENTS.md 里,父目录的规矩赢了
合并方式是从根往下拼接、用空行连起来,越靠后越有分量。想让子目录赢,规矩就得写在子目录那一份里,而不是在父目录里写「子目录例外」。
AGENTS.md 后半截像被吃掉了
合并后的总大小到了 project_doc_max_bytes(默认 32 KiB)就停止追加。把长篇背景挪走,只留它每次都要遵守的硬规矩。
.codex/config.toml 不生效
项目级配置只在受信任的项目里生效。另外要记住它排在 CLI 参数之下、profile 之上——用 --profile 想压过项目配置是压不过的,顺序反了。
profile 建好了但没用上
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/ 下的文件(需要管理员权限);能找到公司里负责设备管理的人对一次话。

跟做实验

  1. 01非交互跑一次:codex exec(简写 codex e)把一个任务写成可重复执行的命令,先在本地跑通,再放进脚本。
  2. 02续会话:codex resume 按 ID 接着上一次的交互式会话往下做。
  3. 03建一个子 Agent:在 .codex/agents/(项目级)或 ~/.codex/agents/(个人级)放定义文件,必填三个字段——name(派发时引用的标识)、description(什么时候该用它)、developer_instructions(它的职责与行为)。
  4. 04在会话里用 /subagents 或 /agent 切换当前 Agent 线程,把审查、调研这类任务派出去。
  5. 05接 MCP:用 codex mcp 子命令管理服务器,会话里用 /mcp 查看。
  6. 06试实验特性 /goal:给它一个目标而不是一串指令,用 /goal pause 暂停、/goal resume 续上、/goal clear 清掉。注意它被官方标为实验特性,需要 goals 功能已启用,且目标文本有长度上限(约 4000 字符),更长的说明写进文件再让目标指向那个文件。
  7. 07如果用云端:codex cloud 浏览或执行云端会话,codex apply 把云端产生的 diff 落到本地仓库。
  8. 08写团队硬约束草案(requirements.toml):至少禁掉 approval_policy = "never" 与 sandbox_mode = "danger-full-access",再加一份 MCP 服务器允许清单。
  9. 09放到位:Unix(含 Linux 与 macOS)放 /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。
  10. 10**跑反例**:在那台机器上试着把 approval_policy 改成 never,确认真的被挡下。没验过的约束不算约束。

做完你手上会多出一个能在 CI 里跑的 codex exec 脚本、至少一个子 Agent 定义文件、一份 MCP 配置、一份 requirements.toml 草案与一份 managed_config.toml,以及一次「硬约束真的挡住了越权配置」的终端记录。

验收清单

  • codex exec 能在没有人盯着的情况下跑完一个任务并给出结果
  • codex resume 能接上之前的会话
  • 子 Agent 定义文件三个必填字段齐全,且能被派发到
  • /mcp 里能看到你接的服务器
  • requirements.toml 已放到正确路径,且反例验过:越权配置被挡下(有终端记录)
  • 你能说清 requirements 与 managed defaults 的区别——前者用户改不动,后者只是启动时的初始值
  • 你能说出 requirements.toml 里未写的键会怎样(答案:不受约束)

常见错误

requirements.toml 写了,用户还是能改成危险配置
先确认路径对不对(Unix 在 /etc/codex/,Windows 在 %ProgramData%\OpenAI\Codex\)。另外「省略的键保持不受约束」——你没写进去的东西不会被自动收紧,得逐条列出来。
把 managed_config.toml 当成硬约束
它是「托管默认值」,是启动时的初始值,会话里可以被改回来。真正改不动的是 requirements.toml。两个文件放错,等于什么都没管住。
codex exec 在 CI 里卡住不动
非交互环境下没人能批准升级请求。要么把审批策略和沙箱预先配到不需要升级的组合,要么把需要越界的步骤(装依赖、访问网络)拆到 Codex 之外先做完。
/goal 找不到或不生效
它是官方标注的实验特性,需要 goals 功能已启用。另外目标文本有长度上限,超了就写进文件、让目标指向那个文件。
子 Agent 定义写了但派不过去
name 字段才是权威标识,文件名只是给人看的。派发时引用的是 name;description 写得含糊,它也不知道什么时候该轮到自己。
以为把边界交给管理员之后就不用管了
requirements.toml 能约束的键是有清单的(审批策略、审查策略、沙箱模式、权限 profile、联网要求、MCP 允许与阻断清单、插件市场来源、命令规则与文件系统权限等)。清单之外的行为约束只能靠 AGENTS.md 和流程,别把两者混为一谈。

安全这一级把 Codex 放进了无人值守的环境,所以每一条约束都必须配反例记录。requirements.toml 一旦下发用户改不动——先在一台机器上完整验证再铺开,否则全公司一起被卡住。云端会话与 codex apply 会把仓库之外产生的 diff 落到你本地,落之前要像审外部 PR 一样审一遍。

SYLLABUS

十六节,四本课程同一套骨架

小节顺序就是学习顺序。四本用同一份目录,读完一本,第二本可以直接跳到你要的那一节。

  1. 01

    这是什么,适合谁

    OpenAI 的终端 Agent。它能在你的仓库里读文件、改文件、跑你机器上已经装好的工具,也能针对未提交改动、指定提交或基线分支单独做代码审查。它最有辨识度的地方是把边界拆成两个正交的开关:沙箱管「技术上能碰什么」,审批策略管「什么时候停下来问你」——这两件事在很多工具里是揉在一起的。

  2. 02

    安装前检查

    Codex 的安装本身不复杂,真正该在装之前想清楚的是两件事:这台机器上的沙箱走哪条路径,以及你打算用哪种方式登录。沙箱机制是随系统走的,装错平台后面绕不过去。

  3. 03

    第一次成功运行

    官方 CLI 页给出的安装命令,同一条既装也升级——不用记两条。装完之后不要急着开始干活,先用 /status 把当前的模型、沙箱模式与审批策略看清楚,这三个值是你后面每次改配置的对照基准。

  4. 04

    入门项目

    第一个项目要达成的不是产出,是让你亲眼看到两个开关如何分工。所以任务本身要小,但必须包含一次「越界」——只有它请求升级、你做决定的那一刻,边界才变成你能感知的东西。

  5. 05

    项目规则与上下文

    项目约定写在 AGENTS.md 里,Codex 在开工之前先读它。规则不复杂,但有三个细节决定它到底有没有被读到:文件名的检查顺序、多层合并的方向、以及总大小上限。

  6. 06

    权限、安全与审批

    这一节是整本课程的核心。沙箱与审批是两个正交的开关:sandbox_mode 决定技术上能碰什么,approval_policy 决定什么时候停下来问你。把其中一个开到最松,另一个不会跟着松——这也意味着,只调一个是管不住的。

  7. 07

    文件、工具与外部系统

    内建能力之外,外部系统走 MCP 接入,另有插件机制。管理员可以对可用的 MCP 服务器与插件市场来源下允许 / 阻断清单——这一点在选型阶段就该跟安全同事说清楚。

  8. 08

    记忆与长期任务

    跨会话的项目知识靠 AGENTS.md;跨会话的对话线索靠 codex resume;单次会话里的上下文压力用 /compact 缓解。长任务另有一条实验路线:/goal——给目标而不是给指令。

  9. 09

    多 Agent 协作

    子 Agent 用于把审查、调研这类任务从主线程里拆出去。定义文件只有三个必填字段,门槛很低;难的是把 description 写得足够具体,否则它不知道什么时候该轮到自己。

  10. 10

    自动化和团队使用

    自动化的入口是 codex exec——非交互模式,可以写进脚本与 CI。但非交互意味着没人能批准升级请求,所以自动化的前提是先把沙箱与审批配到「不需要临时升级」的组合。顺序不能反。

  11. 11

    调试与高频故障

    排查顺序固定:先看 /status 里的三个值(模型、沙箱、审批)对不对,再看配置是从哪一层来的,最后才怀疑任务本身。多数「它不听话」的现象,追到底都是某一层配置压过了你以为在生效的那一层。

  12. 12

    生产使用边界

    个人配置和团队约束是两回事。写在 ~/.codex/config.toml 里的东西,任何人都能自己改回来;真正改不动的硬约束要由管理员通过 requirements.toml 下发。这两个文件放错,等于什么都没管住。

  13. 13

    入门项目验收

    入门级看的是你有没有建立「两个开关」的直觉,而不是任务做没做完。六条全部为真才算过。

  14. 14

    进阶项目验收

    进阶级验收的是配置层次的掌握程度。所有结论都要用 /status 验证过,不能只看配置文件推断。

  15. 15

    精通项目验收

    精通级验收自动化与治理。判定标准比前两级严:每一条约束都要有对应的反例记录,没跑过反例的一律不算通过。

  16. 16

    速查卡与术语表

    下面 cheatsheet 与 glossary 两个字段是这一节的正文。所有命令名、配置键与路径都在 2026-08-15 对过 OpenAI 官方文档;核不到出处的旧说法已经从这份速查里删掉,不做保留。

INSIDE THE MANUAL

16 章,分三段推进

从装环境到 Goal 模式,收尾一章对照 Claude Code。

入门

装好、认证、跑出第一个结果

  1. 01什么是 Codex CLI
  2. 02安装与环境准备
  3. 03认证配置
  4. 04第一次使用
  5. 05排错速查

进阶

先把边界与配置定下来

  1. 01审批模式与沙箱
  2. 02config.toml 配置详解
  3. 03自定义模型供应商
  4. 04Profiles 配置预设
  5. 05AGENTS.md 项目记忆

精通

把长任务交出去,再和同类工具对照一遍

  1. 0135+ 斜杠命令速查
  2. 02Goal 模式
  3. 03高级功能 · MCP / 子代理 / Skills / 记忆
  4. 04实用技巧与快捷键
  5. 05最佳实践
  6. 06与 Claude Code 的对照

答题闯关

14 道题,答对才解锁下一题:入门 5 题、进阶 5 题、精通 4 题。每题都给解析,答错能直接定位到对应章节。

WHERE TO START

第一天做这三件事

先在最保守的审批模式下把它跑通,再决定要不要打开 Goal。

01

装环境

需要 Node.js 22 以上。执行 npm i -g @openai/codex,macOS 也可以用 Homebrew;手册另给了从源码与二进制安装的路径。

手册 · 第 2 章

02

接上账号

用 ChatGPT 账号走 OAuth 登录(Plus / Pro / Team / Edu / Enterprise),或填 API Key。

手册 · 第 3 章

03

先看它怎么问

手册的第一个实战是让它写一个脚本并运行。观察审批与沙箱的实际行为,确认边界符合预期,再考虑放开 Goal。

手册 · 第 4 章

NEXT STEP

手册解决怎么用,现场解决用在哪

带一个真实的业务问题来,我们和你的团队一起判断这些工具该落在哪一步。