Activity

1. Saber-CC

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on May 27, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   on May 27, 2026
3. github-actions commented on May 27, 2026

   

   github-actionsbot

   on May 27, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Enable built-in Chinese (zh-CN) UI support #23431
   • Codex Desktop language setting changes localeOverride but UI remains English #23815

   Powered by Codex Action
4. tangnomad commented on Jun 16, 2026

   

   tangnomad

   on Jun 16, 2026

   More actions

   I can still reproduce this on the latest Codex Desktop release.

   Environment:

   • Codex Desktop: 26.609.71450, released Jun 16, 2026
   • Codex CLI: 0.140.0-alpha.2
   • macOS: 26.5.1, build 25F80
   • Architecture: arm64, Apple M1
   • Auth mode: API key
   • Selected UI language: zh-CN / 中文（中国）

   What I observed:

   • Settings > General > Language shows 中文（中国）.
   • ~/.codex/config.toml contains [desktop] localeOverride = "zh-CN".
   • Codex renderer/service processes are launched with --lang=zh-CN.
   • The app bundle includes zh-CN frontend translation assets and native-menu-locales/zh-CN.json.
   • Reinstalling Codex, fully restarting the app, and clearing Chromium/Electron cache did not help.
   • The visible app UI remains English.

   Additional diagnosis:
   The selected locale appears to be saved and propagated correctly. The problem looks consistent with the i18n provider not loading translated messages unless the remote Statsig gate/dynamic config enables enable_i18n. This also explains why another user on the same Codex version and also using API key auth can see Chinese UI, while this machine/account cannot.

   Expected behavior:
   If a supported locale is selected in Settings and localeOverride is set, Codex Desktop should load the bundled locale messages without requiring a per-account/per-device remote rollout flag.
