我在一线的AI工具选型这条路上摸爬滚打了挺长时间，试过各种AI编程助手，但真正让我觉得“这玩意儿真能进工作流”的，还得是Codex。加上最近的网络热词里全是“Codex下载”“Codex安装”“Codex接入DeepSeek”，可以感受到大家对这个工具的热情和困惑是同时存在的。所以这篇博文，我想从零开始，把Codex的下载、本地部署、配置、接入本地大模型的完整链路，以及那些官方文档里没写明白的坑，一次性给你捋清楚。

它能解决什么问题？简单说，Codex是一个跑在终端里的AI编程智能体，它能直接读写你的代码文件、执行命令、甚至帮你完成跨多个文件的复杂重构。这篇文章适合谁？无论是刚接触AI编程的新手，还是想把它接进私有化大模型环境的老手，都能从里面找到可以直接“抄作业”的方案。

1. 内容整体设计与思路拆解

1.1 先搞清楚Codex到底是什么

在很多人的认知里，Codex和Copilot是同一种东西，这两个概念经常被混为一谈。实际上它们的工作模式有本质区别。Copilot的核心逻辑是“自动补全”，它在你输入代码的时候给出下一段预测，它是一个 辅助输入法 。而Codex的核心逻辑是“任务执行”，你给它一句自然语言指令，比如“帮我写一个Flask应用，实现用户登录和JWT鉴权，并把数据库模型放在models目录下”，它会自己规划步骤、创建文件、填充代码、安装依赖，甚至可以跑命令来验证。

这种“智能体”形态最大的杀伤力在于，它彻底改变了人跟代码的交互粒度。你不再是一个字符一个字符地敲代码，而是像在带一个经验丰富但偶尔需要盯着的实习生，把任务拆解清楚、验收好结果就行。这也是我为什么说，如果你还在纠结Copilot和Codex选谁，不如先想清楚你要的是“自动补全”还是“自动干活”。

1.2 为什么需要“本地部署”

这里要先澄清一个容易让人误解的点：Codex本身不是一个模型，而是一个 客户端应用程序 。它本身不包含大模型的推理能力，必须连接一个模型服务端来完成对话和决策。它默认连接的是OpenAI的云端API，所以很多教程里“本地部署Codex”，严格来说并不是把Codex的推理引擎搬到本地，而是指以下两种场景之一：

• 场景A：把Codex这个客户端程序安装在本地电脑上，配置文件、会话记录、密钥都由自己掌握，数据流经你控制的终端。
• 场景B：把Codex对接到你本地或者内网部署的大语言模型服务上，比如Ollama、vLLM、DeepSeek开源模型，或者公司内网自建的OpenAI兼容接口。

这两种场景在实际操作中经常叠加出现。你想拥有终端原生的AI编程体验，又不想把代码片段上传到外部服务，或者你有私有的模型服务，用Codex做一个统一的入口，是非常合理的诉求。所以在这篇文章里，我会把这两个层面的“本地部署”都覆盖到。你按自己的实际情况对号入座就行。

1.3 我能用它替代哪些工作流

在深度使用三个多月后，我的体感是Codex在下面几类任务上是真的能省时间，适合纳入日常流程：

• 跨文件的代码重构 ：比如把项目里所有使用旧API的调用改为新API，这种机械但要细心的工作，Codex擅长得让人感动。它能自己搜索哪些文件引用了旧方法，逐个修改，然后你可以用 git diff 快速审查每一处改动。
• 快速搭建项目骨架 ：让它根据你的技术栈偏好生成整个项目结构，比自己从零手搓省太多事了。
• 写单元测试和文档 ：这件事本身价值高但重复性强，Codex能把测试覆盖率和文档完整度拉到一个不错的水准，你再人工检查关键逻辑就行。
• 处理报错和调试 ：给它一坨报错堆栈，它能尝试定位问题位置，甚至直接提出修复方案，最方便的是可以选择让它直接改动代码。

说白了，Codex能帮你处理“工作量占比大、思维含量不高但容易出错”的编程任务。理解它擅长什么、不擅长什么，是后续所有实践中最重要的认知基础。

2. 环境准备与工具链选型

2.1 安装Codex前必须确认的软硬件条件

很多人在安装环节就卡死，其实大部分问题不是Codex本身的问题，而是环境前置条件没做好。按照我的经验，开始之前先对照下面这几条逐项检查。

