折腾了一晚上终于把 Windows 下的 VSCode Codex 插件 中转站 API 给调通了。本来以为只是装个扩展、填个 Key 的事结果又是乱码又是权限又是自动确认中途差点想放弃。这篇东西就是把我踩过的坑和最终验证通过的配置方式整理出来给同样在 Windows 上用 Codex 插件的朋友一个参考。如果你已经装了 Codex 插件但一直卡在连接、乱码、权限上面可以直接跳到对应章节抄作业如果还没装我建议从第 1 节顺着读装好之后再看后面的配置。1. 准备工作先把 Codex 插件请进 VSCode1.1 Codex 插件能干嘛为什么值得折腾Codex 是 OpenAI 出的编程代理工具和普通聊天式代码补全不太一样。它不只是给你生成一段代码让你自己粘而是可以直接读你的项目文件、执行命令、改代码、跑测试相当于在编辑器里雇了一个能真正动手干活的 AI 结对程序员。在 VSCode 里装好插件后侧边栏会多一个 Codex 面板你可以直接在里面下指令比如“帮我看看这个报错”、“给这个函数补单元测试”、“把日志改成中文输出”它会基于当前工作区实际执行操作。在 Windows 上折腾它比 Mac/Linux 稍微麻烦一点主要是编码和权限这两个历史遗留问题。但只要把基础配置理顺日常用的体验其实是能很顺的。这一节先把安装和依赖讲清楚。1.2 安装 Codex 插件前需要准备什么Codex 官方现在同时提供 CLI 和 VSCode 插件两种形态。插件依赖底层 CLI 能力所以即使你只打算用界面通常也建议把 CLI 装好这样排错会更方便。安装 Node.js LTS。Codex CLI 基于 Node.js 跑去官网下 Windows 安装包一路 Next 就行。装完在 PowerShell 里执行node -v能显示版本号就说明没问题。安装 Git for Windows。虽然用 Codex 不一定要操作 Git但插件在处理工作区文件时经常需要 shell 环境Git 自带的 bash 有时能帮你避开 PowerShell 的脚本执行策略问题。打开 VSCode 扩展市场搜索“Codex”注意看发布者信息选 OpenAI 官方的扩展安装。装完会提示重新加载窗口照做。装完之后如果你还想用命令行方式验证中转站 API可以在普通终端里试一下codex --version如果提示codex不是内部或外部命令多半是 Node.js 的全局 bin 目录没在 PATH 里。去系统环境变量看一眼把%APPDATA%\npm加进用户变量 PATH再重开一个终端。1.3 先别急着填 Key想清楚你的接入方式Codex 插件默认会找官方账号或官方 API Key。我们这里要换成中转站 API实际上就是告诉它两件事接口地址变成什么认证用的 Key 变成什么。搞清楚这一点后面所有配置都围绕这两个变量展开。所以建议先在记事本里记下你的中转站 Base URL 和 API Key后面会用很多次。如果对自己的网络环境和支付渠道没把握中转站是很多 Windows 开发者的选择。但要注意中转站本质是第三方代理服务一定要选稳定、口碑好的服务商并且不要把 Key 写进公开仓库。免费渠道往往不稳定容易影响排查心情。2. 中转站 API 配置参考让 Codex 走你的接口2.1 中转站 API 到底是个什么东西简单说中转站 API 就是一个兼容 OpenAI 接口格式的 HTTP 服务地址。你在代码或工具里填的 Base URL 不是https://api.openai.com/v1而是中转站提供的地址比如https://api.someproxy.com/v1。它收到请求后会把请求转发给真正的大模型服务商再把结果原样返回。对 Windows 上的开发场景来说用中转站最大的好处是接口统一。你不用在 VSCode、CLI、脚本里分别维护不同的接入逻辑只要把 Base URL、API Key、模型名填对所有基于 OpenAI 生态的工具都能直接跑。另一个好处是有的中转站会做并发控制、用量统计、多模型路由对团队协作和日常调试比较省心。2.2 三样必填信息Base URL、API Key、模型名配置前先把这三样东西对齐缺一个都会让你后端空转。配置项作用示例Base URL接口根地址Codex 会拿它拼接/chat/completions等路径https://api.someproxy.com/v1API Key认证凭证中转站后台生成sk-xxxxxxxx模型名指定使用的模型得是中转站支持的名字gpt-4o-mini注意有些中转站给的模型名可能和官方不完全一致比如带-prefix或渠道标识。那一串名字一定要以中转站后台的说明为准填错了会报model not found。2.3 VSCode 扩展侧的设置参数Codex 插件在不同版本里可用的配置项命名不完全一样但核心思路是设置 Base URL 和 Key。打开 VSCode 命令面板执行Preferences: Open User Settings (JSON)在settings.json里加一段{ codex.apiKey: sk-你的中转站key, codex.baseUrl: https://你的中转站地址/v1, codex.model: gpt-4o-mini, codex.autoApprove: false }如果你的 Codex 插件版本版本比较新可能不是用codex.apiKey这种字段而是统一读取环境变量。遇到这种情况可以先在设置里搜codex看看有没有相关条目如果没有直接看下一节的环境变量方案那个是相对通用的办法。这里特别提醒一句很多插件是先用 Base URL 拼接出完整的请求地址。有些人把 Base URL 填成带/chat/completions的完整接口导致后面重复拼接变成/v1/chat/completions/chat/completions报 404。Base URL 通常只要填到/v1这层。2.4 环境变量配置法CLI 和插件通用如果插件不认上面的 JSON 字段或者你想让 Codex CLI 和 VSCode 插件同时生效最省事的方法是配置环境变量。在 Windows 搜索框里输入“环境变量”打开“编辑系统环境变量” - “环境变量”。在用户变量里新建变量名: OPENAI_BASE_URL 变量值: https://你的中转站地址/v1 变量名: OPENAI_API_KEY 变量值: sk-你的中转站key有需要的话还可以配CODEX_MODEL但不是所有版本都认这个变量。配完之后务必关闭所有 VSCode 窗口和终端窗口再重新打开。环境变量在进程启动时读取不重启不会生效。如果你习惯用 PowerShell也可以这样设置用户级变量[Environment]::SetEnvironmentVariable(OPENAI_BASE_URL, https://your-api/v1, User) [Environment]::SetEnvironmentVariable(OPENAI_API_KEY, sk-xxx, User)设置返回成功后重开终端验证一下$env:OPENAI_BASE_URL $env:OPENAI_API_KEY能打印出你刚才填的值就说明环境变量读到了。2.5 用 curl 验证中转站接口是否真的通没有验证就直接开 Codex容易把“中转站挂了”和“插件配置错”混在一起。推荐用 curl 先打一发接口确认服务本身可用。打开 PowerShell执行curl.exe https://你的中转站地址/v1/chat/completions -H Content-Type: application/json -H Authorization: Bearer sk-你的中转站key -d {\model\: \gpt-4o-mini\, \messages\: [{\role\: \user\, \content\: \hello\}]}注意PowerShell 里curl默认是Invoke-WebRequest的别名所以最好写成curl.exe调用真正的 curl。如果返回结果里有choices字段说明中转站接口是通的问题只出在 Codex 和 VSCode 侧。如果返回 401就是 Key 不对返回 404基本是 Base URL 多了或少了路径返回其它错误建议先查中转站文档。3. 中文乱码不是 Codex 的锅是 Windows 编码问题3.1 为什么一跑起来就是“锟斤拷”和“口口口”在 Windows 上装完 Codex 插件后最让人崩溃的往往不是接口连不上而是终端里输出的中文变成一堆乱码。这不是 AI 模型的问题也不是 Codex 插件写坏了而是 Windows 的代码页和 UTF-8 字符集不匹配。Windows 中文系统默认代码页是 936GBK而现代开发工具基本上都按 UTF-8 输出。VSCode 终端在启动时默认继承系统代码页收到 UTF-8 的中文字节后却按 GBK 去解码自然就乱码了。打个比方同一串字节你用中文输入法打的“你好”换到日文编码表里就会变成完全不同的字符。Codex 生成的代码和 Shout 输出都是 UTF-8碰到 GBK 终端乱码就很正常。3.2 一招鲜让终端切到 UTF-8 代码页最简单粗暴的验证方法是在终端里敲chcp 6500165001就是 UTF-8 的代码页编号。执行后当前终端窗口就能正确显示中文了。如果你发现执行完立刻生效那说明问题确实是代码页引起。不过chcp 65001只对当前窗口有效关掉再开又会变回 GBK。要想 VSCode 终端一启动就自动执行可以在settings.json里自定义终端 profile。比如设置 Windows PowerShell 的启动参数{ terminal.integrated.profiles.windows: { PowerShell UTF-8: { source: PowerShell, args: [ -NoExit, -Command, chcp 65001 ] } }, terminal.integrated.defaultProfile.windows: PowerShell UTF-8 }保存配置后新打开的终端会自动执行chcp 65001。注意如果你改了默认 profileVSCode 的集成终端会使用这个新 profile之后的权限、环境变量、路径解析都以它为准。3.3 预防乱码的全局配置文件编码和输出编码终端代码页解决的是“显示乱码”但如果你发现 Codex 往文件里写入中文后文件打开还是乱那就是文件编码的问题。这时候去 VSCode 设置里开两个选项{ files.encoding: utf8, files.autoGuessEncoding: true }files.encoding告诉 VSCode 新文件默认按 UTF-8 保存files.autoGuessEncoding让 VSCode 在打开文件时自动猜测编码遇到老的 GBK 文件也能尽量识别。已经乱掉的文件可以按CtrlShiftP搜索Change File Encoding选择“Save with Encoding - UTF-8”再重新保存。如果你的项目里主要用 Python还建议把PYTHONIOENCODING也设置成utf-8。否则即使终端切到 UTF-8Python 的 stdout 在某些情况下还是会因为 Windows 默认 code page 输出 GBK 字节。在系统环境变量里加一条变量名: PYTHONIOENCODING 变量值: utf-8Node.js 和 Codex 本身按 UTF-8 走只要终端代码页切到 65001基本不会再出幺蛾子。3.4 Codex 面板和输出通道乱码的补充处理有时候终端是好的但 Codex 面板里的中文回复正常把代码贴进编辑器之后中文注释乱掉。这类问题基本是文件本身编码和显示编码不一致导致的。除了设置files.encoding: utf8还要检查右下角状态栏显示的文件编码。如果状态栏显示“GBK”说明这个文件是旧编码需要转存为 UTF-8。另外某些 Codex 版本在 Windows 上用的是系统默认代码页去渲染输出面板导致面板里中文正常、终端里乱码或者反过来。这种时候可以优先使用 VSCode 内置输出面板看日志别死盯着终端。日志面板通常按 UTF-8 渲染能帮你判断是请求成功但显示乱码还是请求本身就没通。4. 自动同意策略让 Codex 少问你几次4.1 Codex 的权限机制为什么要“问一下”Codex 和普通聊天机器人最大的不同是它真的会执行命令。你让它“安装依赖”它就真的去跑npm install你让它“修复这个文件”它就真的往磁盘写入内容。为了安全插件默认会在每次执行敏感操作前弹确认框。在 Windows 上这类确认弹窗会频繁打断你的思路。尤其是让 Codex 连续修改多个文件、跑测试、再重启服务每一步都要手动点一下非常痛苦。“自动同意”就是让 Codex 跳过这些确认直接执行。但这相当于你把电脑的操作权完全交给 AI风险必须心里有数。4.2 CLI 命令的自动同意参数如果你用的是 Codex CLI终端里执行代码时可以加一个--auto-approve参数codex --auto-approve这个参数的作用是让 Codex 不再对命令执行和文件写入做交互确认。但要注意某些版本支持的是-a短参数有的版本需要用--auto-approve。具体以codex --help输出为准。如果你不想每次输入参数可以修改配置文件。Codex CLI 的配置一般放在用户目录下的~/.codex/config.toml没有就手动创建然后写入[default] auto_approve true保存后重启 Codex就默认开启自动批准了。同样这个配置只针对当前用户生效比较干净。4.3 VSCode 插件里的自动同意选项在 VSCode 插件里自动同意通常可以通过设置项控制。不同版本的字段名称可能不一样常见的有两种{ codex.autoApprove: true, codex.autoApproveAllowedTools: [*] }codex.autoApprove用来打开全局自动同意codex.autoApproveAllowedTools用来限定允许自动执行的操作范围。填[*]代表所有操作都可以自动执行也可以只填部分命令白名单比如{ codex.autoApproveAllowedTools: [ Bash(git status*), Bash(npm run test*) ] }注意白名单匹配规则以插件自身实现为准。我的建议是日常对话用宽松模式但遇到需要删除文件、操作数据库、执行构建命令时还是手动确认更保险。别为了一时的痛快让 Codex 帮你把环境搞崩了。4.4 自动同意不生效的排查思路如果你开了autoApprove但还是频繁确认先检查三件事VSCode 插件版本是不是太旧有的旧版本不认codex.autoApprove字段。是否同时开着 Codex CLI 和 VSCode 插件两边权限策略互相覆盖。插件是否读取了~/.codex/config.toml有些版本优先读配置文件插件设置会被忽略。排查最快的方式是查看 Codex 输出面板。如果某个操作被拦截它会输出类似“Permission denied”的日志。把日志关键词拿到插件文档里搜比瞎猜快得多。5. 管理员权限问题Windows 下的一道坎5.1 什么时候会碰到管理员权限在 Windows 上跑 Codex最常见的权限报错场景有三类Codex 尝试向C:\Program Files、系统盘根目录等受保护目录写入文件。Codex 执行需要管理员权限的安装命令比如安装全局 npm 包、注册 Windows 服务。当前 VSCode 是以普通权限启动的但项目编译脚本里用到了需要提权的命令。这些问题本质不是 Codex 本身的问题而是 Windows 的访问控制策略。普通用户进程默认没有管理员权限碰到受保护资源就会失败。搞清楚这一点解决思路就很清晰要么让进程以管理员权限运行要么调整它要访问的目标目录权限。5.2 最直接的办法以管理员身份运行 VSCode最省事的方法是关闭所有 VSCode 窗口然后在桌面或开始菜单的程序图标上右键选择“以管理员身份运行”。这样 VSCode 以及它启动的集成终端都会带上管理员权限Codex 执行命令时就有权限访问系统级目录了。这个方法虽然简单但有两个副作用需要注意。一是管理员权限下 VSCode 打开文件会有额外安全提示部分扩展可能出现异常二是如果你同时用多个 VSCode 窗口普通权限窗口打不开管理员权限下的项目文件容易造成文件锁冲突。所以我的习惯是平时普通权限跑只有在 Codex 明确需要系统级操作时才管理员模式。5.3 给 Codex 命令单独提权如果你不想整个 VSCode 都以管理员运行也可以只针对 Codex 相关命令提权。比如在 PowerShell 里手动用管理员身份打开一个终端然后执行Start-Process codex -Verb RunAs这会让 Codex CLI 新开一个管理员权限终端。但注意这个方式打开的进程和你原来的 VSCode 工作区不一定在同一个会话里项目路径、环境变量都得重新确认。还有一种思路是在项目编译脚本里加上自动请求管理员权限的逻辑。比如脚本开头检查当前权限不足就弹出 UAC 提权。这种方式适合自己可控的 Node/Python 脚本但会破坏流程的自动化能不用尽量别用。5.4 权限、环境变量和乱码三个问题容易互相干扰我在实际排查时发现权限问题和环境变量、乱码经常纠缠在一起。比如你普通权限打开 VSCode 时设置的用户环境变量在管理员终端里不一定读不到因为后者可能加载的是系统级环境变量副本。这会导致 Codex 在管理员模式下连接中转站时提示没找到 API Key。解决方法是在中转站 API 配置阶段把OPENAI_BASE_URL和OPENAI_API_KEY同时设置到用户变量和系统变量。如果你不想污染系统变量最稳妥的做法是每次用管理员模式前在管理员终端里重新执行一次$env:OPENAI_BASE_URL https://...。虽然麻烦点但能避免权限模式和配置分离导致的莫名 401。另外管理员终端默认代码页也可能和普通终端不一样。如果同一个 Codex 命令在普通窗口不报错管理员窗口却乱码或者中文路径解析错误基本就是代码页和区域设置不一致。这时候再执行一次chcp 65001就能解决。6. 常见问题速查Windows Codex 排错备忘录6.1 高频问题对照表把这段时间里遇到过最多次的情况整理成了一张速查表遇到问题直接对着看问题现象可能原因解决动作插件装好后侧边栏没有 Codex 图标扩展未加载完成 / VSCode 版本过旧重启窗口检查 VSCode 更新提示401 UnauthorizedAPI Key 错误或中转站校验失败核对 Key确认没有多余空格提示404 Not FoundBase URL 路径多了或少了一层把 Base URL 改成以/v1结尾提示model not found模型名与中转站支持列表不一致去中转站后台查正确模型名终端中文输出乱码代码页为 GBK程序输出 UTF-8执行chcp 65001或配置默认 profile文件里中文乱码文件保存编码不是 UTF-8用Change File Encoding转成 UTF-8Codex 频繁要求确认自动同意策略未开启设置codex.autoApprove或 CLI 加--auto-approve执行命令提示权限不足当前进程没有管理员权限右键以管理员身份运行 VSCode管理员模式下找不到 API Key环境变量未在管理员会话中加载同时配置用户变量和系统变量chcp 65001后仍然乱码字体不支持中文 / 程序强制输出 GBK换终端字体检查程序编码参数6.2 一个比较隐蔽的坑Path 和终端 Profile 冲突Windows 上配置完 Codex 后还有个大坑就是 PATH 顺序和终端 Profile 冲突。如果你安装 Node.js 后又在系统变量里手动加过 PATH可能导致node命令找到的是旧版本。Codex 插件内部会优先用 PATH 里的node启动 CLI如果版本不对某些功能会表现得很奇怪比如日志里没有任何错误但请求就是不发出。排查方法是在 VSCode 集成终端里执行where.exe node如果你看到多个路径说明 PATH 里可能混着不同版本的 Node。保留一个 LTS 路径其他删掉再重新打开终端测试。6.3 给新手的最后提醒如果你刚接触 Codex建议先不要急着把所有权限放给 AI。先用普通权限跑一个简单任务比如“帮我把这段代码改成中文注释”确认编码和接口都正常。再逐步打开自动同意策略然后才考虑管理员权限。这个顺序能让你在出现问题时快速缩小排查范围。我在实际使用中最满意的组合是用户变量里配好中转站 APIVSCode 终端默认执行chcp 65001日常用普通权限跑只有在装依赖、写系统级文件时才切管理员模式。自动同意策略只对白名单命令打开删除、覆盖、安装类操作保持人工确认。这样折腾一次之后Codex 在 Windows 上基本能像在 Linux 上一样顺手。回头再看这个配置过程其实大半时间都花在 Windows 的编码和权限身上Codex 本身的配置反而非常简单。希望这篇参考能帮你少走这几个弯路把更多时间留给真正要写的代码。
