Windows desktop app crashes on launch (no window) for CJK/non-ASCII usernames — cua_node runtime deploy fails in cpSync with __char_to_wide: Illegal byte sequence

Environment

• Codex Desktop (MSIX, Microsoft Store): OpenAI.Codex 26.609.3341.0 (x64)
• Electron/Chromium: 149.0.7827.54
• Bundled core engine: codex-cli 0.140.0-alpha.2
• OS: Windows 11 (build 26200)
• Windows username contains CJK characters (e.g. 苏海龙…), so %USERPROFILE% / %LOCALAPPDATA% are non-ASCII paths.
• Worked on an older version / on a machine with an ASCII username. Broke right after updating to the latest version.

Summary

The packaged Windows desktop app crashes ~5 seconds after launch and never shows a window. The Electron processes spin up (5–6 processes), then all exit at once. It happens every launch and is fully deterministic.

The crash occurs while the app copies the bundled cua_node runtime from
…\WindowsApps\OpenAI.Codex_…_x64\app\resources\cua_node
into
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-<hash>-<rand>.

Each launch leaves behind an empty .staging-* directory and a fresh crashpad minidump.

Evidence (from crashpad minidump)

Readable strings extracted from the .dmp:

filesystem error: in __char_to_wide: Illegal byte sequence
cpSyncCheckPaths / cpSyncCopyDir / cpSyncOverrideFile / cpSyncFn
errorOnExist
ERR_INVALID_RETURN_VALUE
\\?\C:\Users\?????????<digits>\AppData\Local\OpenAI\Codex\runtimes\cua_node\.staging-<hash>-<rand>
C:\Program Files\WindowsApps\OpenAI.Codex_26.609.3341.0_x64__…\app\resources\cua_node\bin\node.exe
length_error was thrown in -fno-exceptions mode

Note the username renders as ????????? — it has been mis-decoded (UTF-8/locale mismatch) before being handed to the filesystem layer.

The desktop log stops at the same two lines every time (constant 328 bytes), right before the runtime-deploy step:

info Launching app … packaged=true platform=win32
info Appshot hotkey inactive configured=true enabled=true platform=win32

Diagnosis

The app uses Node's fs.cpSync ({ errorOnExist: true }) to deploy the cua_node runtime. The underlying C++ std::filesystem call (__char_to_wide) fails to convert the non-ASCII destination path to wide chars and throws Illegal byte sequence. Because the binary is built -fno-exceptions, the throw becomes an immediate std::terminate → whole-process crash. No EPERM/ENOENT — it is a string encoding bug, not a filesystem-permission/IO issue.

Workarounds attempted (and results)

1. CODEX_HOME=C:\codex (ASCII path) — fixes the .codex half (app now reads C:\codex\config.toml, crash point moves later), but cua_node deploy still crashes because its destination is derived from %LOCALAPPDATA%, which still contains the CJK username. There is no env var to relocate the runtime-deploy directory.
2. Junction …\OpenAI\Codex\runtimes → C:\codex-rt (ASCII target) — no effect. This confirms the failure is in path-string→wide-char conversion, not in physical disk IO (the app still passes the CJK junction path string to cpSync).
3. Microsoft Store Repair / Reset — no effect.

Conclusion: not locally workaround-able for CJK usernames; needs a code fix.

This is a recurring class of bug, not a one-off

Non-ASCII / CJK username path handling has broken Codex on Windows repeatedly, across multiple versions and components — see the related issues below (.codex home derivation, CODEX_HOME, subprocess locale decoding, and now cua_node runtime deploy). As a user with a CJK username, I keep hitting this every time a new version or feature touches the filesystem: each release fixes (or works around) one path, then the next feature reintroduces the same encoding mistake somewhere else.

Please consider treating this as a systemic issue rather than patching individual call sites:

• Add a non-ASCII / CJK username path to CI (e.g. a Windows runner whose user profile or LOCALAPPDATA contains CJK characters) so any new filesystem code that mishandles encoding is caught before release.
• Audit all std::filesystem / fs.cpSync / subprocess path usage for narrow-char locale conversion of user-derived paths.

Suggested fix

• When deploying cua_node via cpSync/std::filesystem, encode non-ASCII paths correctly (UTF-8 / wide-char) instead of going through a locale narrow-char conversion; and/or
• Don't run the runtime copy in -fno-exceptions code paths that terminate on encoding errors — fail soft with a clear error; and/or
• Allow overriding the runtime-deploy directory (like CODEX_HOME) so it can be pointed at an ASCII path.

Where to find logs/dumps (for repro/attachments)

• Logs: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs
• Crashpad dumps: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad

Related issues (same non-ASCII path root cause)

• #16918 — Windows app fails to start for non-ASCII usernames (malformed CODEX_HOME)
• #13553 — First start fails when user folder has non-ASCII characters
• #16268 — Corrupted HOME path when username contains é
• #14311 — UnicodeDecodeError on non-ASCII Windows locales
• #26079 — "Updated Codex Always Crash"