首先是操作系统和硬件。Codex官方对macOS和Linux支持得最好，Windows则需要通过WSL2来跑，或者直接使用Windows桌面版。Node.js运行时是硬性要求，虽然不是所有安装方式都依赖它，但通过npm安装依然是最省心的路线。我实测下来，Node.js 18以上的版本兼容性最佳，如果你还在用16，建议先升级。

其次是网络和API密钥的问题。Codex默认要连OpenAI的接口，所以你需要一个有效的API Key，并且确认终端环境能够正常访问相关接口。这是最容易出现“安装成功但跑不起来”的环节。另一个前置条件是你得会在终端里设置环境变量，后续很多配置都跟环境变量有关。

2.2 为什么我强烈建议用npm或包管理器安装

Codex的安装方式有好几种，直接去GitHub Releases页下载对应的二进制包也行，官网客户端也行，但我依然推荐新手优先使用npm安装。原因有三点：

• 版本更新省心。Codex迭代速度非常快，几乎每周都有新版本，npm的 codex upgrade 一条命令就能升级到最新版，不用手动下载替换。
• 依赖管理透明。安装过程会清楚告诉你缺什么，报错信息也更标准，排查问题比二进制包打到一半“无响应”要友好得多。
• 团队统一版本方便。用 package.json 锁定版本，不管谁加入项目， npm install 一下就完全复现环境，这对协作很重要。

如果你在Windows上工作，还有一个更方便的选择是直接下载Windows桌面版。桌面版的好处是有图形界面，但如果你是重度开发者，最终还是要在WSL2里配置一个命令行版本，因为桌面版的终端集成能力相对有限，自动化脚本也没有命令行灵活。两个版本的配置文件是通用的，这点很贴心，你完全可以根据场景混用，不需要重复配置。

2.3 配置文件的目录结构和作用域

Codex的配置是TOML格式，默认位置在 ~/.codex/config.toml 。我建议你在动手之前先搞清楚这个文件的作用域，因为它决定了你之后所有自定义配置的生效范围。

全局配置文件管的是所有项目的通用设置，比如默认模型、密钥来源、历史会话存放路径。而Codex也支持在项目根目录放一个 .codex/config.toml ，这个文件中的配置会覆盖全局配置中相同字段的值。这是个很实用的设计，比如你想在这个项目里默认用更大的上下文窗口，在那个项目里用更便宜的模型，可以在各自项目里独立声明，不用改来改去。

还有一点容易被忽略：会话历史和日志都存放在 ~/.codex/sessions 和 ~/.codex/log 目录下。如果你要排查问题或者审计自己跟AI的交互记录，这两个目录就是第一现场。我建议在部署完成后，去看看这两个目录是否正常生成，如果没生成，说明你的环境变量或者权限设置有问题，后面肯定要踩坑。

3. 完整实操：下载、安装与配置一条龙

3.1 安装的两种主流方式和验证方法

方式一：使用npm安装

npm install -g @openai/codex

这个命令会把Codex CLI安装到全局，装完之后先别急着用，做两件事验证环境是否正常。第一件事是运行 codex --version ，如果能正常输出版本号，说明安装本身成功了。第二件事是确认二进制文件的完整路径：

which codex

方式二：Windows桌面版

Windows用户如果不想折腾WSL2，或者只是想先体验一下交互，直接去Codex官网下载Windows桌面版安装包是最省力的路径。下载完成后按提示安装，登录你的OpenAI账号授权即可。但我要提醒一句：桌面版和CLI版在功能权限上不完全一致，某些依赖文件系统操作权限的高级功能在桌面版上受到限制。所以如果你打算做复杂的本地仓库操作，我还是建议你后续在WSL2里安装CLI版本，桌面版可以作为尝鲜或者处理轻量任务的选择。

3.2 使用DeepSeek或Ollama等第三方模型的接入方法

这一节是很多人到处搜的内容，就是怎么让Codex不依赖OpenAI的模型，转而去接DeepSeek、Ollama或者其他兼容OpenAI接口的本地模型。

以DeepSeek的API为例，关键套路是自定义模型提供商。Codex支持在配置文件中通过 model_providers 字段定义自己的提供商，然后在 model 字段中指定你想用的那个模型。下面是一个完整的配置示例：

model = "deepseek-chat"

model_providers = [
  { name = "deepseek", base_url = "https://api.deepseek.com/v1", env_key = "DEEPSEEK_API_KEY" }
]

