OpenAI Codex 不完全的伪新手指南

Published by rcdfrd on 2026-02-26

转载声明:本文转载自 loongphy 的博客,原文采用 CC BY-NC-SA 4.0 协议发布。

OpenAI Codex 不完全の伪新手指南

⚠️ 这并不是一篇零基础上手指南,需要您有一点点 Codex 使用经验。由于本人对于 官方仓库 所用 Rust 语言并不了解,所有信息均来自 PR 和 Issue 讨论,可能存在经验主义错误,如有事实偏差,还望指正。本文偏向于 Windows 的调教指南,如果这你都能看完,想必 MacOS/Linux 更能得心应手。

前言

基础配置 config.toml

💡 工欲善其事,必先利其器。对于 Codex 这个工具,强烈建议把配置文档看一遍 config.md

~/.codex/config.toml 中配置基础的 Codex:

model = "gpt-5-codex" # Codex 0.36.0 支持
model_reasoning_effort = "high" # 使用最大推理能力
model_reasoning_summary = "detailed" # 在终端显示详细的推理总结(ctrl+T查看)OpenAI 没有推理过程,只有推理总结
model_verbosity = "high" # 不懂,总之要拉满
model_supports_reasoning_summaries = true # 强制启用推理总结,针对于自定义 API KEY 的
hide_agent_reasoning = false # 允许显示更多的 AGENT 内部思考过程
disable_response_storage = true # 不允许 OpenAI 服务端存储你的对话
approval_policy = "never" # 配了但没用,总之先放着,建议通过 /approvals 配置
sandbox_mode = "workspace-write"

# 配了但没用,总之先放着,建议通过 /approvals 配置
# allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

命令

💡 codex --help 是一个好习惯

终端执行 codex 后进入,输入 / 你能得到目前支持的一些快捷命令。

/status

最常用的命令,用于检查当前的权限和 GPT-5 模型配置。如果你是自定义 API Key,更应该多使用该命令检查是否使用了正确模型。

/approvals

授予 Codex 权限,目前有三种,如果超出权限限制,就需要用户手动确认:

  • Read Only:默认权限,只能读取文件(实操下来限制太多,和 Agent Coding 自由理念相悖,一个任务可能要十多次手动批准。太麻烦)

  • Auto:读写,运行命令(实测一点也不 Auto,还是有太多手动批准)

  • Full Access:读写、使用网络工具(虽然官方一再声明小心操作,但这是我的日常使用的方式,真正的 Auto,整个过程不需要一次确认)

    个人倾向日常选用 Full Access,可以在每次运行 Codex 时添加额外的命令参数,无需每次重新选择权限:

codex --dangerously-bypass-approvals-and-sandbox

/mcp

Codex 目前仅支持 STDIO,若遇到仅支持 SSE 的 MCP Server,请查看下一章节。

如果你是 Windows 开发者,遵从 mcp_servers 一定会配置失败。通常进入 Codex 你会看到:

Program not foundrequest timed out

需要在原教程文档基础上增加如下:

  • 新增 command 指向具体的 npx 位置
  • 新增 env 包含 SYSTEMROOT
[mcp_servers.context7]
command = "C:\\Program Files\\nodejs\\npx.cmd"
args = [
  "-y",
  "@upstash/context7-mcp",
  "--api-key",
  "<your_api_key>"
]
env = { SYSTEMROOT = 'C:\Windows' }

MCP Server (SSE 方式)

在 WSL2 采用 MacOS/Linux 方式配置,访问 Windows 代码仓库时,也会出现 request timed out 问题。

此类问题通常是 Codex 没有正常读取环境导致的,可以借助 mcp-remote 通过切换到 SSE 的方式解决。

除此之外,还有些 MCP Server 仅支持 SSE,所以我们也需要采用这种方式,比如 deepwiki

⚠️ mcp-remote 是第三方作者开发,非 MCP 协议官方支持,需考虑风险。

分为两种方式,可以二者选其一。

全局安装

npm install -g mcp-remote

添加 SSE 的方式(需要 MCP Server 支持):

[mcp_servers.context7]
command = "mcp-remote"
args = [
  "https://mcp.context7.com/mcp",
  "--header",
  "CONTEXT7_API_KEY: <your-api-key>"
]

