Codex desktop 26.1002.7124.0 declares only `en-US` in its MSIX manifest, forcing the UI to English despite shipping complete zh-CN resources

Locate the MSIX packaging configuration in the build system, likely a template or generation script for AppxManifest.xml. Update the <Resources> section to include all shipped locales (at minimum zh-CN, zh-TW, etc.). Verify by rebuilding the package and confirming that app.getLocale() returns the correct value on a system with a non-English display language.

App version: 26.1002.7124.0 (x64), SignatureKind: Store
OS: Windows 11, system display language zh-CN
Related setting: [desktop] localeOverride = "zh-CN" in ~/.codex/config.toml

---

Summary

The package ships 136 localised webview chunks and 220 Chromium resource packs, including a complete Simplified Chinese set. The AppxManifest.xml nevertheless declares a single resource language:

<Resources>
  <Resource Language="en-US" />
</Resources>

Because Windows reports the app's language from that declaration, Electron's app.getLocale() returns en-US and the webview never loads zh-CN-*.js. English is compiled into the main bundle (there is no en-*.js chunk at all), so the fallback is English and localeOverride cannot override it — the setting is honoured by the Electron main process, but the webview's own language resolution does not consult it.

localeOverride is read correctly. It just does not reach the renderer.

---

Steps to reproduce

1. Set the Windows display language to Chinese (Simplified, China). Confirm:

   Get-WinSystemLocale          # Name: zh-CN
   

2. Set the UI language explicitly in Codex settings, and confirm the value is persisted:

   # ~/.codex/config.toml
   [desktop]
   localeOverride = "zh-CN"
   

3. Fully quit Codex (including the tray icon) and relaunch.

Expected: the interface is in Simplified Chinese.
Actual: the interface is in English. Changing the language inside the app UI and restarting does not change this.

---

Evidence

1. The manifest declares one language

[xml]$m = Get-Content 'C:\Program Files\WindowsApps\OpenAI.Codex_26.1002.7124.0_x64__2p2nqsd0c76g0\AppxManifest.xml' -Raw
$m.Package.Resources.ChildNodes | ForEach-Object { $_.Language }
# en-US

2. The Chinese resources are present in the same package

# Chromium resource packs
Get-ChildItem '...\app\locales' | Where-Object Name -like 'zh*'
# zh-CN.pak      508.6 KB
# zh-TW.pak      502.1 KB

# Webview chunks, read out of app.asar (20806 packed files)
# webview/assets/zh-CN-b05cfd55c534.js    2.41 MB
# webview/assets/zh-TW-52bd4aa86e3b.js    2.42 MB
# webview/assets/zh-HK-7b393a9a174d.js    2.42 MB
# webview/assets/zh-Hans-6d9213662c0b.js  0.13 MB
# webview/assets/zh-Hant-4077f27a21c1.js  0.13 MB
#
# There is no en-US-*.js or en-*.js chunk: English is the built-in fallback.

3. The locale resolves correctly, and the strings still fall back to English

~/.codex/computer-use/config.json, written by the main process:

{
  "accentColor": "#a67df2",
  "direction": "ltr",
  "locale": "zh-CN",
  "strings": {
    "usingComputer": "ChatGPT is using your computer",
    "escToCancel": "Esc to cancel"
  }
}

This file is produced by the main-process helper that resolves the locale:

function Tc({ settingsStore, locale, localesDir, shouldUseDarkColors }) {
  let a = Lc(settingsStore.getEffective(r.z.localeOverride.key)) ?? Lc(locale) ?? yc,
      o = Nc(localesDir, a);
  return { accentColor: jc({...}), direction: Fc(a), locale: a,
           strings: { usingComputer: Pc(o, fc, pc), escToCancel: Pc(o, mc, hc) } };
}
function Ec() { return typeof app.getLocale === 'function' ? app.getLocale() : 'en'; }

locale is zh-CN — the resolution works — while strings holds the English literals fc/mc. So the locale is correct and the language data is not being loaded.

4. The setting is valid and present, so it is not the cause

The settings schema accepts any string for this key:

localeOverride: J({ agentAccess: 'read-write', default: null, key: 'localeOverride',
                    schema: el,   // el = t.N().nullable()
                    vscode: { description: 'Preferred language for the Codex UI. Leave empty to auto detect.',
                              scope: 'application' } })

Changing the language in the app UI writes no language value anywhere on disk. A before/after snapshot of 2906 candidate files under ~/.codex, %LOCALAPPDATA%\Packages\OpenAI.Codex_* and %LOCALAPPDATA%\OpenAI\Codex found only config.toml rewritten with identical content and .codex-global-state.json changed by 3 bytes with no locale field in it.

---

Impact

Every non-English user on Windows is affected. The resources are already paid for in the download — 136 locale chunks — and roughly 136 × ~2.9 MB of them are unusable in their intended language.

The interface language cannot be set from within the app, from config.toml, or from the Windows system language, so there is no user-side fix.

---

Workaround

None reliable. Launching with Chromium's own switch is the only lever found, and it bypasses app.getLocale() rather than fixing the resolution:

explorer.exe "shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App" --lang=zh-CN

---

Suggested fix

Declare the languages the build actually ships, so Windows reports the correct application language:

<Resources>
  <Resource Language="en-US" />
  <Resource Language="zh-CN" />
  <Resource Language="zh-TW" />
  <!-- ...the rest of the 136 shipped locales... -->
</Resources>

If declaring every locale is impractical, declaring at minimum the languages that have a full webview chunk (the ~2.4 MB *-<hash>.js files) would cover the affected users.

Separately, it would be worth making the webview's language resolution fall back to settingsStore.getEffective('localeOverride') when the platform locale is unavailable, since that setting is already surfaced in the UI as "Preferred language for the Codex UI".

---

Notes

• This is a regression as observed by the reporter: version 26.930.4958.0 displayed Simplified Chinese correctly on the same machine and with the same configuration. The previous version's directory was removed by the update, so its manifest could not be compared to confirm the cause of the regression.
• Signature verification for completeness: ChatGPT.exe, Codex.exe and resources\codex.exe all report Status: Valid, signed by CN="OpenAI OpCo, LLC", issued by CN=Microsoft ID Verified CS EOC CA 03, SignatureKind: Store, IsDevelopmentMode: False. The installation is genuine, which is why this is reported as a packaging defect rather than a tampered install.