文章

Codex CLI 极简配置：从 7 个真实痛点到一套够用的配置

发表于 15天前 更新于 最近
作者 Eric
53~69 分钟 阅读

见字如面，与大家分享实践中的经验与思考。

Codex 作为我的个人主力 Agent，已经用了很长一段时间。期间我研究过很多配置项，也反复改过好几个版本。最后发现：大多数配置其实用不上，真正解决问题的就那几行。

这篇文章会从我自己的痛点出发，整理一套够用、好维护的 Codex CLI 配置。

以下示例基于本机 codex-cli 0.136.0。Codex 配置仍在持续演进，正式使用前仍建议再对照一次最新文档。

images-20260605-00.32.50@2x

01 我遇到的 7 个痛点

#

痛点

具体表现

1

模型选择困难症

不知道选哪个模型，每次凭感觉手动切

2

审批太频繁

95% 以上都是同意，但每次都弹确认

3

跨 workspace 修改受限

跨多个项目复刻实现，频繁授权很烦

4

运行命令要审批

CLI 经常需要跑命令，每次都卡一下

5

Plan/Build 模式差异

不确定是否需要不同模型配置

6

Skills 加载路径

全局还是项目目录，怎么放最省事

7

Profile 管理复杂

多个场景要切换，感觉太麻烦

这些痛点都是我在长时间高频使用 Codex 的过程中一点点遇到的。不是一开始就想把配置做复杂，而是每遇到一个影响效率的问题，就补一处配置。

02 一套配置解决所有问题

最终配置

主要涉及两个文件：

1）config.toml 主配置文件：

# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"
plan_mode_reasoning_effort = "high"
approval_policy = "never"
sandbox_mode = "danger-full-access"
personality = "pragmatic"
​
[desktop]
preventSleepWhileRunning = true
ambient-suggestions-enabled = false

全量配置可以参考：https://developers.openai.com/codex/config-sample

2）控制外部命令的规则文件：

# ~/.codex/rules/default.rules
# File inspection
prefix_rule(pattern = ["ls"], decision = "allow")
prefix_rule(pattern = ["pwd"], decision = "allow")
prefix_rule(pattern = ["cat"], decision = "allow")
prefix_rule(pattern = ["head"], decision = "allow")
prefix_rule(pattern = ["tail"], decision = "allow")
prefix_rule(pattern = ["find"], decision = "allow")
prefix_rule(pattern = ["grep"], decision = "allow")
prefix_rule(pattern = ["rg"], decision = "allow")
​
# Gradle
prefix_rule(pattern = ["./gradlew", "build"], decision = "allow")
prefix_rule(pattern = ["./gradlew", "test"], decision = "allow")
prefix_rule(pattern = ["./gradlew", "clean"], decision = "allow")
prefix_rule(pattern = ["./gradlew", "check"], decision = "allow")
prefix_rule(pattern = ["./gradlew", "classes"], decision = "allow")
prefix_rule(pattern = ["./gradlew", "compileJava"], decision = "allow")
prefix_rule(pattern = ["./gradlew", "compileTestJava"], decision = "allow")
prefix_rule(pattern = ["./gradlew", "bootJar"], decision = "allow")
prefix_rule(pattern = ["./gradlew", "bootRun"], decision = "prompt")
​
# pnpm
prefix_rule(pattern = ["pnpm", "build"], decision = "allow")
prefix_rule(pattern = ["pnpm", "format"], decision = "allow")
prefix_rule(pattern = ["pnpm", "lint"], decision = "allow")
prefix_rule(pattern = ["pnpm", "test"], decision = "allow")
prefix_rule(pattern = ["pnpm", "install"], decision = "prompt")
prefix_rule(pattern = ["pnpm", "dev"], decision = "prompt")
​
# Git
prefix_rule(pattern = ["git", "status"], decision = "allow")
prefix_rule(pattern = ["git", "diff"], decision = "allow")
prefix_rule(pattern = ["git", "log"], decision = "allow")
prefix_rule(pattern = ["git", "branch"], decision = "allow")
prefix_rule(pattern = ["git", "show"], decision = "allow")
prefix_rule(pattern = ["git", "ls-files"], decision = "allow")
prefix_rule(pattern = ["git", "grep"], decision = "allow")
prefix_rule(pattern = ["git", "add"], decision = "allow")
prefix_rule(pattern = ["git", "commit"], decision = "prompt")
prefix_rule(pattern = ["git", "push"], decision = "prompt")
​
# Misc
prefix_rule(pattern = ["mkdir", "-p"], decision = "allow")
prefix_rule(pattern = ["curl", "-L"], decision = "prompt")
prefix_rule(pattern = ["rsync"], decision = "prompt")

逐条解释

痛点 1：模型选择困难 → 固定一个平衡模型