然后你需要在终端里设置环境变量 DEEPSEEK_API_KEY ：

export DEEPSEEK_API_KEY=你的密钥

这里的逻辑是你把base_url指向任何兼容OpenAI接口规范的服务地址，Codex就用底层协议去调用。换句话说，不管是DeepSeek的官方API，还是你自己内网用vLLM部署的模型，只要接口格式兼容，都能用同样的方式接入。

但是要注意，不同模型的能力边界不一样。DeepSeek这种模型用在Codex场景下，写代码和重构能力都有不错的表现，但它的工具调用稳定性相比OpenAI自家模型略微弱一些，偶尔会出现上下文理解偏差。而如果接的是本地小参数模型，比如7B或者14B的模型，更要降低预期——写简单脚本没问题，复杂跨文件重构就指望不上了。这个问题跟Codex无关，是模型推理能力上限决定的。

3.3 Ollama本地模型部署与Codex联动实操

如果你完全不想走外部API，要用本地部署的大语言模型，我建议用Ollama作为模型服务端，因为它把模型下载和运行做得极其傻瓜化，几乎零配置就能起来。然后通过Codex的model_providers配置把它纳入进来。

model = "ollama/qwen2.5-coder:14b"

model_providers = [
  { name = "ollama", base_url = "http://localhost:11434/v1", env_key = "OLLAMA_API_KEY" }
]

这里有个细节要注意，那个 env_key 字段虽然是必填的，但Ollama本身通常不需要API Key，你可以设置成一个空的环境变量占位符，比如 OLLAMA_API_KEY 设置为 ollama 这个字符串，只要保证Codex能读取到环境值就行。这个绕行方案能解决很多“本地部署Codex连不上本地模型”的报错。

我实测过qwen2.5-coder的14B、32B版本跟Codex配合的情况。14B可以做单文件级别的生成和简单bug修复，速度快、资源占用适中，8GB显存能跑。32B在代码理解深度上有明显提升，但显存要求高不少，需要约24GB以上。如果你用的是Mac统一内存架构，30GB内存以上的M系列芯片跑32B相当流畅，除了推理速度比云端API慢，整个流程是完全可以用的。

3.4 必须理解model_providers的配置逻辑

很多人在配置第三方模型时犯的最大错误，是照着别人的配置抄了一遍，然后完全不知道每个字段是什么意思，一换模型就抓瞎。这里帮大家掰开揉碎讲清楚配置背后的原理。

Codex跟所有AI模型的对接，本质上都是一个套路：你给它一个HTTP接口地址，它往这个地址发送OpenAI格式的请求体，然后从响应里解析出模型返回的内容。这个套路里面， base_url 是核心，它告诉Codex该往哪个地址发请求。 env_key 是告诉Codex去读取哪个环境变量，作为认证令牌放在HTTP请求的Authorization头里。 model 字段则是你希望服务端使用哪个具体的模型名称。

理解了这个机制，你就能举一反三。不管是DeepSeek、Kimi、通义千问，还是开源模型框架vLLM、LM Studio，只要它们对外提供的接口是OpenAI兼容的，都能用同样的模板接进来。区别只是模型名称字符串不同罢了。

4. 核心功能实战：部署之后怎么高效用起来

4.1 交互模式的差异和选择

Codex提供了几种交互模式，选对模式能明显提升工作效率。更关键的是，它们的权限边界完全不同，这关系到你的环境安全。

首先是 全自动模式 ，用 codex exec "你的指令" 来触发。这种模式下Codex在沙箱里执行代码、运行Shell命令，全程不需要你手动确认。它适合执行你完全信任的、影响面可控的任务，比如“给这个项目的README补充架构说明”。

再有一种是 交互模式 ，直接输入 codex 不带任何参数，进入一个类似REPL的对话终端。它执行每个命令前都会询问你是否放行。这个模式跟我日常的工作习惯配合得最好，我可以在听到它计划跑的每条命令时快速审查，觉得不对就打断让它换思路。

另外Codex还支持 resume 功能，你可以恢复之前的会话。这个功能极其适合跨天进行大型任务。比如前天下午让它分析了一下午代码，今天想接着让它继续改文件， codex resume 会话ID 一下就回到之前的上下文，不用重新描述需求。

4.2 文件操作与代码修改的安全边界

