★ FEATURED ARTICLE 想给 Codex 装个汉化包结果网上一搜同一个关键词能搜出三种完全不同的东西VMware Workstation 汉化包、某款游戏补丁、还有真能改 Codex 界面的语言包。就算运气好找到了后者下载下来也可能装不上。我见过太多人最后卡在这一步原因几乎都是同一个——他们根本没搞清楚自己装的 Codex 是哪个客户端。Codex 在国内社区里被笼统叫做“客户端”的东西实际上至少分成命令行工具、IDE 扩展、第三方打包版这三种形态。它们虽然共用同一个名字安装位置、文件结构、语言文本存放的位置完全不一样。这也就是为什么别人能用的汉化包到你手里不是找不到文件就是覆盖完整个程序直接罢工。与其继续白费力气不如先花十分钟把这个问题想清楚再决定汉化包怎么下载、怎么装。1. 汉化前先分清Codex 的几种客户端形态与语言文件位置1.1 三个长得完全不像的“Codex 客户端”先说最常见的形态终端命令行版。打开终端敲codex进入一个全屏的 TUI 操作界面可以新建会话、切换模型、看代码 diff。这个是官方主推的方向也是目前网上“Codex 使用教程”“Codex 接入 DeepSeek”这类文章里的主角。绝大多数人装的都是它安装方式一般是一条 npm 命令。第二种是 VS Code 扩展。安装后在编辑器侧边栏里多出一个面板可以选中代码直接问问题也能让它跑命令改文件。这个形态不依赖终端界面是典型的图形化面板。它的语言文本嵌在扩展的编译产物里跟命令行版完全不是一个文件结构。第三种是第三方整合包或“绿色汉化版”。有些作者会把官方命令行版连同一个汉化文件、启动脚本打包在一起甚至再套一层独立窗口做成“下载解压就能用”的形态。搜索“Codex 汉化包”时出来的结果里这种整合包占了很大比例。它的问题在于你不知道作者打包时用了哪个版本、改过哪些文件、有没有往里面塞额外的东西。其实还有第四种容易混淆的ChatGPT 网页里的 Codex 面板。它也叫 Codex但它只是网页上的一个功能不存在“下载安装”这回事。如果搜教程看到有人让你登录 ChatGPT 网页去汉化那多半是答非所问直接跳过。1.2 界面语言到底存在哪里要理解汉化包为什么不能通用得先搞清楚一个事实Codex 的界面语言不是像传统软件那样放在独立的 locale 文件里统一管理的。对于命令行版它的英文提示文本直接写死在编译后的 JS 文件里。所谓汉化包本质上就是别人把这些英文提示替换成中文后重新打包的一份文件下载回来后你把它覆盖到对应目录界面文字才会变中文。但这里有个非常容易误会的点汉化包只能改界面文字改不了模型回复的内容。你装完汉化包Codex 的按钮、菜单、提示会变中文但模型照样可能用英文回答你。因为回复内容是模型生成的并不在你的安装目录里。想要“全面中文化”除了装汉化包还得同时设置系统指令让模型用中文回复有些人光装汉化包然后抱怨“怎么还是英文”其实是没有搞清楚这一层划分。1.3 版本号是汉化包的“生死线”Codex 的更新节奏很快npm 上openai/codex的版本号经常变。每次代码调整编译产物里的字符串位置、文件名都可能变化。一个针对 v0.10 做的汉化包拿去覆盖 v0.17十有八九会启动失败或者出现“找不到模块”之类的报错。所以下载汉化包之前第一件事永远是打开终端执行codex --version把版本号记下来。去找汉化包的时候只找写明支持这个版本的资源。没有写明版本的汉化包一律当它不匹配来处理。2. 用一条命令/一个目录判断你手里的 Codex 属于哪类2.1 最直接的判断方法看启动方式就行。如果你是通过终端敲codex命令启动的那就是官方命令行版如果你是打开 VS Code 点侧边栏图标启动的那就是扩展版如果你双击一个桌面图标或者某个独立程序窗口启动的那大概率是第三方整合包。这里我有张对照表基本覆盖了绝大多数情况判断维度官方 Codex CLIVS Code 扩展第三方整合包启动入口终端敲codex编辑器侧边栏图标独立窗口或快捷方式安装目录npm 全局 node_modules~/.vscode/extensions下 openai 目录你解压到的任意文件夹语言文件位置安装目录内的 dist 文件里扩展目录内的 dist JS 文件里取决于作者怎么打包配置文件位置~/.codex/config.toml同样是~/.codex/config.toml可能被改过路径如果还不确定就去看配置文件。命令行版和扩展版都会在用户目录下生成.codex文件夹里面一般有config.toml和auth.json。第三方整合包为了保护它的运行环境经常会把这两个文件放到它自己的目录里这也算一个识别特征。2.2 命令行版的定位命令用这两个命令很快就能定位到安装位置which codex npm root -g在 Windows 上把which换成where codex然后再执行npm root -g拿到 npm 全局目录后命令行版的安装目录就是npm root -g下面的openai/codex。进到这个目录看里面的package.json里的version字段就能确认自己当前跑的版本。这个目录里通常会有bin、dist等子文件夹。语言文本就浓缩在dist里的编译文件里。老版本可能直接在dist/index.js里新版可能拆成多个 chunk 文件。汉化包要覆盖的就是这整个dist目录而不是某一个单独文件。2.3 扩展版的定位与风险扩展版在 VS Code 的安装目录下每个扩展一个文件夹。查看方式ls ~/.vscode/extensions | grep -i openai会看到一个类似openai.chatgpt-x.x.x或者openai-codex-x.x.x的目录。语言文本在它内部的dist目录中。注意扩展目录名里带版本号如果你手动换了里面内容但目录名还是旧版本号VS Code 加载时可能识别异常。这是很多扩展汉化失败的原因之一。另外VS Code 默认会自动更新扩展。就算你汉化成功了某天它自己悄悄更新汉化内容就全没了。这种情况不是你的操作问题是更新机制导致的。后面我会专门说怎么避免。3. Codex CLI 汉化包的下载、替换与验证以官方 npm 版为例3.1 先泼盆冷水没有官方汉化包只有社区产物官方目前没有内置中文界面更没有官方发布的“中文汉化包”。你能在网上找到的全部是个人或社区维护的产物。这就意味着来源很重要。我的下载顺序建议是优先去 Codex 相关开源社区的 GitHub Release 页面找找那种明确写了“支持版本号”的压缩包其次是有明确版本说明的技术博客附件。搜索引擎首页那些带着“官方”字样、或者弹窗引导下载的站点我基本不碰。常见干扰项包括假下载站、旧版广告页、甚至捆绑了其他软件的一键安装器。还有一个经验一个合格的 Community 汉化包通常以压缩包形式提供里面是dist目录或语言文件的替换清单。如果某个自称汉化的包是一份几百 MB 的独立安装器那你下载的不是补丁是一个整合包。整合包不是不能用但你要清楚自己选择了什么。3.2 找到安装目录并完整备份不管你决定怎么汉化第一步永远是备份。先执行npm root -g cd $(npm root -g)/openai/codexWindows 上执行npm root -g cd (npm root -g) \openai\codex然后备份整个openai/codex目录不要只备份你以为的语言文件。因为实际操作中你很难判断汉化包到底会改动哪些文件整个目录一起备份是最稳妥的。备份命令cp -r $(npm root -g)/openai/codex ~/codex-backup-$(date %F)备份目录跟原目录完全分开放到用户主目录或桌面别放进原目录里否则覆盖时会被一起处理。3.3 覆盖、回滚与验证汉化包的安装方式取决于包的类型。如果是覆盖型压缩包解压后你会看到里面同样有dist目录或bin目录把它解压后的内容整体复制到openai/codex目录里覆盖同名文件即可。覆盖时注意别把原目录里不在汉化包里的文件删掉正确的操作是“把包里的文件拷进去”而不是“把原目录清空再解压”。验证分两步。第一步看版本codex --version如果这个命令能正常返回版本号说明基础结构没坏。第二步启动codex随便问一个中文问题观察界面提示是否变成了中文、会话是否正常创建。如果启动时报错或者命令直接不存在了不要慌用备份恢复。最干净的做法其实是直接用 npm 重装一个同版本官方包npm install -g openai/codex原来的版本号然后把你手动覆盖过的目录清理掉让 npm 重新生成一个全新的实例。比手动把备份目录移回去更省心因为 npm 包的权限和软链接结构是 npm 安装时生成的手动还原容易留下隐患。3.4 不想动文件改配置让 Codex 说中文如果你想要的“汉化”其实只是让 Codex 用中文回复你那根本不需要动安装目录里的任何文件。Codex CLI 的配置文件在~/.codex/config.toml在里面加两行model gpt-4.1 instructions 你叫 Codex是一名资深编程助手。请始终使用简体中文回复代码注释和 git 提交信息也使用中文。保存后重启codex模型就会一直用中文回答。这个方案的好处是不碰程序文件、不担心版本匹配、升级 Codex 也不会失效因为 instructions 字段是官方支持的配置项。如果你还配了第三方模型比如 DeepSeek可以在同一个配置文件里加独立的 provider[model_providers.deepseek] name deepseek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api responses然后回到[model]部分把model_provider指过去。这属于配置层面的玩法跟汉化包是两条路但很多人最后都会走到这里所以顺带提一下。4. IDE 扩展与第三方 GUI 版的汉化套路跟 CLI 完全不同4.1 VS Code 扩展汉化的复杂与脆弱扩展版的汉化方式完全不同。先找到扩展目录ls ~/.vscode/extensions | grep -i openai备份整个扩展目录然后找到语言文本所在的dist文件。由于语言字符串是直接编译进 JS 里的社区汉化几乎都是直接修改dist/extension.js或者 vendor chunk 里的英文字符串。实际操作时你很难手动在压缩混淆过的 JS 里逐个改字符串所以靠谱的用法是找已经处理好的汉化版dist文件整个目录覆盖过去。覆盖后一定要重启 VS Code 窗口并确认扩展没有在“扩展”页里被标记为损坏。这里有个最常见的坑VS Code 的扩展更新默认开启。今天汉化好明天它自己更新到新版本汉化就没了。想锁版本保守做法是先在 VS Code 设置里把extensions.autoUpdate关闭然后手动忽略 Codex 扩展的更新提示。扩展目录里的package.json也可以改但扩展目录是 VS Code 管理的改坏会导致扩展加载异常新手不建议乱动。如果你的目的是日常使用我个人更推荐放弃扩展汉化直接用“改 config 让回复说中文”的办法。扩展面板里的英文按钮其实没几个真正影响效率的是它回复你的语言。4.2 第三方 GUI 版完全看作者怎么打包第三方 GUI 版没有统一套路因为它可能基于 Electron、Tauri、PyQt 或者干脆只是套了一个网页壳。不同打包方式决定了语言文件在哪个位置。Electron 打包的语言文件可能在resources/app.asar里。想汉化需要先解包npx asar extract app.asar app改完里面的语言文件或界面资源后再重新打包npx asar pack app app.asar这套操作对普通用户来说门槛偏高。而且很多第三方 GUI 版并不支持这种“语言包式”的汉化因为作者把语言直接编译进了主程序里。遇到这种情况你能做的只有“换一个汉化完全的版本”没有别的办法。所以我一直觉得第三方 GUI 版不是汉化的好对象。你有能力解包替换不如直接用官方 CLI还能少一层供应链风险。4.3 第三方整合包的真实风险不少人下载汉化包时拿到的是“汉化版完整客户端”也就是整合包。这类包最大的问题是有三一是版本旧。作者打包的时间决定了他内置的 Codex 版本很可能比官方新版落后不少。你装了整合包等于拒绝了后续一切安全修复和功能更新。二是捆绑。少数整合包会夹带私货比如额外的启动程序、修改配置文件的脚本、甚至挖矿组件。直接双击运行前先打开它的启动脚本比如start.bat看看里面写了什么是基本的自我保护。看到启动脚本里调用异常端口或下载远程文件立即删除。三是杀毒误报。汉化包频繁操作可执行文件和 JS 文件容易触发杀毒软件告警。这不是说告警就一定有鬼但你要有基本判断力优先选择有开源历史、有人维护的汉化项目。5. 汉化安装后的高频报错登录、组织设置与端点请求逐一排查5.1 登录不上和组织设置加载失败安装完汉化包后如果出现“登录不上”先别急着怀疑汉化包它和汉化基本没关系。Codex 的登录走 OAuth浏览器弹窗授权成功后CLI 会收到回调。常见失败原因有几个浏览器弹窗被拦截授权页根本没打开授权完成后浏览器正常跳转了但 CLI 窗口被遮挡没注意到回调确认旧的登录凭证和新的 OAuth 过程冲突~/.codex/auth.json里存着过期的 token。处理办法很直接先备份auth.json再删掉它重新执行codex login。如果是在公司网络或代理环境下登录还要确认 OAuth 回调地址没有被拦截。“无法加载组织设置”是另一个出现频率很高的报错。它跟你登录用的账号有关系个人账号和 ChatGPT 账号在 Codex 里对组织设置的加载权限不同还有一个可能是config.toml里写了一个不存在的组织 ID。检查配置时把组织相关字段先注释掉看报错是否消失能快速定位是哪份配置写坏了。5.2 端点请求报错与本地代理的边界Codex 运行日志里有一种报错cc switch local proxy failed while handling codex endpoint /responses。看关键词是请求/responses这个接口时Codex 切换本地代理失败。这种问题在装了汉化包后偶尔会被误认为是汉化导致的其实两者没有直接关系。常见原因是你在config.toml或系统环境变量里设置了HTTP_PROXY/HTTPS_PROXY但这些代理服务并没有真正监听你填写的端口。排查步骤很简单先看看这两个环境变量和 config 里的代理字段确认端口号是否是正在运行的本地服务端口。如果不需要代理就把这些配置全部清掉再重启 Codex。要特别说明的是代理在这里是一个中性的技术概念本地调试、企业内网访问都可能用到。配置正确与否决定了/responses请求能不能正常到达服务端。它不是汉化包的锅单独排查就好。5.3 乱码与终端编码问题汉化装好后最常见的“假故障”是乱码。终端里中文显示成方块或者问号不是你汉化包有问题而是终端编码和文件编码不一致。Codex 的汉化文件基本是 UTF-8 编码。但 Windows 默认的旧式控制台代码页可能是 GBK936两者对不上就乱码。解决办法是换用 Windows Terminal 作为终端环境或者在旧终端里手动切换chcp 65001另外编辑 config.toml 或汉化相关 JSON 文件时别用 Windows 自带的记事本去改它容易把文件另存成带 BOM 的格式或保存成 GBK导致 Codex 解析失败。用 VS Code 或任意现代文本编辑器保持编码为 UTF-8能避开大部分这类问题。5.4 版本错位导致的启动失败这一条特别典型。你下载的汉化包是给 v0.13 做的而你装了 v0.18覆盖后一执行codex直接提示找不到模块或者秒退。原因不复杂新版本把一部分代码拆成了新文件而旧汉化包里的文件结构还停留在老版本。覆盖后新版要加载的文件没了自然启动失败。这时候不要继续在混乱的文件结构里修补直接重装同版本官方包最干净npm install -g openai/codex0.18.0装完后重新确认版本再去找匹配的汉化包。版本号不是接近而是必须一致汉化包的说明里写了支持 v0.18你的就是 v0.18这样才稳妥。6. 我的最终建议先让 Codex 说中文再决定要不要汉化界面6.1 界面文案其实很少别高估它的影响用 Codex 命令行版一段时间后你会发现TUI 界面本身只有那几行提示对话列表、模型切换、按键说明、退出确认。真正每天都在面对的反而是它给你的回复内容、代码 diff、commit 信息。这些内容用 interface 汉化是管不到的。所以我现在的做法是不动安装目录不碰汉化包只在~/.codex/config.toml里写清楚“请始终使用简体中文回复”然后在工作区根目录放一个AGENTS.md里面写“本项目所有注释、提交信息、回复请使用简体中文”。Codex 在读取项目时会把AGENTS.md作为辅助指令带进上下文模型就会持续用中文工作。这套方案对命令行版、扩展版都有效也是我觉得性价比最高的“软汉化”。6.2 如果你还是想装汉化包记住三个原则第一先验证自己属于哪个客户端类型再看对应的汉化说明第二下载时认准 GitHub 或技术社区的 release 产物警惕一键安装器和整合包第三每次操作前完整备份版本升级后主动重装不要让旧汉化残留文件继续混在新版目录里。6.3 再分享一个小技巧日常使用命令行版时我会把一些高频指令写成一个 shell 函数放在配置文件里。比如让 Codex 在新建会话时自动读一个工作区说明文件这样每次进入项目界面“看起来”是英文但所有生成内容都是从中文语境里产出的。时间久了你会觉得真正的“汉化”不是把几个按钮翻译过来而是让 Codex 在你熟悉的中文语境里正常工作。至少对我而言这条路比折腾汉化包省心得多。
阅读完成 · 觉得有帮助？