model = "gpt-5.5"
model_reasoning_effort = "medium"
plan_mode_reasoning_effort = "high"
personality = "pragmatic"

  • 日常用 gpt-5.5 + medium，够用，也比较省 token；如果任务明显复杂，再手动切到 high 或 xhigh

  • Plan 模式默认用 high，需要深度思考时自动切换到更高推理力度

  • 不用每次手动选，省心

  • personality 有三个选项：friendly、pragmatic、none。friendly 偏友好解释型，pragmatic 偏直接高效型，none 则是不附加 personality 指令。按需选择即可。

痛点 2：审批太频繁 → 直接关掉

approval_policy = "never"

  • 个人使用时，我更信任自己的操作边界，但是最好搭配 Git 使用

  • 95% 以上的确认最后都会点同意，不如直接放行

  • 也可以使用 on-request 模式，只在需要的时候弹确认，然后配置 defaults.rules 来使用。

痛点 3：跨 workspace 修改受限 → 完全访问权限

sandbox_mode = "danger-full-access"

  • 配合 --add-dir 可以跨目录操作，也可以直接贴其他项目的全路径

  • 想同步复刻实现时，不再卡授权

  • 官方建议：sandbox_mode = "workspace-write"，通过配置 writable_roots 来实现不同项目目录的授权修改。

痛点 4：运行命令要审批 → 用 rules 放行

参考上面的 ~/.codex/rules/default.rules 配置。我的思路是：大部分常用命令直接放行，少量重量级或有外部影响的命令保留确认。

自动允许：
- 常用文件操作
- Gradle 构建、测试、清理
- pnpm 构建、格式化
- Git 查看类命令
- git add
- mkdir -p
- curl -L
​
执行前确认：
- 后端服务启动：./gradlew bootRun
- 前端服务启动：pnpm dev
- git commit
- git push
- rsync

痛点 5：Plan/Build 模式差异 → 已解决

plan_mode_reasoning_effort = "high" 已经让 Plan 模式使用更高推理力度，Build 模式继续使用默认的 medium。

痛点 6：Skills 加载路径 → 两级管理

~/.codex/skills/          ← 全局通用 skills
项目/.codex/skills/        ← 项目专属 skills

  • 全局目录放通用工具，比如 skill-creator

  • 项目目录放专属规则，比如特定框架下的 to-specs、to-prd 等

痛点 7：Profile 管理复杂 → 不用 profile

结论：你不需要多个 profile。

理由很简单：

  1. 你的痛点是效率，不是场景隔离

  2. 用 never + danger-full-access 已经解决大部分问题

  3. Profile 更适合团队协作、CI/CD、敏感项目

  4. 个人使用，一套配置 + rules 就够了

03 配置优先级说明

Codex 的 config.toml 配置优先级可以按这个顺序理解：越上面优先级越高。

1. CLI 参数 / --config 覆盖
2. 项目级 .codex/config.toml
3. --profile 指定的 profile 配置文件
4. 用户级 ~/.codex/config.toml
5. 系统级 /etc/codex/config.toml (Unix 系统)
6. Codex 内置默认值

所以日常可以这样记：

临时一次性修改：用 CLI 参数 / -c
某个项目特殊配置：用 项目/.codex/config.toml
某种工作模式：用 --profile 对应的 profile 文件
个人默认配置：用 ~/.codex/config.toml
团队默认配置：用 /etc/codex/config.toml

04 什么场景才需要 Profile？

如果你未来遇到以下场景，再考虑加 Profile：

场景

配置建议

团队协作，需要统一行为

项目 .codex/config.toml

CI/CD 流水线

单独的 profile 文件

敏感项目，需要只读模式

readonly-audit.config.toml

深度审查，需要高推理力度

deep-review.config.toml

使用时可以这样指定：

codex --profile deep-review

05 桌面端配置

[desktop]
preventSleepWhileRunning = true
ambient-suggestions-enabled = false

启用 preventSleepWhileRunning，可以让 Codex 持续运行，尤其适合 /goal 命令。

如果你经常发现，每次启动 Codex Desktop 时，5 小时额度都会消耗 1% 到 3% 左右，可以考虑把 ambient-suggestions-enabled 关掉。

这个功能主要是在每次启动时，给聊天框下方自动生成任务建议。它需要调用 AI，所以会消耗一定额度。个人感觉它的价值不大，如果你不常用，关掉之后既能减少额度消耗，也可能让 App 启动更轻一点。

Codex Desktop ambient suggestions 设置示例

结语

真正的高效，不是让 AI 什么都能做，而是让它在正确的范围里持续稳定地做事。

我的建议很简单：

  • 固定一个平衡模型

  • 关掉审批（个人使用）

  • 给完全访问权限（跨 workspace）

  • 用 rules 放行常用命令

  • 不用 profile，一套配置够了

Codex 系列精选阅读

如果你对 OpenAI Codex Agent 感兴趣，可以浏览我的更多专题文章。

快速上手

欢迎关注公众号"Eric技术圈"，原创技术文章第一时间推送。

AI
Codex
许可协议:  CC BY 4.0