有趣的是，Codex对自己的定位其实不是“聊天机器人”，而更像一个“程序员”。它有一整套围绕文件操作和命令执行的权限控制逻辑，这是我见过绝大多数同类工具里做得出色的部分。

在交互模式下，Codex会请求你的批准才执行文件写入和Shell命令。但在全自动模式下，它的操作限制默认比较强——只能读写当前工作目录下的文件，不能随便触碰系统敏感区域。这让人安心不少。

如果你希望Codex能在本地直接执行 git commit 之类的操作，有两种方式：在交互模式下手动批准，或者在配置里设置 "allow" 列表，把 git commit 列入白名单。我个人的习惯是，除了常规的代码读写，把 git diff 和 git status 设成放行， git commit 和 git push 保持每次询问。原因很简单，自动提交代码的出错成本太高了，万一它提交了不想提交的文件，那是给自己找麻烦。

4.3 与GitHub等平台的集成配置

Codex原生支持GitHub集成，你可以在配置中关联你的GitHub账号。这样它就能直接操作仓库，不只限于本地文件。配置方式通常是用OAuth流程授权，或者设置 GITHUB_TOKEN 环境变量。

export GITHUB_TOKEN=你的个人访问令牌

这里给个实操人的提醒：个人访问令牌的权限范围尽量给最小集。Codex只需要处理仓库内容、创建PR等基础能力，不需要把repo的管理权限全部给它。你给它什么权限，它就在什么权限范围内操作，这是底线。

我用Codex创建PR有一个习惯，它生成完代码之后，我会先在本地看一遍改动，再让它提交并推送，最后由它把PR描述写好。这个过程一气呵成，非常丝滑。有一次我甚至直接让它根据一个Issue的描述修复代码、跑通测试、提交PR，全程我只需要审核，等于把“功能开发”的完整闭环交了出去。

4.4 自动化脚本和批处理的实战建议

前面讲的都是Codex跟人交互的场景，但它还有很强的批处理能力。你可以写一个Shell脚本，循环调用 codex exec 跑一系列任务。这个能力在日常开发中能解放很多重复劳动。

比方说，你接手了一个旧项目，里面有几百个 TODO 注释。你完全可以写个脚本让Codex逐个文件去分析这些TODO到底需不需要解决，然后生成报告。这种活要是人肉去做，两天都不一定能干完，但Codex一晚上就搞定了。

for file in $(find ./src -name "*.py"); do
  codex exec "分析 $file 中的TODO注释，输出哪些需要立即处理，哪些可以删除，输出JSON格式报告" --skip-git-repo-check
done

要注意的是，大规模批处理时，Codex的上下文窗口是有上限的。每次调用都相当于一个全新的对话，它看到的就是你标题里说的这个文件，不会自动带上前一个文件的分析结论。所以你要在每条指令里写清楚让它输出什么格式、重点关注什么，不然它返回的结果会非常混乱。

另外，批处理任务如果跑的时间太长，建议用 nohup 挂在后台执行。Codex偶尔会卡在等待确认状态，如果是非交互模式，会自动采用默认策略继续，不用担心它会停在半路。

4.5 Web搜索和MCP扩展的进阶玩法

如果你用到的Codex版本比较新，会发现它开始支持网页搜索功能和MCP（Model Context Protocol）扩展。MCP相当于给Codex插上外部工具的接口，让它能调用数据库、浏览器等外部能力，配合Codex自身强大的终端环境，能做很多原来只能靠人手工完成的操作。

比如你想让Codex查某个文档站的API用法，再根据查到的内容写一段调用代码。没有MCP的时候，你得手动把文档内容粘贴进去。有了MCP，Codex能自己去读取网页内容再生成代码。不过我要给大家打个预防针，MCP扩展的配置复杂度比基本模型接入高不少，为了求稳，建议先跑通默认配置再折腾这些扩展，一步到位往往容易出乱七八糟的问题。

5. 常见问题排查与避坑实录

5.1 热词里那些报错到底是怎么回事

最近网络上关于Codex的搜索热词里充斥着“codex 无法加载组织设置”和“cc switch local proxy failed while handling codex endpoint /responses. provider”这类报错。看到大家被这些问题折磨，我专门把它们的成因和解决办法整理一下。

“无法加载组织设置”这个报错，主要发生在你同时关联了多个组织账号，但Codex不知道当前该用哪个组织身份的情况下。最简单的处理方式是通过环境变量显式指定组织ID：