[mcp_servers.deepwiki]
command = "mcp-remote"
args = [ "https://mcp.deepwiki.com/sse" ]

npx

[mcp_servers.context7]
command = "npx"
args = [
  "mcp-remote",
  "https://mcp.context7.com/mcp",
  "--header",
  "CONTEXT7_API_KEY: <your-api-key>"
]

[mcp_servers.deepwiki]
command = "npx"
args = [
  "mcp-remote",
  "https://mcp.deepwiki.com/sse"
]

恢复/继续对话

💡 resume/continue 恢复对话功能仍然在开发中,所以 --help 中还没有增加对应的说明,但当前可用

与 Codex 的对话是保存在本地目录 ~/.codex/sessions 下的,我们可以执行如下命令来选择最近对话列表恢复,继续对话。

codex --resume

0.36 版本后废弃,continue 直接恢复上一次对话,无需选择:

codex continue

工具调用

为了最快、最准确的帮助 Codex 完成搜索,我们需要针对性的使用不同的工具。

不同的系统平台,Shell 工具也有所不同,本文主要聚焦于 Windows 平台,旨在引导 Codex 使用正确的命令和工具,减少错误重试、降低单次任务执行的时长。

Codex 支持在代码仓库根目录添加 AGENTS.md 文件来指导 Codex 在该仓库下遵守的规则,如:仓库技术栈、工具调用等。

目前主要使用三种:fd, ripgrep 和 ast-grep。

  • 按文件名找 → fd
  • 按文本内容找 → rg(ripgrep)
  • 按代码结构/语义找 → sg(ast-grep)

Windows 安装

从 codex v0.41 版本开始,ripgrep 已经被内置到 npm 包中,无需手动安装。

winget install sharkdp.fd ast-grep

WSL2(Debian)

apt install -y fd-find
npm i @ast-grep/cli -g

AGENTS.md

在实际操作过程中,发现只声明可用工具而不引导具体用法,经常会偏离预期,因此建议复制如下完整的配置,按需调整。

## Tool Priority

- Filename search: `fd`.
- Text/content search: `rg` (ripgrep).
- AST/structural search: `sg` (ast-grep) — preferred for code-aware queries (imports, call expressions, JSX/TSX nodes).

### AST-grep Usage (Windows)

- Announce intent and show the exact command before running complex patterns.
- Common queries:
  - Find imports from `node:path` (TypeScript/TSX):
    - `ast-grep -p "import $$ from 'node:path'" src --lang ts,tsx,mts,cts`
  - Find CommonJS requires of `node:path`:
    - `ast-grep -p "require('node:path')" src --lang js,cjs,mjs,ts,tsx`

### Search Hygiene (fd/rg/sg)

- Exclude bulky folders: `.git`, `node_modules`, `coverage`, `out`, `dist`.
- Examples:
  - `rg -n "pattern" -g "!{.git,node_modules,coverage,out,dist}" src`
  - `fd --hidden --exclude .git --exclude node_modules --type f ".tsx?$" src`

系统通知

Codex 支持在任务执行完成后执行自定义事件,我们可以利用这一特性实现 Windows 系统弹窗通知。

~/.codex/config.toml

notify = [
  "powershell.exe",
  "-NoProfile",
  "-ExecutionPolicy",
  "Bypass",
  "-File",
  "C:\\Users\\<username>\\.codex\\notify.ps1"
]

~/.codex/notify.ps1

param(
  [Parameter(Mandatory = $true)]
  [string]$json
)

# 解析 JSON(Codex 把一段 JSON 作为 argv[1] 传进来)
try {
  $payload = $json | ConvertFrom-Json
} catch {
  $payload = @{}
}

$title = 'Codex'
$msg = $payload.'last-assistant-message'
if (-not $msg) {
  if ($payload.type) {
    $msg = "Event: $($payload.type)"
  } else {
    $msg = 'Codex has an update.'
  }
}

# 可选:截断过长文本,注意只用 ASCII 的三点号,避免乱码
if ($msg -and $msg.Length -gt 240) {
  $msg = $msg.Substring(0,240) + '...'
}

# 只用 Toast,不要任何 Popup 兜底
Import-Module BurntToast -ErrorAction Stop
New-BurntToastNotification -Text $title, $msg | Out-Null

