Codex desktop UI does not update language despite localeOverride=zh-CN and --lang=zh-CN

Summary

Codex Desktop does not update the app UI language according to the language selected in Settings.

The local setting is saved as localeOverride=zh-CN, and the running Electron renderer process is launched with --lang=zh-CN, but the visible UI remains in English after restart.

Environment

Codex Desktop: 26.422.21459
Codex CLI: 0.124.0-alpha.2
macOS: 26.4.1, build 25E253
Architecture: arm64
Selected language: Simplified Chinese / zh-CN

What I checked

The local global state contains localeOverride: "zh-CN".
The running Codex renderer process includes --lang=zh-CN.
The app bundle contains Simplified Chinese resources, including frontend strings such as “新聊天” and “Codex 设置”.
Restarting Codex does not change the UI language.

Suspected cause

From the bundled frontend code, UI message loading appears to be gated behind a remote feature flag named enable_i18n. If that flag is false or not fetched for this machine/account, the app still computes the preferred locale but does not pass localized messages to the UI, so it falls back to English defaults.

This would also explain why the issue only reproduces on some machines/accounts.

Expected behavior

When the user selects Simplified Chinese in Settings, Codex Desktop should render the UI in Chinese after restart or reload.

Actual behavior

The UI remains in English even though the saved setting and Electron language are both zh-CN.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

[Bug] reqwest HTTP clients missing User-Agent override → Cloudflare 403 from HKG edge on Codex Desktop 26.422.x #18456

Powered by Codex Action

I can also reproduce this in Codex Desktop.

Observed behavior:

Settings > Language shows 中文（中国） selected.
The setting label itself says this is the language for the app UI.
After fully quitting and restarting Codex, the visible app UI remains English, including settings labels such as Default open destination, Language, Prevent sleep while running, etc.
Chat responses can be Chinese, but the Codex application shell UI does not switch to Chinese.

This appears to match the original report: the language selection is saved/visible in Settings, but localized UI strings are not applied after restart.

macos 26.4 系统下，遇到过同样问题，最后发现彻底关闭Codex APP，然后开启系统全局代理，然后再打开Codex APP之后重新切换语言就有效了。原因应该是加载语言需要联网。

我也遇到了同样的问题。设置里选了中文但菜单还是英文。Codex Desktop 版本：26.513.31313 (2867)。请帮忙处理。

我也遇到了同样的问题。设置里选了中文但菜单还是英文。Codex Desktop版本：26.513.31313 (2867)。请帮忙处理。

找到了一个解决方法：

退出应用（重要）
打开 "~/.codex/.codex-global-state.json"
把 "localeOverride" 设置改成 "en-US"，然后保存
重新打开应用

I can reproduce this as well in Codex Desktop.

Observed behavior:

Settings > General > Language shows 中文（中国） selected.
The setting description says Language for the app UI.
The visible UI remains English, including the left settings sidebar (General, Appearance, Configuration, Personalization, MCP servers, etc.) and General settings labels such as Default open destination, Language, Show in menu bar, and Prevent sleep while running.
This matches the original report: the language selection is saved and displayed, but localized UI strings are not applied.

This is still reproducible as of 2026-05-18.

I’m seeing the same issue on Windows.

Environment:

Codex Desktop: 26.513.40821
Build flavor: Windows Store
OS: Windows
System locale/timezone: zh-CN / Asia-Shanghai
Selected app UI language: 中文（中国）

What happens:

Settings > General > Language is set to 中文（中国）
I fully restarted Codex after changing the language
The UI still remains in English, including Settings, sidebar items like “New chat / Search / Skills / Project”, and the top menu “File / Edit / View / Window / Help”

Expected:

After selecting 中文（中国） and restarting the app, the Codex Desktop UI should render in Simplified Chinese.

This looks consistent with the original report: the language setting is saved, but the localized UI strings are not being applied.

Windows 版 26.527.31326，localeOverride = zh-CN 已保存，但主界面仍英文。

Adding another reproduction from macOS with Simplified Chinese.

Environment

Codex Desktop: 26.609.30741
macOS: 15.3.2, build 24D81
Platform: macOS
Selected language: Simplified Chinese / zh-CN (中文（中国）)

What was tried