export OPENAI_ORGANIZATION=你的组织ID

把这一行加进你的 ~/.bashrc 或者 ~/.zshrc 里，让它永久生效，之后就不会再出现这个提示了。如果你用的是Windows桌面版，可以直接在应用设置里的账户部分重新选一下组织，效果也一样。

而“cc switch local proxy failed”这个报错，本质上是网络代理配置的问题。它只能说明你的终端环境里某些HTTP代理设置跟Codex连接端点时产生了冲突，或者设置了本地代理但没有确保Codex的流量走通了。解决的思路不是说让你去调整什么特殊网络设备，而是围绕常规的网络连通性检查来排查，比如检查代理环境变量是否正确、代理服务是否在运行、API端点能否正常请求到。把代理配置理顺，这个报错自然就消失了。

5.2 安装后无法启动或者找不到命令

如果你安装完运行 codex 却提示“command not found”，最常见的原因是npm的全局bin目录没有加到PATH环境变量里。用 npm prefix -g 查一下全局目录位置，然后把里面的bin目录加到PATH即可。

export PATH="$(npm prefix -g)/bin:$PATH"

另外在Windows上还有一个比较容易栽跟头的点，就是PowerShell的执行策略限制。如果安装脚本因为策略问题中断，可以用管理员权限运行 Set-ExecutionPolicy RemoteSigned 来解除限制，然后重新安装。

5.3 接入DeepSeek或Ollama后总是超时或报认证错误

两种典型情况我都在实践中遇到过。第一种是接了DeepSeek之后报401认证失败，这种几乎都是环境变量没生效。设置完 export DEEPSEEK_API_KEY 后，一定要在同一终端重新打开Codex，或者先跑一下 echo $DEEPSEEK_API_KEY 确认变量真的存在于当前环境中。很多人在 .env 文件里配了Key，以为就生效了，但Codex并不默认读 .env 文件，这是个巨坑。

第二种是接入Ollama但报连接超时。这通常是Codex尝试访问的地址和Ollama的监听地址对不上。Ollama默认监听 http://localhost:11434 ，如果你的服务是通过Docker跑的，地址可能就不一样。检查一下Ollama实际监听的地址，把它填到 base_url 里，问题就能迎刃而解。

5.4 会话历史管理和隐私注意事项

Codex会把每一轮对话、每一次操作完整记录在 ~/.codex/sessions 目录下。这个设计既方便你回溯，也有隐私风险。如果你在一个共享的电脑或者公司环境使用，需要格外小心这些记录的敏感性，因为它们包含你的真实代码和指令信息。

我的建议是定期清理不需要的会话记录，或者至少对敏感的会话做归档加密。另外，Codex的配置文件中包含API Key的读取方式，如果团队协作中要分享配置文件，务必把密钥部分做成环境变量引用，而不是把明文密钥写进去。这是最容易被忽视的安全漏洞。

5.5 快速排查速查表

为了方便你对照排查，我汇总了一张我在实践中总结的速查表，按症状、原因、解决方法来整理。

症状	常见原因	解决办法
安装后找不到codex命令	npm全局目录不在PATH中	将npm全局bin目录加入PATH
启动时报认证失败/401	API Key环境变量未生效或错误	确认环境变量名称，检查Key有效性
接入Ollama超时	base_url与Ollama监听地址不匹配	确认Ollama服务监听地址，修正base_url
无法加载组织设置	多组织账号冲突	显式设置OPENAI_ORGANIZATION
沙箱权限不足，无法写文件	默认沙箱限制	在交互模式下批准，或按需配置allow列表
上下文不够用	大文件超过模型窗口上限	用--full-auto子任务拆分，或改用窗口更大的模型
代理报错	终端代理环境与API端点冲突	检查全链路网络连通性，规范化环境变量

这张表是我每次调试遇到问题时的第一参考，至少帮我省掉了一半的试错时间。

6. 部署后的优化与实测体验

6.1 模型选择与Codex效果之间的匹配关系

部署完成后，真正决定Codex好不好用的，已经不取决于Codex本身，而是你选了哪个模型来驱动它。这是我最想强调的一点。我试过OpenAI自家的GPT系列模型、DeepSeek系列，还有本地的Qwen Coder系列，它们各自的性格差异很大。

