搞命令行AI编程的近半年最绕不开的一个名字就是 Codex。我最初是在 macOS 上跑的 Codex CLI体验确实不错但后来把主力机换成了 Windows就发现网上讲 Windows 下安装配置的资料碎得不行很多坑都得自己一个个踩。这篇就把我在 Windows 上从零折腾 Codex 的完整过程写出来包括安装方式怎么选、登录认证怎么处理、模型怎么配、常用玩法有哪些以及那一堆报错到底是什么意思、怎么解。不管你是刚听说 Codex 想试试的新手还是在 macOS/Linux 上用过、想在 Windows 上复刻一遍的老手这篇应该都能帮你省下不少时间。先交代一下我自己的环境方便你对照Windows 11 专业版 23H264 位系统Node.js 用的是 v20.11.1 LTSGit 是 2.43.0终端用的 Windows Terminal。这套组合当前跑 Codex 最新版没有任何兼容性问题下面所有操作都是在这个环境里验证过的。1. 先搞清楚 Codex 是什么以及为什么要在 Windows 上用它1.1 不是 GitHub Copilot也不是 Cursor它是 OpenAI 官方的终端 AI 编程代理Codex 是 OpenAI 推出的命令行 AI 编程工具英文全称叫 Codex CLI。它和我们熟悉的 Copilot、Cursor 这类IDE 插件 / 编辑器最大的区别在于它跑在终端里以代理的方式直接操作你的代码库。你给它一个任务它会自己读文件、改文件、执行命令、检查结果整个流程可以看作一个在你电脑上干活的自动化编程助手。很多人的第一个疑问是我都在用 Cursor 了还配了 Copilot为什么还要折腾 Codex我的理解是Codex 解决的问题场景不一样。在 IDE 里AI 是辅助你写代码核心工作还是你完成而 Codex CLI 更适合那种你明确知道要做什么但不想手写一堆样板代码的任务比如批量重构、写测试、跨文件修改、跑一遍命令行工具链。它相当于一个更自主的终端代理你的角色从写代码的人变成了提需求、审代码的人。另外Codex 和 OpenAI 的 ChatGPT 是打通的。你可以在终端里让 Codex 调用你 ChatGPT 账号的额度也可以单独用 API Key 按量付费。这意味着如果你本来就有 ChatGPT Plus/Pro 订阅用 Codex 不需要额外掏钱直接用订阅额度就行这是它在定价上比很多独立 AI 编程工具香的重要原因。1.2 Windows 下的 Codex 和 macOS/Linux 版本有什么差异先说结论功能上没有本质差异但环境准备和认证方式上有几个 Windows 特有的问题。Codex CLI 是基于 Node.js 开发的所以理论上只要你能跑 Node.jsWindows/macOS/Linux 都能跑。但 Windows 和 macOS/Linux 在文件系统、shell 环境、路径处理上差异很大直接导致 Windows 上会遇到一些 macOS 上没有的问题。比如默认 shell 不同。macOS/Linux 用 bash/zshWindows 用 cmd/PowerShellCodex 需要调用 shell 来执行命令Windows 下的 shell 兼容性就经常出问题。路径分隔符和换行符问题。Windows 是反斜杠路径、CRLF 换行这会影响 Codex 读文件、改文件的行为。OpenSSL 和证书问题。Windows 的 Node.js 走系统证书库有时候会出现证书验证失败这在 macOS 上很少遇到。认证方式不同。macOS 上可以直接走系统浏览器做 OAuth 登录Windows 上如果默认浏览器设置有问题登录流程会卡住。这些问题不是 Codex 本身有问题而是 Windows 生态的固有差异。所以这篇博文我会花比较多篇幅讲环境准备和问题排查这部分才是 Windows 用户真正省时间的核心。1.3 安装前必须确认的 4 个前提条件不要一上来就敲npm install先把基础环境准备好否则后面全是莫名其妙的坑。我列一下必要条件操作系统Windows 10 版本 22H2 或更高Windows 11 全版本。老版本 Windows 10 可能出现 OpenSSL 或终端兼容性问题。Node.js建议 18.0.0 及以上实测 v20 LTS 最稳。不要用 v17 或更老版本Codex 依赖的现代 JavaScript API 在老版本上会直接报错。Git必须装而且建议在安装时勾选添加到 PATH。Codex 的版本管理、变更回滚都依赖 Git。终端强烈建议用 Windows Terminal不要用老的 conhost就是那个经典黑窗口。Windows Terminal 的渲染、复制粘贴、字体支持都更好Codex 的交互界面在 Windows Terminal 里显示最正常。注意如果你在 Windows 上用 WSLWindows Subsystem for Linux理论上可以直接在 WSL 里装 Linux 版 Codex。但 WSL 有自己的一套路径和网络问题和不熟悉 WSL 的人讲不清楚。这篇博文专注讲原生 Windows 方案也就是直接在 Windows 上装 Node.js 跑 Codex这样最直观、最容易复现。2. 安装 Codex 的 3 种方式与选择逻辑2.1 方式一npm 全局安装最推荐90% 的人选这个Codex 官方推荐的安装方式就是通过 npm 全局安装。打开 PowerShell 或 Windows Terminal执行npm install -g openai/codex装完验证一下codex --version如果能看到类似codex 0.x.x的输出版本号说明安装成功。这个方式为什么最推荐因为 npm 包更新最简单一条命令就能升级而且 npm 是 Node.js 自带的包管理器你只要装了 Node.js 就一定有它。后面升级也很方便npm update -g openai/codexnpm 安装的唯一风险是网络问题。国内用户如果 npm 官方源下载慢可以临时换一下源。但注意我不建议长期使用第三方 npm 镜像因为 Codex 更新很频繁镜像同步可能会有延迟。临时下载慢的时候换一下就行装完记得换回来。2.2 方式二原生安装器适合不想装 Node.js 的人如果不想为了装 Codex 单独装一个 Node.js 运行时可以用官方提供的原生安装器。Codex 官网提供了 Windows 安装包下载后双击安装即可。安装器会把 Codex 编译成独立的可执行文件自带 Node.js 运行时所以不需要你手动装 Node。这个方式的优缺点都很明显。优点是省事不需要管 Node.js 版本缺点是更新比较麻烦需要手动去官网下载新版安装包重新装没法用 npm 一条命令搞定。如果你是那种能用就行不折腾环境的人选这个没问题。不过我个人还是更推荐 npm 方式因为 Codex 迭代速度非常快几乎每周都有小版本更新npm 方式更新成本低太多了。你要是用原生安装器每次更新都要下载一次完整安装包时间长了会觉得很烦。2.3 方式三源码编译不推荐普通用户openai/codex的源码在 GitHub 上理论上你可以 clone 下来自己构建。但这完全没有必要因为官方已经发布了编译好的 npm 包和原生安装器。源码编译只适合两种人一种是想要最新开发版功能的人另一种是打算给 Codex 贡献代码的开发者。普通用户直接跳过这个选择。2.4 安装完先做这两件事确认 shell 环境和 Node 版本装完之后不要急着登录先做两个基础检查后面能少踩一半坑。第一个检查是确认 Codex 默认用的 shell。Codex 在 Windows 上默认会尝试用 PowerShell如果没找到才退回 cmd。你可以运行codex --debug看输出的日志里 shell 相关的内容确认它用的是哪个 shell。如果发现它用的是 cmd但你想用 PowerShell可以在配置文件里显式指定配置方式后面讲。第二个检查是确认 Node.js 版本。运行node -v npm -v确保 Node 不低于 18npm 不低于 9。如果版本太低后续可能遇到各种莫名其妙的语法错误。3. 登录、认证与配置文件这一步决定你能不能用起来3.1 登录方式详解ChatGPT 账号 vs API KeyCodex 支持两种认证方式一种是 ChatGPT 账号登录OAuth另一种是 OpenAI API Key。两种方式的适用场景完全不同先搞清楚再选。ChatGPT 账号登录适合有 ChatGPT Plus 或 Pro 订阅的用户。这种登录方式下Codex 使用的是你订阅套餐里包含的 ChatGPT 额度不需要额外为 API 调用付费但会有每日使用量限制。流程是在终端运行codex login它会弹出一个浏览器窗口让你登录 ChatGPT授权之后终端会自动绑定会话。API Key 方式适合使用 OpenAI API 并按量付费的开发者或者想通过第三方兼容 API比DeepSeek等接入其他模型的用户。流程是在 OpenAI 平台创建 API Key然后在 Codex 配置里指定这个 Key。这种方式不依赖 ChatGPT 订阅费用完全看你调用了多少 token。我的建议是如果你只是想体验 Codex 做 AI 编程而且已经有 ChatGPT Plus/Pro 订阅直接用 ChatGPT 登录就行最省事如果你是做开发集成、要写脚本、或者需要精确控制模型和费用就用 API Key 方式。3.2 Windows 上登录报错的常见原因Windows 下执行codex login最常遇到的问题有两个。第一个是浏览器弹不出来。Codex 的登录流程需要打开默认浏览器跳转到 OpenAI 的授权页面如果 Windows 默认浏览器没设置好或者终端环境变量BROWSER被占用了就会卡在 Waiting for authorization... 这一步。解决办法是手动设置默认浏览器或者在配置文件中指定浏览器路径。第二个是登录后终端报 auth token is unavailable 之类的错误。这个通常是因为 Codex 虽然拿到了 auth token但没能正确写入系统的凭据管理器。Windows 下 Codex 会把 token 存在系统凭据管理器Credential Manager里如果系统服务没开启或者你的终端没有管理员权限写入就会失败。解决办法是确保 Windows Credential Manager 服务在运行并且用普通用户权限打开终端不要用管理员权限跑。注意这里有个很反直觉的点——用管理员权限打开终端反而可能导致凭据写入失败。因为管理员权限下的进程和普通用户权限下的进程访问的凭据存储空间可能不是同一个。首次登录就用普通权限的终端跑codex login后续使用也用普通权限保持一致最稳。3.3 配置文件路径与核心配置项Codex CLI 的配置文件在用户目录下的~/.codex/config.toml。Windows 下就是C:\Users\你的用户名\.codex\config.toml。如果文件不存在可以先运行一次codex让程序自动创建也可以手动创建。典型的配置文件内容如下# Codex 配置文件位于 ~/.codex/config.toml # Windows 示例 # 模型选择 model gpt-5.2-codex # API 基础地址默认是 openai.com后续会讲到如何改 # base_url https://api.openai.com/v1 # 是否允许 Codex 自动执行命令 # 默认 false改成 true 表示自动执行不推荐建议手动批准 auto_exec false # 禁止 Codex 执行的命令列表 # 这些命令会被直接拒绝安全性兜底 # disable_sandbox false # sandbox_workspace_write [/tmp/codex-workspace] # 终端 shell 路径 # 不设置则自动检测 # shell C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe # 存储路径默认 ~/.codex # legacy_storage_path C:\\Users\\你的用户名\\.codex关键配置项说明model指定使用的模型。默认的是 OpenAI 的 codex 系列模型具体版本会随更新变化。如果用 API 接入第三方兼容服务后面单独讲这里要改成对应的模型名。base_urlAPI 请求基础地址。默认指向 OpenAI如果要接入第三方兼容端点比如 DeepSeek 或其他 provider改成对应地址。auto_exec是否允许 Codex 自动执行 shell 命令。我强烈建议保持false让 Codex 每执行一条命令前都征求你的同意。虽然会多一步操作但能防止 Codex 误操作。后面讲使用技巧时我会详细说。shell指定 Codex 调用命令时用的 shell。不设置的话默认检测。修改配置后需要重启 Codex 会话才会生效。注意修改config.toml之前最好备份一份因为手误改错格式会导致 Codex 直接启动失败。3.4 把 Codex 接入 DeepSeek 或其他 OpenAI 兼容 API这段时间网上搜 Codex 接入 DeepSeek 的人特别多。原因也很简单OpenAI 的 API 在国内访问门槛高而且 GPT 模型按 token 计费不便宜DeepSeek 的 API 价格相对低不少而且有 OpenAI 兼容的接口格式理论上 Codex 也能走这个路子。不过这里得先明确一个安全和技术边界接入第三方兼容 API 时一定要用官方提供的、合规的 API 地址和认证方式不要用任何非官方代理服务也不要听信免费用 GPT之类的说法。正规接入的配置方式是在config.toml里指定base_url和 API Key# 以 DeepSeek 官方 OpenAI 兼容接口为例请以官方文档为准 # model deepseek-reasoner 或 deepseek-chat # base_url https://api.deepseek.com/v1然后在环境变量或配置里设置对应的 API Key。具体模型名、接口路径、参数限额务必以该服务商的官方文档为准不要照搬网上的过时配置。需要提醒的是Codex 本身是为 OpenAI 的模型设计的很多功能比如函数调用、工具调用、安全过滤依赖模型的能力。第三方模型即使接口格式兼容实际表现也可能有差异。如果遇到工具调用行为不符合预期优先检查模型名称是否匹配、该模型是否支持 Codex 所需的工具调用协议。4. Windows 下的核心使用实战从初始化项目到自动改代码4.1 第一次启动进入交互式 REPL安装并登录完成后在任意项目目录打开终端输入codex会进入 Codex 的交互式会话REPL模式。这时候你可以直接用自然语言描述任务比如把当前目录下的 utils.js 里的所有 var 改成 const 或 letCodex 会先读取项目结构然后分析任务最后给出它计划做的修改。在默认配置下它会每步询问你是否继续。看起来有点像在终端里和一个懂代码的同事聊天但它的懂是建立在能真实读文件、改文件、执行命令的基础上的。REPL 模式和codex后直接带参数的纯命令模式不同。REPL 更适合交互式对话适合你还不确定怎么拆任务的时候边聊边引导代码一步步改。纯命令模式适合明确的任务和脚本化调用。4.2 实战案例让 Codex 自动给你写一个 Python 脚本假设你在D:\projects\test-codex目录下想让 Codex 帮你写一个批量重命名文件的 Python 脚本。进入 REPL 后输入写一个 Python 脚本把当前目录下所有 .txt 文件重命名为 yyyy-MM-dd_原名.txt 的格式要求处理文件名冲突。Codex 会开始工作典型流程是这样的列出当前目录内容了解文件结构检查是否已有类似脚本自动创建rename.py在运行前征求你的许可你可以输入y同意n拒绝或者自己手动修改运行脚本把输出结果展示给你看。这里面最关键的是第 4 步的同意机制。Codex 执行命令前会停下来问你这是安全兜底不要让 Codex 拿着管理员权限乱跑命令。如果你完全信任某个任务可以在 REPL 里输入/approve进入自动放行模式但结束任务后记得退出。4.3 让 Codex 改动代码后如何审计变更Codex 改完代码之后不要直接信任它。我自己用下来的习惯是每次让 Codex 完成一轮修改立刻运行git diff看它到底改了哪些文件、改了什么内容。可以用命令模式codex exec 给所有的 Python 文件添加类型注解执行完之后在项目目录跑git diff --stat git diffgit diff --stat看文件级别的改动概况git diff看具体变化。这一步必做不管 Codex 表现得多自信都要人肉审计一遍。改得有问题想回滚直接git checkout .回到修改前的状态。这就是我为什么强调必须装 Git这玩意儿不只是给你自己写代码用的更是你对 Codex 的后悔药。4.4 非交互式用法把 Codex 写进脚本和自动化流程Codex 不止能在终端里聊天式使用它还支持非交互式执行适合放进脚本、CI/CD 流程或自动化任务里。一次性的非交互任务格式是codex exec 你的任务描述比如codex exec 给项目添加一个 README.md内容包括项目简介、安装步骤、使用示例这个命令会直接执行、然后退出不会进入交互界面。如果配置了auto_exec true它会一口气跑完所有步骤如果是默认的false它会在需要执行命令时卡住等你确认——所以配置auto_exec时要想清楚场景。PowerShell 里还有更自动化的玩法把输出重定向到文件codex exec 整理当前目录的所有未提交改动到 CHANGELOG.md | Out-File -Encoding utf8 runlog.txt不过我要提醒一点在 Windows 的 PowerShell 里跑codex exec如果碰到中文乱码通常是 PowerShell 编码问题不是 Codex 的问题。把代码页切到 UTF-8 再跑就好了chcp 650015. Windows 常见问题与排查实战5.1 安装阶段常见报错速查表错误信息可能原因解决方案npm ERR! code EEXIST全局目录已存在同名文件手动删除冲突文件或执行npm cache clean --force后重试npm ERR! code CERT_HAS_EXPIREDnpm 镜像证书过期把 npm 源切回官方源或更新 npm 版本codex 不是内部或外部命令npm 全局 bin 目录不在 PATH 里把%APPDATA%\npm加入系统 PATHError: Cannot find modulenpm 安装不完整先npm uninstall -g openai/codex再重新安装PowerShell 提示禁止运行脚本执行策略限制运行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned其中最典型的是 不是内部或外部命令 那个。npm 全局包的可执行文件默认放在C:\Users\你的用户名\AppData\Roaming\npm目录下如果这个目录不在 PATH 环境变量里终端就找不到codex命令。解决办法设置 → 系统 → 关于 → 高级系统设置 → 环境变量在用户变量的Path里添加%APPDATA%\npm保存后重开终端。5.2 登录与认证阶段常见问题错误信息可能原因解决方案浏览器无法自动打开系统默认浏览器或 BROWSER 环境变量问题手动复制日志中的授权链接到浏览器打开auth token is unavailableToken 写入 Windows 凭据管理器失败检查 Credential Manager 服务用普通权限终端重试登录成功但每次重启都要重新登录Token 未持久化检查~/.codex/目录是否可写确认没有被杀毒软件拦截cc switch local proxy failed while handling codex endpoint /responses使用了本地代理/转发类工具时上游连接失败关闭本地代理及网络转发类工具或者检查代理地址是否配置正确codex 正在重新连接/codex 打不开网络连接问题或本地服务异常检查网络连通性重启 Codex必要时重装说一下 cc switch 那个报错。这个cc switch是一个社区用户用 Rust 写的 CLI 切换工具用来切换不同的 OpenAI 兼容 API provider 配置。但这工具在设计上会修改本地 Codex 的配置如果它的配置和本机网络环境不匹配比如你本地有一个代理服务但代理没启动Codex 请求/responses端点时就会报 local proxy failed 的错误。遇到这个优先检查你的本地代理服务注意这里说的是指本地 HTTP 代理不是任何违规工具是不是挂了以及cc下的配置文件的base_url是否指向了一个不可达的地址。把不可达的地址改回官方 API或者启动对应对代理服务就能恢复。5.3 模型不受支持错误the gpt-5.6-sol model is not supported when using codex with a ...有段时间很多人搜 gpt-5.6-sol model is not supported when using codex这个错误的根源很直接Codex 是一个固定功能的客户端它对模型有兼容性要求。官方会根据 Codex 版本的迭代在客户端里做模型名白名单校验不在名单里的模型比如某些重命名/变体/预览模型或者第三方的同名模型会直接拒绝。解决办法有几个方向把 Codex 升级到最新版npm update -g openai/codex新版本通常会同步支持新的官方模型在config.toml里把model改成当前官方支持的模型名不要用别人教程里写的旧模型名如果你确实需要指定模型用codex exec --model 模型名临时指定但要确认该模型对 Codex 工具链的兼容性。我自己遇到过类似问题是升级 Codex 后配置文件里还写着旧模型名导致新版启动直接报错。改了模型名之后一切正常。所以配置文件里的模型名要时不时检查别一次配置终身使用。5.4 日常使用中的 4 个高频坑第一个坑是 PowerShell 执行策略。Windows 默认的 PowerShell 执行策略是Restricted可能会阻止 npm 生成的.ps1脚本运行。解决办法是给当前用户设置RemoteSignedSet-ExecutionPolicy -Scope CurrentUser RemoteSigned。这个设置是合法的、官方支持的配置不会影响系统安全它只允许本机创建的脚本和签名过的远程脚本运行。第二个坑是杀毒软件/Windows Defender 拦截。Codex 第一次要执行命令时某些杀毒软件可能会弹窗告警。如果你确认 Codex 和命令是安全的需要手动放行。经常被拦的是codex.exe本体以及它要调用的git.exe、node.exe。Windows Defender 如果误报可以在病毒和威胁防护 → 排除项里添加 Codex 的安装路径。第三个坑是路径空格。Windows 很多路径带空格比如C:\Program Files\...Codex 在执行命令时如果没正确处理带空格的路径会报 command not found 或执行到错误的路径。这个没有特别完美的解决方案只能在配置shell或写任务时尽量避免把路径写死或者用短路径8.3 格式来规避。第四个坑是中文路径和中文文件名。Windows 下的中文路径有时会导致 Codex 读文件失败。如果你项目路径包含中文建议先复制一份到纯英文路径下跑跑通没问题再考虑回头处理。这不是 Codex 独有的问题很多 Node.js CLI 工具在 Windows 中文路径下都有类似毛病。6. 安全与权限使用 Codex 之前必须想清楚的事6.1 为什么不要把 auto_exec 直接改成 trueauto_exec true会让 Codex 自动执行它认为需要执行的命令不再问你。听起来很爽但风险巨大。Codex 执行的是系统命令它有权限做你当前用户能做的一切事——删除文件、修改注册表、提交 Git 代码、覆盖配置如果在有管理员权限的终端里跑它甚至能改系统级配置和安装软件。它的判断能力还没强到对每条命令的后果完全负责。我的建议是始终保留手动确认的默认模式尤其当你让 Codex 在正式项目里改代码的时候。每次确认无非是敲一个y的事但多这一下能避免 99% 的灾难性误操作。如果你需要长时间无人值守跑任务也要先评估任务涉及的命令是否安全跑完立刻检查结果。6.2 从 OpenAI 官方渠道获取 API Key 与认证信息不论是用 ChatGPT 登录还是 API Key都要坚持一个原则只从 OpenAI/官方文档入口获取认证信息。很多互联网上的免费 API Key 分享破解版基本都涉及账号泄漏或第三方中转轻则 Key 被盗刷产生费用重则隐私代码被上传到未知服务器甚至账号被封禁。这个风险完全不值得冒。如果你用的是第三方兼容 API比如 DeepSeek同样只认准该服务商的官网和官方文档不要用来路不明的第三方聚合接口。第三方接口的 URL、Key 都会经过你的本地客户端一旦这个第三方不可信你的代码和 prompt 就等于裸奔。6.3 不要把敏感项目整个丢给 CodexCodex 会读取你项目里的文件来理解上下文然后把相关的文件内容或摘要发送到 API 服务端做推理。如果你在做一个商业项目代码里有数据库密码、API Key、客户隐私数据直接让 Codex 处理等于把这些信息上传到第三方服务器。这不是 Codex 独有的问题所有 AI 编程工具都一样。规避方式很简单用.gitignore和.codexignore把敏感文件排除在 Codex 的读取范围之外涉及密钥、令牌的配置单独放环境变量或凭据文件不要写在项目源码里敏感项目用本地模型或私有化部署方案不要用云端 API。Codex 的隐私边界在 OpenAI 官方文档里有明确定义使用前花十分钟看一下数据处理相关条款比出事后补救强得多。7. Windows 下的进阶玩法与生产力组合7.1 在 VS Code 里用 Codex官方插件方案Codex CLI 虽然定位是终端工具但 OpenAI 官方也提供了 VS Code 插件方便你在编辑器里使用 Codex。在 VS Code 扩展市场搜 Codex OpenAI 就能找到官方插件。安装后左侧会出现 Codex 面板可以直接在编辑器里选代码、提需求Codex 会在编辑器里生成 diff 而不是直接改文件审查起来比终端里方便很多。我的体验是编辑器插件和 CLI 是互补关系。CLI 适合给你一个完整任务自己去干的场景比如批量重构、跨文件改动插件适合我选中这段代码帮我优化这种单元级的操作交互反馈更直观。两个都装了之后公用同一个登录凭据和配置不会冲突用起来很顺手。7.2 Codex 与 MCP 工具的组合MCPModel Context Protocol是 Anthropic 提出的开放协议目的是让 AI 模型通过标准化的方式调用外部工具。OpenAI 的 Codex 目前对 MCP 生态也有一定支持你可以通过 MCP 给 Codex 挂一些自定义工具比如数据库查询、HTTP 请求、文件搜索等。在config.toml里可以声明 MCP Server# 启用 MCP 支持按平台实际版本可能会微调 [mcp_servers] # 示例注册一个网络请求 MCP server # [mcp_servers.fetch] # command npx # args [-y, some-mcp-server-package]MCP 的具体配置方式取决于 Codex 当前版本的支持程度官方文档更新比较勤建议以官方文档为准。这个玩法适合已经熟练使用 Codex 基础功能的用户新手不建议一开始就碰 MCP先把基础流程弄顺。7.3 Windows Terminal 集成与自定义快捷启动把 Codex 和 Windows Terminal 绑定能提升不少体验。比如在 Windows Terminal 设置里新建一个配置文件启动命令直接设成codex这样每次打开一个专门跑 Codex 的标签页不用手动敲命令。操作方式Windows Terminal 设置 → 新增配置文件 → 命令行设为codex.exe确认路径npm 全局安装后通常就在%APPDATA%\npm\codex.exe→ 设置一个独立配色和图标。这样我有一个单独的 Codex 标签页视觉上就和普通终端区分开了工作区更清爽。我还会在 PowerShell profile 里加一个函数function Run-Codex { codex args } Set-Alias cx Run-Codex这样在 PowerShell 里敲cx 任务描述就相当于codex exec 任务描述省了几个键。这种自定义看个人习惯不一定非要学但能让你用起来更顺手。7.4 多项目配置管理如果你同时维护多个项目不同项目用的模型、权限策略可能不一样。Codex 的做法是配置文件优先级从高到低依次是 当前目录的codex.toml→ 当前目录的.codex/config.toml→ 用户全局的~/.codex/config.toml。也就是说你可以在某个具体项目里放一个.codex/config.toml单独指定模型、shell、权限其他项目用全局配置互不影响。比如 A 项目用 GPT 官方模型B 项目用性价比更高的第三方模型各自独立配置这比每次手动改全局配置优雅多了。这个多级配置机制在官方文档里有完整的字段说明 Windows 用户注意路径里的反斜杠要转义成\\比如shell C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe8. 写在最后的几条经验Codex 在 Windows 上跑起来之后实际发挥多大作用很大程度取决于你给它定义的任务边界。我现在的工作流是让 Codex 干那些重复性强、有明确验收标准的活比如补测试、改格式、写脚手架、批量重构凡是涉及架构决策、安全校验、核心逻辑一定自己动手。你把它当成一个效率极高的实习工程师而不是一个可以全权托付的架构师。还有一点值得强调Codex 的输出一定要审尤其是改动文件后的 diff 审阅这一步省不得。我最初用 Codex 时图省事让它改完就提交结果有一次它在代码里引入了一个只在 Windows 下出现的文件路径硬编码问题测试没覆盖到上线才暴露。从那以后我对 Codex 的改动一律过一遍git diff这个习惯至今没变也建议你从一开始就养成。最后再分享一个小技巧Codex 的 REPL 里有个/undo命令可以在它做了一组修改后快速撤销最近一次操作。这个命令比手动git checkout更精准它只回退 Codex 刚才那轮对话涉及的文件改动不影响你自己提交的内容。我在让它多轮改代码时经常用这个命令做精细回退比全部git checkout安全得多。把这个命令记下来你在 Windows 上踩坑的次数会少很多。