Changed Settings -> General -> Language to 中文（中国）
Went back to the app
Restarted Codex
Switched language away and back to 中文（中国）

Actual behavior

The language selector shows 中文（中国）, but the app UI remains in English. In the captured Settings screen, these labels are still English after the language is set to Chinese:

General
Work mode
Permissions
Default permissions
Auto-review
Full access
Default open destination
Language

Expected behavior

The desktop UI should switch to Simplified Chinese after selecting 中文（中国） and restarting the app.

Adding a summary from several reproductions:

Users are still reproducing this on recent Desktop builds, including 26.609.30741.
localeOverride is saved as zh-CN.
The renderer appears to start with --lang=zh-CN.
Simplified Chinese resources exist in the app bundle.
Chat responses can be Chinese, but the Desktop UI still remains English or mixed English.

One reported workaround was to fully quit Codex, enable a system-wide proxy before launching, then switch the language again. That suggests this may involve startup-time fetching of remote i18n config, feature flags, or server-side rollout state.

Could maintainers confirm whether Desktop UI localization is gated by a remote enable_i18n flag or another server-side config?

If the Desktop UI i18n code is not part of this public repo, an external PR may not be able to fix it. In that case, please route this to the internal Desktop/i18n config owner.

Also experiencing this on the latest version:

Codex desktop: 26.917.71314 (macOS, latest prod)
localeOverride = "zh-CN" is saved in ~/.codex/config.toml, but the UI renders in English after restart
Key detail: the UI was in Simplified Chinese yesterday and reverted to English today after a reboot — no settings changed in between. Restarting the app, switching model providers, and re-selecting the language all failed to restore Chinese.
The app bundle contains zh_CN.lproj, consistent with the enable_i18n remote-gate theory: the strings are local, but the flag isn't enabled for this machine/account right now.
The "worked yesterday, broken today with zero local changes" pattern suggests the gate is flaky server-side rather than a hard local bug. Happy to provide more diagnostics if needed.

Adding a Windows reproduction and a verified recovery, checked on 2026-10-11.

Environment:

Windows 11, Codex desktop package 26.1007.2314.0.
Simplified Chinese selected; [desktop] localeOverride = "zh-CN" persisted in ~/.codex/config.toml.
Clash Verge with TUN enabled and rule mode. Windows system proxy was disabled.

Before restarting:

The renderer's document.documentElement.lang and navigator.language were both zh-CN, but the settings heading still displayed General and the shell remained English.
Reading Statsig dynamic config 72216192 returned reason: "NoValues", with no enable_i18n value.
An earlier desktop log contained Timed out while fetching post-login Statsig bootstrap.
Simplified Chinese translation resources were already present in the installed app.

What worked in this session:

Keep the existing TUN/proxy network available.
Fully exit the desktop client.
Relaunch the installed client normally, keeping the existing zh-CN setting and proxy configuration.

After reopening, the actual desktop UI displayed Chinese. This was verified from the visible window and accessibility tree: 文件 / 编辑 / 视图 / 帮助, navigation labels, 搜索, and 新聊天. The new app process had no additional proxy command-line arguments; Windows system proxy remained disabled.

This is evidence that a full restart with the existing proxy network can recover this failure. It is not a strict reproduction of the earlier system-wide/global-proxy workaround. We did not inspect the post-restart enable_i18n value or test repeated restarts, so this does not establish a permanent fix or a unique root cause. The pre-restart NoValues and bootstrap timeout make startup-time remote configuration loading worth investigating.

Reproducing on macOS 15.6 (arm64), Codex Desktop 26.1007.30912 (build 20156). Settings > General > Language shows Simplified Chinese, and [desktop] localeOverride = "zh-CN" is saved in ~/.codex/config.toml. Native macOS menus are in Chinese, but the main Codex UI and Settings remain in English. Switching to Auto detect and back to Simplified Chinese did not help.

On several launches, the desktop log reports Timed out while fetching post-login Statsig bootstrap after six attempts. I found the same timeout in logs from older app versions, so I cannot attribute it solely to the current version or prove that it causes the language issue.

Could maintainers investigate whether a failed feature-config load prevents the saved zh-CN setting from taking effect, and provide a supported recovery path?

Same symptom on macOS, on the current build — and it is not the offline case from #52471: the machine has working access to OpenAI the whole time.

Environment

