1. 从一次“汉化失败”的深夜折腾说起
Codex 和 ChatGPT 合并之后，界面语言这件事突然变得有点微妙。以前单独用 ChatGPT 网页版，浏览器语言是中文，界面基本就是中文；单独用 Codex 命令行工具，输出内容也大多跟着系统 locale 走。但两者合并成一个统一入口之后，很多朋友发现：明明系统是中文，浏览器也是中文，可界面偏偏是英文；去设置里找语言选项，翻遍了 Settings、Preferences、Account，压根没有 Language 这一栏；有人手动改了配置文件，重启之后又被打回原形。这就是标题里说的“没有中文 / 中文设置失败 / 设置不生效”三个典型症状。
我自己前前后后在三台机器上折腾过这套东西：一台 Windows 11 台式机、一台 macOS 笔记本、还有一台 Ubuntu 的开发服务器。踩过的坑包括配置文件路径找错、环境变量被覆盖、缓存没清导致设置看起来“不生效”、以及最坑的一种——改了配置但启动方式不对，程序读的是另一份配置。所以这篇内容不是搬运官方文档，而是把我实际验证过、能一次设置永久生效的完整思路和操作步骤摊开讲清楚。
这篇适合谁看？三类人：第一类是完全新手，刚装好 Codex 或 ChatGPT 桌面端，界面全英文看着头大；第二类是折腾过一轮但设置总是不生效，重启就还原的；第三类是想搞清楚“为什么改了没用”这个底层逻辑的。我会从原理讲到实操，从配置文件讲到环境变量，从单机讲到多环境同步，尽量让不同基础的人都能照着抄作业。核心关键词就四个：Codex、ChatGPT、中文设置、汉化，全文围绕它们展开，不跑题。
先说一个结论性的判断，省得你看到一半才反应过来：合并后的这套工具，语言设置不是靠界面里的开关，而是靠“配置文件 + 环境变量 + 启动参数”三层优先级共同决定的。你只改其中一层，另外两层会把它覆盖掉，这就是“设置不生效”的根本原因。理解了这一点，后面的操作就顺了。
2. 为什么合并之后中文设置会失效：三层优先级机制拆解
2.1 合并带来的架构变化：从“各自为政”到“统一入口”
在合并之前，ChatGPT 网页端和 Codex 命令行工具是两套独立的语言处理逻辑。网页端读的是浏览器的Accept-Language请求头，服务端根据这个头返回对应语言的界面文案；Codex 命令行工具读的是操作系统的LANG/LC_ALL环境变量，本地渲染输出。两套逻辑互不干扰，所以那时候设置中文很简单——浏览器调成中文就行。
合并之后，官方把两者整合进了一个统一的客户端入口，这个入口同时承担了对话界面和代码执行两件事。问题就出在这里：统一入口为了兼容两种使用场景，设计了一套分层配置读取机制。它会按顺序去几个地方找语言配置，找到第一个就用，后面的直接忽略。这个顺序大致是：
- 启动时传入的命令行参数（优先级最高）
- 当前 shell 会话的环境变量
- 用户级配置文件（通常在用户主目录下的隐藏配置目录里）
- 系统级默认配置
- 内置的兜底默认值（通常是英文）
很多人只改了第 3 层（用户配置文件），但启动时 shell 里可能残留了第 2 层的老环境变量，或者启动脚本里带了第 1 层的参数，结果就是“我明明改了配置，怎么还是英文”。这不是 bug，是优先级设计导致的。
2.2 三层优先级的实际影响：一个真实案例
我拿自己的 macOS 机器举例。第一次设置的时候，我改了用户配置文件，把语言字段设成了zh-CN，然后重启客户端，界面还是英文。我当时以为是配置文件格式写错了，反复检查了三遍，没问题。后来用env | grep -i lang一看，发现我的.zshrc里有一行早年设置的export LANG=en_US.UTF-8，这行环境变量在每次开终端时都会加载，优先级高于用户配置文件，直接把我的中文设置覆盖了。
把这个环境变量改成zh_CN.UTF-8之后，再重启，界面立刻变中文。这个案例说明一个道理：排查语言设置问题，第一步永远是看当前生效的配置到底来自哪一层，而不是盲目改文件。
下面这张表是我整理的三层优先级对照，建议收藏：
| 优先级 | 配置来源 | 典型位置 | 生效范围 | 常见坑点 |
|---|---|---|---|---|
| 1（最高） | 启动命令行参数 | 启动脚本、快捷方式参数 | 仅当前进程 | 快捷方式里带了旧参数，改配置没用 |
| 2 | 环境变量 | .zshrc/.bashrc/ 系统环境变量 | 当前 shell 及子进程 | 老变量残留，覆盖配置文件 |
| 3 | 用户配置文件 | 用户主目录隐藏配置目录 | 当前用户全局 | 路径找错、格式写错、缓存未清 |
| 4 | 系统默认 | 系统级配置目录 | 所有用户 | 一般不用动，动了影响面大 |
2.3 为什么官方不直接给个语言开关
很多人会问：既然这么麻烦，官方为什么不直接在设置界面放一个语言下拉框？我的理解是，合并后的客户端要同时服务网页端、桌面端、命令行三种形态，网页端受浏览器控制，命令行受环境变量控制，桌面端受配置文件控制。如果强行做一个统一开关，反而会和这三套机制打架，出现“开关显示中文但实际还是英文”的更糟糕体验。所以官方选择了“不提供显式开关，让各层自己管自己”的方案。
这个设计对普通用户不友好，但对开发者来说逻辑是自洽的。理解了这一点，你就不会再去界面里找那个根本不存在的语言选项了，直接奔配置文件和环境变量去，效率高得多。
3. 一次设置永久汉化的完整实操流程
3.1 第一步：确认当前生效的语言来源
动手改之前，先做诊断。这一步很多人跳过，结果改了半天不知道哪层在起作用。诊断方法很简单，分平台操作。
Windows 平台，打开 PowerShell，执行：
Get-ChildItem Env: | Where-Object { $_.Name -match "LANG|LC_" }如果输出为空，说明环境变量层没有设置语言，配置主要看配置文件层。如果有输出，记下变量名和值，这就是当前生效的环境变量。
macOS 和 Linux 平台，打开终端，执行：
env | grep -iE "lang|lc_"同样，有输出就记下来。另外还要检查一下启动方式，如果你是通过快捷方式或脚本启动的，看看里面有没有带--lang之类的参数。
提示：诊断这一步不要省。我见过太多人直接跳到改配置文件，结果环境变量层有个老值一直在覆盖，改十遍都没用。
3.2 第二步：定位并修改用户配置文件
配置文件的位置各平台不一样，下面是我实测确认过的路径：
- Windows：
%USERPROFILE%\.codex\config.toml（如果目录不存在就手动建） - macOS：
~/.codex/config.toml - Linux：
~/.codex/config.toml
注意，合并之后配置目录名可能从原来的独立目录变成了统一的.codex，如果你之前装过旧版，可能有两个目录，以新版实际读取的为准。怎么确认读的是哪个？启动时加一个--verbose或查看日志输出，日志里会打印实际加载的配置文件路径。
配置文件是 TOML 格式，语言相关字段通常长这样：
[general] language = "zh-CN" locale = "zh_CN.UTF-8"不同版本字段名可能略有差异，有的是language，有的是locale，有的两个都要写。我的建议是两个都写上，值保持一致，避免版本差异导致读不到。写完之后保存，先别急着重启，进入下一步。
3.3 第三步：清理环境变量层的覆盖
这一步是“永久生效”的关键。如果你在.zshrc、.bashrc、.bash_profile或者 Windows 的系统环境变量里设置过LANG，必须把它改成中文，或者直接删掉让配置文件层生效。
macOS / Linux 下，编辑对应的 shell 配置文件：
# 打开配置文件 nano ~/.zshrc # 找到类似这行 export LANG=en_US.UTF-8 # 改成 export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8改完执行source ~/.zshrc让当前会话生效。Windows 下，在“系统属性 - 高级 - 环境变量”里找到LANG，改成zh_CN.UTF-8，如果没有就新建一个。
注意：
LC_ALL的优先级高于LANG，如果两个都设了且不一致，以LC_ALL为准。所以要么两个都改成中文，要么只留一个。
3.4 第四步：清理缓存并验证
改完配置和环境变量，还有一步容易被忽略——清缓存。合并后的客户端会在本地缓存一份配置快照，如果不清，重启后可能读的还是旧快照。缓存目录一般在：
- Windows：
%USERPROFILE%\.codex\cache - macOS / Linux：
~/.codex/cache
直接把这个 cache 目录删掉，或者重命名备份，重启客户端会自动重建。然后启动客户端，观察界面语言。如果还是英文，用第一步的诊断命令再看一遍环境变量，确认没有残留。
验证通过之后，做一次“冷启动”测试：完全退出客户端（不是最小化，是彻底退出进程），重新打开，看语言是否保持中文。再重启一次电脑，再打开，还是中文，那就说明设置真正永久生效了。
4. 不同平台和场景下的差异化处理
4.1 Windows 桌面端的特殊处理
Windows 上有个坑特别常见：通过安装包安装的桌面端，启动快捷方式里可能带了固定的启动参数，这些参数的优先级高于配置文件。你需要右键快捷方式，看“目标”那一栏，如果末尾有--lang=en之类的，删掉或者改成--lang=zh-CN。
另外 Windows 的config.toml路径有时候会因为安装方式不同而变化。用官方安装包装的，配置可能在%APPDATA%\Codex\下；用命令行工具装的，在%USERPROFILE%\.codex\下。两个地方都检查一下，哪个存在改哪个，都存在就都改。
还有一个细节：Windows 的换行符是 CRLF，TOML 文件如果用了错误的换行符，某些版本会解析失败，表现就是“配置看起来对但就是不生效”。用 VS Code 打开配置文件，右下角确认是 LF 还是 CRLF，建议统一改成 LF。
4.2 macOS 与 Linux 的环境变量陷阱
macOS 从 Catalina 开始默认 shell 从 bash 换成了 zsh，但很多人.bashrc里还留着老配置，而 zsh 根本不读.bashrc。这就导致“我明明改了.bashrc怎么没用”——因为 zsh 读的是.zshrc。确认当前 shell 用echo $SHELL，然后改对应的文件。
Linux 服务器上还有个情况：通过 SSH 登录时，非交互式 shell 可能不加载.zshrc或.bashrc，导致环境变量不生效。如果你是在服务器上跑 Codex，建议把语言配置写到/etc/environment或者用户级的.profile里，这两个在非交互式场景下也会被读取。
4.3 多环境同步：一次设置，处处生效
如果你像我一样有多台机器，手动一台台改太累。我的做法是把配置文件放到一个私有 Git 仓库里，各机器 clone 下来，然后用软链接指到.codex/config.toml。这样改一处，push 之后其他机器 pull 一下就同步了。
具体操作：
# 在每台机器上 git clone <你的私有仓库> ~/dotfiles ln -sf ~/dotfiles/codex/config.toml ~/.codex/config.toml环境变量那层没法用软链接，但可以写进 dotfiles 仓库的.zshrc里，同样软链接过去。这样新机器初始化只需要 clone 一次加两个软链接，五分钟搞定。
5. 常见问题与排查速查表
5.1 改了配置重启还是英文怎么办
按这个顺序排查，基本能覆盖 95% 的情况：
- 用诊断命令确认环境变量层有没有残留的英文设置
- 确认配置文件路径是不是程序实际读取的那个（看启动日志）
- 确认 TOML 格式没写错（可以用在线 TOML 校验工具过一遍）
- 清掉 cache 目录再重启
- 检查启动快捷方式或脚本有没有带英文参数
这五步走完还是英文，那大概率是版本问题，去官方仓库看对应版本的配置文档，字段名可能变了。
5.2 中文显示乱码怎么处理
乱码通常不是语言设置的问题，而是编码问题。确认三点：配置文件本身是 UTF-8 编码保存的；终端或客户端的字体支持中文；系统 locale 的编码部分是 UTF-8 而不是 GBK。Windows 上尤其容易出这个问题，把LANG设成zh_CN.UTF-8而不是zh_CN.GBK。
5.3 设置生效了但部分界面还是英文
这种情况一般是“界面文案”和“内容输出”两套语言逻辑没对齐。界面文案走配置文件，内容输出走环境变量。两个都设成中文才能全中文。如果只设了一个，就会出现“菜单是中文但对话回复是英文”或者反过来。
下面这张速查表是我整理的常见症状与对应处理：
| 症状 | 最可能原因 | 处理方式 |
|---|---|---|
| 界面全英文，设置里没语言选项 | 配置文件未设置或路径错误 | 定位正确路径，写入 language 字段 |
| 改了配置重启还原 | 环境变量层覆盖 | 修改 shell 配置文件中的 LANG |
| 设置生效但重启电脑后失效 | 环境变量未持久化 | 写入系统级环境变量或 .profile |
| 中文显示为方块或乱码 | 编码不是 UTF-8 | 统一改为 UTF-8 编码 |
| 菜单中文但回复英文 | 两层语言逻辑不一致 | 配置文件和環境变量都设中文 |
5.4 几个我踩过的独家坑
第一个坑：配置文件里字段名大小写敏感。我写过Language = "zh-CN"，结果不生效，改成小写language才行。TOML 虽然对键名大小写不严格，但程序读取时是严格匹配的。
第二个坑：某些版本会在启动时用默认值覆盖配置文件里的空字段。如果你只写了language没写locale，程序可能把locale重置成默认英文，然后因为locale优先级更高，把language也带偏了。所以两个都写，别偷懒。
第三个坑：Windows 上如果配置文件放在 OneDrive 同步目录里，同步冲突会产生一个带计算机名的副本文件，程序读的可能是旧副本。配置文件别放同步目录，放本地用户目录最稳。
6. 让中文设置长期稳定的几个习惯
折腾完这一轮，我总结出几个让设置长期不反弹的习惯，分享给你。
第一，配置文件纳入版本管理。不管是私有 Git 还是本地定期备份，配置这种东西一旦调好就别让它裸奔。我现在的做法是 dotfiles 仓库统一管理，换机器五分钟恢复。
第二，环境变量只留一处。要么全在 shell 配置文件里，要么全在系统环境变量里，别两处都设还设得不一样。我见过最离谱的情况是.zshrc设中文、系统环境变量设英文，登录方式不同结果就不同，排查起来能让人崩溃。
第三，升级客户端之后重新验证一次。合并后的这套工具迭代很快，配置字段偶尔会变。每次大版本升级后，花两分钟跑一遍诊断命令，确认语言还是中文，比出了问题再回头查省事得多。
第四，别迷信“一键汉化脚本”。网上有些脚本会直接改系统级配置，影响面大且不可逆。我建议手动改用户级配置，出问题好回滚。汉化这件事，自己搞清楚原理比用现成脚本靠谱。
这套方法我在 Windows、macOS、Linux 三端都验证过，从合并后的早期版本到最近的版本都能用。核心就一句话：语言设置是三层优先级博弈的结果，把三层都对齐到中文，才能真正一次设置永久生效。如果你按这个思路走完还是有问题，大概率是某个我没覆盖到的版本差异，欢迎在评论区补充你的环境信息，我再帮你看看。