Codex Prompt 调试技巧

每次修改 AGENTS.md 后,多使用 ctrl+T 查看其思考过程,看看命令的调用、思考过程是否符合你的预期。若不符,直接与 Codex 对话询问该如何调整 AGENTS.md,多重复几轮一般都能得到比较满意的结果。

[开始]
  |
  v
[修改 AGENTS.md]
  |
  v
[Ctrl+T 查看当前思考过程/轨迹]
  |
  v
{是否符合你的预期?}
  |是                |否
  v                  v
[提交/应用变更]    [与 Codex 对话:询问如何调整]
                     |
                     v
                   [根据建议再次修改]
                     |
                     └──→ 回到 [Ctrl+T 查看]

Spec-kit(实验性)

模仿 spec-kit 建立了一套实现新功能的规范,包含三个流程:spec, plan 和 do。

还在尝试优化中,因此未利用 codex/prompts.md 方式注入指令,而是通过 AGENTS.md 来时刻调整测试,在对话时输入 /spec/plan/do 即可。

  • /spec 开头,输入你想要实现的功能,Codex 会自动在 specs 文件夹下生成一个 Markdown 文件

  • /plan 开头,Codex 会自动在 plans 文件夹下生成一个带有日期的 Markdown 文件

  • /do 会自动按照 plan 任务实现

    不必严格遵从上述三个顺序来执行,如果 spec 文件不符预期,完全可以继续多轮对话调整满意后,再输入 /plan 来引导生成 plan 文件。

WSL2

如果你在 Windows 下让 Codex 执行任务,你会发现它经常调用命令失败然后重试,如此循环。虽然最终都会成功,但浪费了很多时间,个人推测这是因为 GPT-5 Unix Shell 训练数据太多而 Powershell 数据太少导致的幻觉,Codex 总是下意识调用 Unix Shell 命令来处理。

那么有没有办法解决呢?当然有!打不过就加入——WSL2。

以 Windows 11 为例,在 Powershell 执行 wsl --install 即可安装 WSL2。

这种情况下,有两种方式选择:

  • Windows 端代码 + WSL2 Codex 环境:适用于开发 Windows 端的程序,比如 Electron Windows,.NET 等

  • WSL2 代码 + WSL2 Codex 环境:比如 Vue Web 开发

    对于后者,所有都能正常在 WSL2 环境内运行。而前者 Windows + WSL2 混用就需要解决一个问题:如何在 WSL2 调用 Windows 端的 npm/pnpm。

    在 WSL2 Codex 对话时,要求其调用 pwsh.exe 来执行 pnpm typecheck 来检查,如此即可:

we're in WSL2, please using pwsh.exe to run `pnpm <script>`

经验之谈

  • 主动让 Codex 调用特定工具:不要把所有的注意事项都写入到 AGENTS.md 中,用户还会需要担负一些心智针对不同的场景引导 Codex 使用更为合适的工具,比如用 git diff 可能更能提供准确的上下文。

  • 尽可能在对话时提供完整的信息来源:Codex 查找代码的方式非常原始,如 grep, ripgrep 等,很有可能搜不到你想要的内容。比如你想要询问为什么实例化了两次,请顺带给出两次出现的地方:函数、文件名等信息,能减少 Codex 的误判或者搜索代码的时间。Codex 提供了 @ 快捷命令来帮助你快速搜索文件名。

  • 网页搜索尽量使用网页端 ChatGPT-5-Thinking:搜索更快更完整,非常擅长对于 GitHub 项目的检索:包括不限于源码、项目结构、issue、PR 等。特别适合了解某个开源项目的功能,单独开一个长对话和 ChatGPT 聊聊,受益良多。

总结

AI 工具日新月异,一个新的工具崛起,不要妄想能三分钟上手掌握,也不要过于依赖他人的博客文档和结论,AI 工具千人千面,每个人都有各自的编程习惯,需要花几天慢慢了解工具特性和背后的大语言模型习惯,根据自己的需求和喜好来调教独属于自己的 AI 工具。

面对新兴事物,莫要故步自封在一个工具上吊死,保持好奇心,勇于探索未知的可能。

参考资料