GPT系列模型在代码理解、函数调用、多步骤任务规划上最均衡，跟Codex结合得最紧密，但费用也最高。DeepSeek在处理中文注释和文档生成时有一定优势，代码能力和GPT有差距但差距不大，性价比较高。Qwen Coder本地模型则完全拥抱隐私保护，离线可用，但推理速度慢，复杂任务稳定性弱一些。你用Codex时，要有一个清晰的预期：模型决定了下限，Codex的智能体机制决定了上限，两者的配合缺一不可。

6.2 关于模型上下文窗口的关键参数理解

上下文窗口这个参数，很多人是等到Codex“失忆”时才反应过来它有多重要。Codex像一个工作记忆容量有限的人，它能在一次会话里记住的内容取决于模型可用的上下文窗口大小。

如果你的任务比较大，比如要它重构一整个项目，而项目代码量明显超过模型的上下文窗口，它的表现就会断崖式下跌：忘了前面的修改、重复生成已有代码、甚至答非所问。解决这个问题最有效的办法是把大任务拆成小批次，每个批次聚焦在一个子模块，改完一个再交给它下一个，不要指望一个会话搞定所有事情。

如果你用的是本地模型，上下文窗口的影响更加明显。小参数模型把自己的上下文窗口压缩得比较小，很多实际项目的代码量稍微大点，就会开始明显地“变笨”。这时候就地文件级重构，反而效果好过让它跨文件高层规划。

6.3 实测数据：不同场景下的性能表现

我在部署完成后的两周内做了几组对比实测，基于真实开发任务，结果很有参考价值。

第一组是“给一个Django项目新增一个带分页的API接口”。用默认GPT模型，从任务下达到文件生成、路由注册完成，总共用了大概40秒，改动质量高，几乎不需要人工修正。用DeepSeek模型时候也是类似的效果，但因为网络延迟小一些，实际感受更快。用本地的Qwen Coder 32B，生成阶段要80秒左右，生成的代码初版可用，但部分细节需要人工调整。

第二组是“把一个旧项目从requests库全面迁移到httpx”。这是一个跨几十个文件的机械性重构任务。GPT模型的表现稳定，逐文件修改，全部完成大概需要5分钟，中途没有任何中断。本地Qwen Coder在处理这种大量文件的任务时，偶尔会出现漏改、半途停止的情况，必须依赖 git diff 仔细核验。

第三组是“根据错误堆栈自动修复一个复杂的并发bug”。这种深度推理任务，本地小模型基本没法胜任，多次尝试后都偏离方向。最终仍然是云端GPT系列模型顺利解决了问题，因为这种任务对模型的推理深度要求太高。这三组实测数据基本可以帮你建立成这样的预期：本地模型适合轻量级任务，云端强模型适合复杂深度任务。

6.4 进一步提升体验的配置技巧

按照我个人的配置习惯，你可以往配置文件中加入一些对工作流有明显提升的参数。比如给 model_reasoning_effort 设置成 high ，可以让模型在复杂推理任务上多花思考时间；在 approval_policy 里设置 "on-request" ，可以避免它频繁打断你，只在真的需要决定的时候才询问。

另一个非常实用的小技巧是把Codex的提示词模板自定义一下。Codex允许你定义自己的AGENTS.md文件，这个文件会影响它在你项目里的行为风格。比如你可以在AGENTS.md里规定“所有生成的代码必须包含类型标注”、“新功能必须同步更新测试文件”，它会在后续会话中持续遵守这些约定，产出风格保持一致。这相当于给你自己塑造了一个懂你项目规矩的AI协作者，非常值得一试。

我在实际使用中发现，AGENTS.md这个文件的影响力被很多人低估了。一开始我也是偷懒不写，觉得“反正它能看懂代码”。但后来在一次紧急的跨模块重构中，它因为没有项目约束，把模块间调用方式改得七零八落，差点酿成事故。从那以后，我每个重要项目都会花十分钟写AGENTS.md，定义清楚目录结构、代码风格、测试要求。长期下来，这件事花的时间一定值得。

再分享最后一个小技巧：建议把 ~/.codex/config.toml 纳入版本管理，用dotfiles仓库统一管理。这样你换电脑或者跟同事协作时，一条 git clone 加一个软链接就能完全恢复自己的Codex环境，不需要重新记忆那些配置细节。这个习惯能让你的部署配置变得可复制、可迁移，也算是一个从“能用”到“好用”的分水岭。