Codex

高阶玩法

Codex CLI 进阶玩法 — AGENTS.md、配置 Profile、config.toml 进阶、MCP、非交互 exec、审批与沙箱、常见工作流。

把 Codex 用顺手,关键在配好审批策略、给足项目上下文,再把 Profile、MCP 和非交互模式利用起来。命令速查见 命令大全

#AGENTS.md 项目说明

在项目根放 AGENTS.md,Codex 会读取它了解项目约定,类似 Claude Code 的 CLAUDE.md

AGENTS.md
# 项目约定

技术栈:Python + FastAPI
包管理:uv(不要用 pip)

## 命令
- 启动:uv run uvicorn app:main
- 测试:uv run pytest

## 风格
- 类型注解必须写
- 改完跑 pytest 确认通过

AGENTS.md 也是分层的:~/.codex/AGENTS.md 放个人全局偏好,项目根的随仓库共享,子目录可放更细的约定。会话里用 /init 可快速生成初稿。

#config.toml 进阶

几个常用项(完整见 CLI 配置):

配置项作用
model默认模型,以模型广场实际可用为准
model_reasoning_effort推理强度:low / medium / high
approval_policy审批策略:on-request / on-failure / never
sandbox_mode沙箱:read-only / workspace-write / danger-full-access
web_search联网搜索:live 开启

启动时还能用 -c key=value 临时覆盖任意配置,例如 codex -c model_reasoning_effort=high,不必改文件。

#用 Profile 一键切换配置

把不同场景的配置打包成 Profile,用 --profile 切换,免去反复改 config.toml

~/.codex/config.toml
# 默认温和;另开一个高自由度 profile 给可信项目
[profiles.fast]
model = "gpt-5.6-sol"
model_reasoning_effort = "high"
approval_policy = "on-failure"
sandbox_mode = "workspace-write"
codex --profile fast "把这个模块补上测试"

#用 MCP 接入外部工具

通过 MCP(Model Context Protocol),Codex 能调用外部工具与数据源 —— 浏览器、数据库、内部 API 等。在 config.toml 里声明服务器即可:

~/.codex/config.toml
[mcp_servers.my-tool]
command = "npx"
args = ["-y", "@scope/my-mcp-server"]
# env = { API_KEY = "..." }

接好后会话里用 /mcp 查看可用工具与连接状态。

MCP 服务器会获得相应访问能力,只接入可信来源。

#非交互模式:脚本与 CI

codex exec 不进入 TUI,直接跑完退出,适合放进脚本、git hook 或 CI:

# 一次性任务
codex exec "修复 lint 报错并跑一遍测试"

# 配合管道:把 diff 交给它总结
git diff --staged | codex exec "用一句中文总结这些改动作为 commit message"

无人值守时务必配合收紧的审批 / 沙箱(如 --sandbox read-only 或限定 workspace-write),别直接全放开。

#审批与沙箱

Codex 的安全模型由 approval_policy + sandbox_mode 共同决定:

保守(推荐起步)approval_policy = on-request,每个有风险动作都问你。适合陌生项目。
高效(个人项目)放宽审批 + workspace-write,在项目目录内自由读写,出界才问。
全自动(谨慎)--dangerously-bypass-approvals-and-sandbox 完全放开,仅限可信 + 有 git 兜底的目录。

命令行也能临时指定:--full-auto 在工作区内自动读写;-a(--ask-for-approval)与 -s(--sandbox)分别覆盖审批与沙箱级别;-C <目录> 指定工作目录。

全自动模式不要在陌生仓库、生产目录或含密钥的目录使用。详见 安全说明

#常见工作流

1

让它先理解

codex "解释这个项目的结构和入口",确认它理解对了再继续。

2

描述目标、要计划

复杂改动先要方案。方案不对在这步纠正,成本最低。必要时用 /model 调高推理强度。

3

执行并自检

确认方案后让它动手,改完让它跑测试 / 构建。

4

git diff 复查

/diff 看改动,不满意就回滚重来。始终在版本控制下工作。

#接着看

Support / 支持

Need help? / 需要帮助?

接入、计费与模型异常可邮件联系;服务可用性以状态页为准。For setup, billing, or model issues, email us. Check the status page for uptime.

也可使用右下角微信 / QQ 客服 · WeChat / QQ support is available at the bottom right