Codex APP实战教程：从配置中转到多任务并行

Codex APP实战教程：从配置中转到多任务并行

01｜直接登录 or 配置 API Key

chatGpt官网下载安装包，安装后可以采用chatGPT账号登录或者apikey登录。这里介绍如何配置中转站的apikey。 697

第一步：准备 API Key

自己选一个中转站，复制好其api和key

第二步：创建 Codex 配置目录

Codex Desktop 的配置文件放在用户主目录下的 .codex 文件夹里。

Windows 路径：

text
C:\Users\<你的用户名>\.codex\
  1. 如果看不到 .codex 目录，先开启“显示隐藏的项目”
  2. 如果没有 .codex 文件夹，就手动创建一个

macOS 路径：

text
/Users/<你的用户名>/.codex/

主要是修改这两个文件：

text
auth.json
config.toml
代码

Windows 用户可以这样操作：

1. 在 `.codex` 文件夹里创建 `auth.json` 和 `config.toml`

macOS 用户可以打开终端，执行：

```bash
mkdir -p ~/.codex
touch ~/.codex/auth.json
touch ~/.codex/config.toml

第三步：编辑 auth.json

打开 auth.json，写入下面内容：

json
{"OPENAI_API_KEY": "sk-xxx"}

把里面的 sk-xxx 替换成你自己的 API Key。

第四步：编辑 config.toml

打开 config.toml，写入下面内容：

toml
model_provider = "api111"
model = "gpt-5.4"
model_reasoning_effort = "high"
disable_response_storage = true
preferred_auth_method = "apikey"

[model_providers.api111]
name = "api111"
base_url = "https://xxxxx.cn/codex"
wire_api = "responses"

简单解释一下这几项：

  • model_provider：自定义模型提供商名称，需要和下面的 [model_providers.api111] 对应
  • model：使用的模型名称，比如 gpt-5.3-codex、gpt-5.4
  • model_reasoning_effort：模型思考强度，可选 high、medium、low
  • disable_response_storage：禁用响应存储，建议开启
  • preferred_auth_method：认证方式，使用 API Key 时设为 apikey
  • base_url：中转站的 Codex API 地址
  • wire_api：API 协议格式，这里使用 responses

如果你想切换到 gpt-5.5，只需要把这一行：

toml
model = "gpt-5.4"

改成：

toml
model = "gpt-5.5"

第五步：重启应用并验证

配置完成后，重新打开 Codex Desktop。

注意：直接点击右上角关闭是不会关闭的，必须在后台杀死codex app

先输入一句最简单的测试内容：

text
hello

如果 Codex 能正常回复，说明 API Key 和配置文件已经生效。

到这里，Codex Desktop 就算跑起来了。后面再继续配置项目目录、权限策略、MCP、插件和自动化任务，会顺很多。

02｜把界面切换成中文

安装完成后，第一次打开 Codex Desktop，默认界面一般是英文。

如果你更习惯中文界面，可以先把应用语言切过来。这个设置不影响模型能力，只是把客户端菜单和界面文案改成中文，用起来会更顺手。

操作路径如下：

text
Codex Desktop → File → Settings → General → Language for the app UI

在语言选项里选择：

text
Chinese (China)

正常情况下，选择后界面会自动切换。

如果没有立刻生效，也不用急。比较常见的原因是语言包还没下载好，可以按下面顺序处理：

  1. 确保当前网络通畅
  2. 重新切换一次语言
  3. 重启 Codex Desktop

这个问题挺常见。很多时候不是设置没成功，而是语言包没有正常拉下来。重启之后再看，一般就能恢复正常。

03｜基础使用：先理解“项目”和“对话”

Codex Desktop 和普通聊天软件最大的区别，是它不是只围绕一段聊天记录工作，而是围绕一个本地项目工作。

你可以把它理解成两层结构：

  • 项目：Codex 当前能看到、能操作的工作目录
  • 对话：你围绕某个具体任务，和 Codex 展开的一次协作过程

项目决定了 Codex 在哪里工作，对话决定了 Codex 正在帮你做哪件事。

项目是什么

项目通常就是你本机上的一个文件夹。

比如：

text
D:\workspace\my-app

或者：

text
/Users/you/workspace/my-app

当你在 Codex Desktop 里打开这个目录后，Codex 才能基于这个项目读取目录结构、查看文件、分析代码、运行命令，甚至在你允许的情况下修改文件。

所以，使用 Codex 的第一步不是直接开始聊天，而是先确认：

  • 当前打开的是哪个项目
  • 这个项目是不是你真正想让 Codex 操作的目录
  • 这个目录里有没有不希望 AI 接触的敏感文件

如果项目选错了，后面对话再怎么写都容易跑偏。项目选对了，Codex 才能真正进入工作状态。

对话是什么

对话可以理解成一次任务会话。

比如你可以为这些事情分别开不同的对话：

  • 让 Codex 熟悉项目结构
  • 修复一个具体 bug
  • 给某个模块补测试
  • 重构一个页面
  • 解释一段你看不懂的代码
  • 帮你写一份技术方案

建议不要把所有事情都塞进同一个对话里。

更好的习惯是：一个明确任务开一个新对话。这样上下文更干净，后面回看、搜索、归档也更容易。

项目和对话的关系

一个项目下面可以有很多个对话。

你可以把项目理解成一个工作台，把对话理解成工作台上的一张张任务单。

例如，同一个前端项目里，可以同时存在这些对话：

text
项目：my-admin
├─ 对话 1：梳理项目目录结构
├─ 对话 2：修复登录页报错
├─ 对话 3：优化表格分页体验
├─ 对话 4：补充 Vitest 单元测试
└─ 对话 5：整理部署文档

这些对话都属于同一个项目，但它们的任务目标不同、上下文不同、产出的修改也可能不同。

这也是 Codex Desktop 比普通网页聊天更适合做工程任务的原因：它不是孤立地回答问题，而是在一个真实项目里持续协作。

对话状态：看清任务进行到哪一步

在 Codex Desktop 里，对话通常会有不同状态。

你可以重点关注几类：

  • 正在进行：Codex 还在阅读文件、运行命令或生成修改
  • 等待你确认：Codex 需要你批准某个操作，或者需要你补充信息
  • 已完成：当前任务已经结束，可以查看结果
  • 出错或中断：命令失败、权限不足、网络异常，或者任务被打断

对新手来说，最重要的是不要只盯着聊天正文，也要看状态提示。

如果 Codex 停住了，先判断它是在等你确认，还是任务真的失败了。很多时候并不是“卡死”，而是它在等你允许下一步操作。

对话归类：把任务按主题放好

当你用得多了，一个项目里很快会堆出很多对话。

这时候建议按任务类型做归类，至少在命名上保持清楚。

比如：

text
[理解项目] 梳理目录结构和启动方式
[Bug 修复] 登录页按钮无响应
[测试] 给 user-service 补单元测试
[重构] 拆分订单详情页组件
[文档] 整理部署说明

这样的好处是，后面搜索和回看时，一眼就能知道这个对话是干什么的。

尤其是公众号读者刚开始用 Codex，很容易把它当成“随手问一句”的聊天工具。其实只要稍微重视命名和归类，它就会更像一个可追踪的工程协作记录。

对话归档：完成的任务及时收起来

任务完成后，可以把不再需要频繁查看的对话归档。

归档不是删除。

它更像是把已经完成的任务从当前列表里收起来，让工作区保持清爽。以后需要回看时，仍然可以从归档里找到。

建议归档这几类对话：

  • 已经完成并确认没有问题的任务
  • 临时探索类对话
  • 重复创建、但已经不用的对话
  • 阶段性总结完成后的旧会话

如果某个对话后面还会继续推进，就先不要急着归档。

对话搜索：把 Codex 当成工程记录来用

当对话多起来后，搜索会非常重要。

你可以通过关键词找回历史任务，比如：

text
登录
测试
部署
权限
MCP
package.json

也可以搜索具体文件名：

text
Login.tsx
auth.ts
vite.config.ts
README.md

这时候前面提到的命名习惯就很有用了。对话标题越清楚，后面越容易搜索。

所以基础使用阶段，建议先养成三个习惯：

  1. 先选对项目，再开始对话
  2. 一个任务开一个对话
  3. 对话完成后及时归档，必要时用关键词搜索找回

把这套关系理解清楚后，再去学怎么让 Codex 读代码、改代码、跑测试，就会顺很多。

04｜权限控制：让 Codex 能干活，但别失控

理解完项目和对话之后，下一步要看权限控制。

这是 Codex Desktop 和普通 AI 聊天工具非常不一样的地方：它不只是回答问题，还可能读取文件、修改代码、运行命令、启动测试，甚至访问网络。

所以在正式让它干活之前，必须先知道一件事：

Codex 到底能做什么，不能做什么，什么时候需要先问你。

权限控制主要看两层

官方文档里把权限控制拆成两个核心概念：

  • sandbox_mode：沙箱模式，决定 Codex 在技术上能碰到哪里、能不能写文件、能不能访问网络
  • approval_policy：审批策略，决定 Codex 什么时候必须停下来问你

简单说：

sandbox_mode 管边界，approval_policy 管确认。

比如，沙箱规定 Codex 只能在当前项目里写文件；如果它想改项目外的文件，就会触发审批策略，让你确认是否允许。

在 Codex Desktop 里怎么切换权限

在 Codex Desktop 里，权限入口通常在输入框附近，也就是对话编辑器下方或旁边的 permissions selector。

官方文档里提到，App 和 IDE 都可以通过这个权限选择器切换模式：

  • Default permissions
  • Full access
  • Custom config.toml

对新手来说，先记住这三个就够了。

Default permissions：默认推荐

刚开始使用时，建议优先使用默认权限。

默认模式的思路是：让 Codex 在当前项目范围内完成常规任务，比如读文件、改项目内代码、运行本地命令；一旦它要越过边界，比如访问网络、修改项目外文件、执行更高风险操作，就停下来问你。

这个模式比较适合大多数日常开发：

  • 让 Codex 熟悉项目
  • 修改一个普通 bug
  • 补测试
  • 调整页面样式
  • 运行项目里的测试命令

它的好处是，不会每一步都打断你，也不会一上来把机器完全交出去。

Full access：只在你明确知道后果时使用

Full access 可以理解成“放开限制”。

官方文档里对应的是：

toml
sandbox_mode = "danger-full-access"
approval_policy = "never"

这个组合意味着 Codex 基本不会被沙箱限制，也不会频繁停下来等你确认。

它适合非常明确、非常信任的场景，比如你在一个临时项目、测试环境、隔离目录里，让 Codex 快速完成大量机械工作。

但不建议新手一开始就用 Full access。

尤其是下面这些项目，更不建议直接开满权限：

  • 公司生产项目
  • 有真实用户数据的项目
  • 放了密钥、证书、账号配置的项目
  • 目录层级很复杂、你自己也没完全确认边界的项目

Full access 不是不能用，而是要等你知道自己在放开什么。

Custom：用 config.toml 自定义权限

如果你希望 Codex 每次启动都按固定规则工作，可以在 config.toml 里配置默认权限。

官方文档里提到，常见的沙箱模式有三种：

toml
sandbox_mode = "read-only"

read-only 表示 Codex 可以查看文件，但不能随便编辑文件或运行需要权限的命令。适合只想让它分析项目、解释代码、做方案评审的时候。

toml
sandbox_mode = "workspace-write"

workspace-write 表示 Codex 可以在当前工作区内读写文件，并运行常规本地命令。这是本地开发里比较常用、也比较平衡的模式。

toml
sandbox_mode = "danger-full-access"

danger-full-access 表示不再使用沙箱限制。这个模式风险最高，只适合你明确需要完全放开权限的场景。

审批策略也常见三种：

toml
approval_policy = "untrusted"

不在可信集合里的命令会先询问。

toml
approval_policy = "on-request"

Codex 默认在沙箱内工作，需要越界时再询问。这是比较适合日常使用的选择。

toml
approval_policy = "never"

Codex 不再停下来弹出审批。这个模式效率高，但风险也更高。

一个适合新手的推荐配置

如果你希望 Codex 能正常改当前项目，又不想完全放开权限，可以使用这个组合：

toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"

它的含义是：

  • 当前项目内的常规操作，Codex 可以自己完成
  • 超出工作区的操作，需要先问你
  • 需要网络或更高风险的命令，需要先确认

这也是我比较建议新手长期使用的模式。

网络访问默认是关闭的

官方文档里还有一个非常重要的点：本地 Codex 默认不会给命令开放网络访问。

也就是说，Codex 在运行本地命令时，默认不能随便联网拉依赖、请求接口或访问外部服务。

如果你确实需要让它联网，可以在配置里打开：

toml
[sandbox_workspace_write]
network_access = true

但这个开关不要随手打开。

比较稳妥的做法是：只有当任务确实需要联网，比如安装依赖、访问文档、调用测试接口时，再考虑临时开启或单独确认。

什么时候应该让 Codex 先问你

只要看到 Codex 请求更高权限，不要直接机械地点允许。

可以先看它要做什么：

  • 是否要访问网络
  • 是否要修改项目外文件
  • 是否要删除文件
  • 是否要安装依赖
  • 是否要运行你不熟悉的脚本
  • 是否要访问密钥、配置、环境变量

如果看不懂，可以直接问它：

text
你为什么需要这个权限？如果我拒绝，会影响哪些步骤？

或者：

text
请给我一个不提升权限的替代方案。

这个习惯很重要。Codex 是协作者，不是自动驾驶。权限越高，越需要你保持判断。

新手记住这套就够了

刚开始不用把所有配置项都背下来。

先记住这几条：

  1. 默认权限适合大多数日常开发
  2. workspace-write + on-request 是比较稳的本地开发组合
  3. Full access 不要随便开
  4. 网络访问默认关闭，需要时再开
  5. 看不懂的权限请求，先问清楚再允许

权限控制不是为了限制 Codex，而是为了让它在一个清楚的边界内更放心地工作。

边界设得好，Codex 才能真正进入“多任务并行”的状态：该自己跑的任务自己跑，该问你的地方及时停下来。