macOS 14.8.3 (arm64), system language zh-Hans-CN (codex doctor reports OS language zh-Hans-CN)
Codex desktop 26.1007.71326 (build 20398), bundle id com.openai.codex
The UI was Simplified Chinese before this update; it has been English since the update.

Network is fine (so this is a different failure mode from #52471)

A proxy is running and the system proxy is set to it.
Through it: google.com → 200 and api.openai.com/v1/models → 401 (i.e. OpenAI is reachable), stable over repeated calls.
The app's own processes have established connections through that proxy.
So the app is not starting offline.

What does not help on this build

[desktop] localeOverride = "zh-CN", written by Settings → Language → 简体中文 and verified present in ~/.codex/config.toml. Full quit + relaunch → still English.
Toggling the setting to English and back to 简体中文 while the app is running (which should go through the onDidChange → refreshApplicationMenu() / refreshLocale() path) → no change.
Launching with --lang=zh-CN (open -a ChatGPT --args --lang=zh-CN, confirmed present in the process argv) → still English.
The native menu bar is localized (文件 / 编辑 / 视图 / 窗口 / 帮助) — only the web UI stays English.

Likely cause: the `enable_i18n` gate has two disagreeing defaults

In Contents/Resources/app.asar, the component that injects the locale and messages for the UI:

function O9s(e){ ...
  s = s0e(`72216192`);
  c = s?.get(`enable_i18n`, !1);          // default FALSE  <-- gate closed
  let l = c,
      u = s?.get(`locale_source`, `IDE`), ...
  bb0: { if (r) { m = r; break bb0 }      // r = localeOverride; only reaches the UI when the gate is open
  ...
}

while the Settings component uses the opposite default:

function cc(){ ...
  r = Pn(`72216192`)?.get(`enable_i18n`, !0);   // default TRUE
}

So enable_i18n is resolved from a server-side config for key 72216192. When that value is not returned, the provider path closes the gate and the UI falls back to the English defaultMessage strings — which makes every local lever (localeOverride, --lang, changing the picker) a no-op, exactly as observed.

The translations themselves are present — app.asar ships a complete zh-Hans set (e.g. 1187 occurrences of 「设置」, 1712 of 「取消」, plus a full browserSidebar.loadError.* group such as "browserSidebar.loadError.dnsHeader":"检查 DNS 设置"). So this is not a missing-translation problem.

Suggested fix

Default enable_i18n to true in the provider path (or derive the initial value from app.getLocale() / the stored localeOverride instead of the remote gate), and/or let an explicit localeOverride force the gate open. The two call sites disagreeing on the default looks like an oversight.

Related: #52471 (Windows, offline start), #19518.

Navigation Menu

Repository navigation

Codex desktop UI does not update language despite localeOverride=zh-CN and --lang=zh-CN #19239

Summary

Environment

What I checked

Suspected cause

Expected behavior

Actual behavior

Environment

What was tried

Actual behavior

Expected behavior

Environment

Network is fine (so this is a different failure mode from #52471)

What does not help on this build

Likely cause: the `enable_i18n` gate has two disagreeing defaults

Suggested fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex desktop UI does not update language despite localeOverride=zh-CN and --lang=zh-CN #19239

Description

Summary

Environment

What I checked

Suspected cause

Expected behavior

Actual behavior

Activity

github-actions commented on Apr 24, 2026

zhaomenghua commented on Apr 25, 2026

hanhongfei558 commented on Apr 29, 2026

lyglane commented on May 16, 2026

xiaoqiangit commented on May 18, 2026

958272629-collab commented on May 18, 2026

jmio19930215 commented on May 27, 2026

wyeee1 commented on Jun 1, 2026

liuqiangweb-svg commented on Jun 12, 2026

Environment

What was tried

Actual behavior

Expected behavior

derekNeedCoffee commented on Jun 15, 2026

mahong3389-cloud commented on Sep 24, 2026

KeplerBro commented on Oct 11, 2026

pufen commented on Oct 11, 2026

WU928-spec commented on Oct 15, 2026

Environment

Network is fine (so this is a different failure mode from #52471)

What does not help on this build

Likely cause: the enable_i18n gate has two disagreeing defaults

Suggested fix

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Likely cause: the `enable_i18n` gate has two disagreeing defaults