5. shilei-openclaw commented on Jun 20, 2026

   

   shilei-openclaw

   on Jun 20, 2026

   More actions

   Update / re-scoping after further investigation

   After looking through existing issues, it turns out Codex Desktop already ships with a fairly complete zh-CN translation bundle (~6,000+ strings in webview/assets/zh-CN-*.js plus native-menu-locales/zh-CN.json). The original framing of this issue ("introduce an i18n layer") is therefore inaccurate — the i18n layer exists and the translations exist; they just don't load.

   The actual root cause, already documented by other reporters, is that the i18n system is gated behind the Statsig flag enable_i18n, whose local fallback defaults to false. So even with:

   • OS locale set to zh-CN
   • localeOverride = "zh-CN" in config.toml
   • launching with --lang=zh-CN
   • ELECTRON_LOCALE_OVERRIDE=zh-CN

   …the renderer still falls back to English because the i18n init code never activates.

   Concrete asks (revised)

   1. Flip the local fallback for enable_i18n to true, or remove the gate entirely now that the translations are shipped.
   2. Make the web UI's i18n init read localeOverride / app.getLocale() / navigator.language instead of hard-coding en-US.
   3. Document the supported locales and the localeOverride config key in user-facing docs.

   Related / likely-duplicate issues

   • i18n is disabled by default, preventing bundled translations from loading for all locales #24741 — i18n disabled by default (root cause)
   • Enable built-in Chinese (zh-CN) UI support #23431 — Enable built-in Chinese (zh-CN) UI support
   • [i18n] Enable zh-CN locale by default / enable i18n experiment #25037 — [i18n] Enable zh-CN locale by default
   • Bug: Codex cannot switch to the Chinese interface (localeOverride does not take effect) #27411 — Bug: localeOverride does not take effect (with technical analysis)
   • Codex desktop UI does not update language despite localeOverride=zh-CN and --lang=zh-CN #19239 — Desktop UI does not update language despite localeOverride/--lang
   • Improve Chinese (zh-CN) Localization Coverage #24686 — Improve zh-CN localization coverage
   • Windows: Statsig bootstrap fails on user.custom.workspace_type, disabling i18n and Browser Use #26780 — Windows: Statsig bootstrap failure also disables i18n

   Happy for maintainers to close this as a duplicate of whichever of the above they consider canonical (likely #24741). Leaving it open meanwhile in case the consolidated framing helps triage.
6. Jeck164 commented on Sep 29, 2026

   

   Jeck164

   on Sep 29, 2026

   More actions

   i18n never loads on Windows Store builds: root cause, complete evidence, and the one-line fix

   App: Codex Desktop (Microsoft Store / MSIX) 26.924.2738.0 on Windows 11 (build 26200), system locale zh-CN, API-key auth mode.
   Symptom: with [desktop] localeOverride = "zh-CN" (and even with --lang=zh-CN), the renderer UI stays 100% English: sidebar (New chat / Scheduled / Plugins / Explore / Projects / Recents), the in-window menu bar labels (File / Edit / View / Help) and all settings text. The native dropdown menus and dialog strings are Chinese, so locale handling itself works - only the renderer's bundled translations never load.

   Root cause

   In the renderer bundle webview/assets/app-initial-*.js the i18n provider does:

   let c = zme('72216192'), l;
   t[0] === c ? l = t[1] : (l = c?.get('enable_i18n', !1), t[0] = c, t[1] = l);
   let u = l, d = c?.get('locale_source', 'IDE'), ...
   ...
   k = () => { ... return u && (async () => {
       if (b) try { let t = await TCr(b); ... D({ locale: C, messages: t }) ... } catch {}
   })() ... }

   so the locale chunk is only imported when enable_i18n is truthy, and the local fallback is false. The value comes from the Statsig dynamic config 72216192; the same module also reads locale_source from it. The settings page reads the same flag with a true default, which is why the language picker is visible and can be changed while the UI never switches.

   Verified on the running app (renderer DevTools port)

   • __STATSIG__ exists and is the React SDK namespace (useDynamicConfig, useLayer, StatsigClient, firstInstance, instances, ...) - it has no getDynamicConfig/getLayer of its own; the client instances do.
   • The app reads the gate through the client layer: instrumenting the client methods captured getLayer(72216192) (plus many other ids).
   • The value it gets: __STATSIG__.firstInstance.getLayer('72216192').get('enable_i18n', 'MISSING') -> MISSING - the key is absent from the config object, so the false fallback applies.
   • Repeated with 6 freshly generated anonymous stable IDs (customIDs.stableID), each with a fresh evaluation: enable_i18n was MISSING every time. So the local server response simply does not carry the key; it is not a percentage-rollout membership problem of one particular device.
   • localeOverride is nevertheless applied: document.documentElement.lang === 'zh-CN', navigator.language === 'zh-CN', and the native application menu (from native-menu-locales/zh-CN.json) renders in Chinese.
   • The translations are definitely shipped: native-menu-locales/zh-CN.json, the renderer chunk webview/assets/zh-CN-1adc76a05252.js (~2 MB) and locales/zh-CN.pak all exist in the installed package.

   The fix

   Make the local fallback default to enabled, e.g.

   l = c?.get('enable_i18n', !0)     // was !1

   or ship the same flag on in the local default config. Nothing else is needed: forcing exactly that value at runtime (injecting a wrapper around the client's getLayer for config 72216192) makes the whole UI render in Chinese immediately, menus included.

   Please don't dismiss this as "works on my machine"

   This is reported repeatedly (#23815, #19239, #24741, #24827, #27846, #29204, #30060) and it is fully deterministic on this machine: the flag simply never arrives, and the fallback is false. Users on API-key auth without access to OpenAI endpoints can never get the flag, because it depends on a remote evaluation that their environment may not receive.

   Extra context (why local workarounds fail on 26.900+)

   For anyone trying to work around this locally, note the walls in this build:

   1. Files under C:\Program Files\WindowsApps\<package> cannot be written in place - even by an elevated administrator who has taken ownership and granted Administrators full control (Access Denied, reproducible in Safe Mode as well).
   2. Editing a copy of the app does not help: for 26.900+ any single byte change in app.asar makes the app abort 2-5 s after launch with 0x80000003 (STATUS_BREAKPOINT). Verified: changing one semantically meaningless byte (a space to a tab) is enough.
   3. --inspect is ignored by this build (no main-process inspector appears on the debugging port), so the main process cannot be patched at runtime.
   4. CDP Page.addScriptToEvaluateOnNewDocument scripts do not run in the reloaded page (typeof window.__codexZhI18nDiag === 'undefined' after Page.reload), so renderer injection has to happen before script execution (instrumentation breakpoint / auto-attach) to be reliable.

   Environment note: api.openai.com / chatgpt.com are unreachable from this network, while api.statsig.com / featuregates.org are reachable.