Windows app crashes at startup (0xE06D7363, "in __char_to_wide: Illegal byte sequence") during cua_node staging on non-ASCII user profile path + CP949 codepage

What version of the Codex App are you using (From “About Codex” dialog)?

26.609.30741

What subscription do you have?

GPT PLUS

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Windows desktop app crashes ~6 seconds after launch (no window ever appears) on systems with a Korean (non-ASCII) user profile path. It recurs after every app update; Repair/Reset/reinstall do not help.

What steps can reproduce the bug?

Note: paths are anonymized — the actual username is different Korean characters, which does not affect reproduction.

Environment

• App: OpenAI.Codex (Microsoft Store, x64) — reproduced on 26.608.1337.0 and again on the next update
• OS: Windows 11, Korean locale (ANSI codepage 949 / CP949)
• User profile path contains Korean characters: C:\Users\홍길동
• Bundled CLI works fine standalone: codex-cli 0.138.0-alpha.7

Summary

After every app update, the desktop app exits ~6 s after launch, before any window is created. Repair, Reset, and full uninstall/reinstall do not help. 100% reproducible.

Root cause (verified from Crashpad dumps and confirmed by a working workaround): during the cua_node runtime staging/copy step, a UTF-8-encoded narrow path containing the Korean username is passed to libc++ std::filesystem __char_to_wide, which converts narrow→wide using the system ANSI codepage (CP949). UTF-8 Hangul byte sequences are illegal in CP949 (e.g. a trail byte followed by 5C), so the conversion throws filesystem_error, which is never caught → the process dies before window creation.

This cannot reproduce on en-US systems (CP1252 accepts any byte sequence) or with the UTF-8 ACP beta enabled — only on CJK/non-UTF-8 codepages with non-ASCII profile paths, which is likely why it passed CI.

Evidence

1. Every launch creates an empty staging dir and dies:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-<hash>-* (0 files each).

1. App log stops after Launching app / Appshot hotkey inactive (328-byte stub log per launch attempt).
2. Crashpad dump (one ~36 MB dump per attempt under

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports):

• ExceptionCode 0xE06D7363, ExceptionInformation[0] = 0x19930520 (MSVC C++ exception)
• Throwing module: ...\app\chrome.dll; raised in KERNELBASE.dll
• Exception object what(): in __char_to_wide: Illegal byte sequence

1. The crashing thread's stack contains the conversion input — a valid UTF-8 narrow path:

\\?\C:\Users\홍길동\AppData\Local\OpenAI\Codex\runtimes\cua_node\.staging-2f053e67fec2d258-SgsmPp
(5C ED 99 8D EA B8 B8 EB 8F 99 5C = \홍길동\ in UTF-8 — not decodable as CP949: a Hangul trail byte followed by 5C is an illegal CP949 pair)
plus the source path \\?\C:\Program Files\WindowsApps\...\app\resources\cua_node on the same stack.

1. Counter-test: launching app\Codex.exe directly with PATH stripped of all non-ASCII entries still crashed with the identical exception → environment variables are not the trigger; the profile-path string itself is.
2. Confirming test: launching app\Codex.exe with USERPROFILE / LOCALAPPDATA / APPDATA / TEMP redirected through ASCII-path junctions (C:\Users\Public\cxlocal → C:\Users\홍길동\AppData\Local) starts the app successfully: cua_node staging completes (runtimes\cua_node\2f053e67fec2d258, 2014 files, node v24.14.0 verified ok) and the app runs normally. After that one successful staging, normal launches from the Start menu work again — until the next runtime version bump re-triggers staging, which reproduces the crash. This recurrence after the latest update is confirmed.

Workaround (for affected users)

Launch the app once with profile environment variables pointed at ASCII-path junctions so the runtime staging can complete; normal launches work afterwards. This must be repeated after every runtime update.

Suggested fix

In the cua_node staging code, construct std::filesystem::path from wide strings (or convert UTF-8 narrow strings explicitly with CP_UTF8) instead of passing UTF-8 narrow paths into ACP-based __char_to_wide. Also consider wrapping runtime staging in a try/catch so a staging failure surfaces an error dialog instead of silently killing the process.

What is the expected behavior?

The app should launch normally and show its window regardless of the user profile path encoding — or at minimum, if runtime staging fails, show an error dialog instead of silently exiting. The bundled CLI (codex.exe) works fine on the same machine; only the desktop app shell is affected.

Additional information

• This affects every Windows user with a non-ASCII (e.g. Korean, Japanese, Chinese) username on a non-UTF-8 ANSI codepage system — a very common configuration in CJK regions.
• The bug recurs after every app update that bumps the cua_node runtime version, because the staging/copy step runs again.
• Previously worked fine: the crash started with the update that introduced the cua_node runtime staging step (26.608.1337.0), and is still present in 26.609.30741.
• Crash dumps (Crashpad minidumps, one per launch attempt) are available on request — please provide a private upload channel, as minidumps contain full process memory.