›_ Codex Issues
Codex Issues / #27506

[Windows] App crashes ~1s after launch when Windows user profile path contains non-ASCII (Korean) characters — `windows-updater.node` throws "in __char_to_wide: Illegal byte sequence"

Open 💬 10 comments Opened Jun 11, 2026 by Readian
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Codex app (Microsoft Store / MSIX): 26.608.1337.0 (crash started right after auto-update from 26.602.71036 on 2026-06-09)

What subscription do you have?

Plus

What platform is your computer?

Platform: Windows x64, Korean locale Windows account name contains Korean characters (profile path: C:\Users\한국어)

What issue are you seeing?

Since the 2026-06-09 update, the app exits silently about 1 second after launch. The process appears briefly in Task Manager and disappears. No window, no error dialog.

The desktop log (%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\...) contains only two lines per attempt:

info Launching app ... buildFlavor=prod enableSparkle=false enableUpdater=true packaged=true platform=win32
info Appshot hotkey inactive configured=true enabled=true platform=win32

What steps can reproduce the bug?

Crash dump analysis

Crashpad captures a dump on every launch (...\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports\*.dmp). Analysis of the minidumps:

  • Exception code: 0xE06D7363 (unhandled MSVC C++ exception)
  • Faulting module on the stack: windows-updater.node

(PDB: D:\a\openai\openai\codex\codex-apps\electron\native\windows-updater-addon\build\Release\windows_updater.pdb)

  • C++ exception what() message extracted from the exception object:
in __char_to_wide: Illegal byte sequence

At crash time the updater is installing the bundled runtime:

  • Source: C:\Program Files\WindowsApps\OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0\app\resources\cua_node
  • Destination: C:\Users\한국어\AppData\Local\OpenAI\Codex\runtimes\cua_node\.staging-2f053e67fec2d258-XXXXXX

Each launch attempt leaves behind one empty .staging-2f053e67fec2d258-* directory (80+ accumulated over a day), i.e. the staging directory is created but the install fails before any file is copied.

Root cause (hypothesis)

The destination path contains Korean characters (from the Windows user name). The updater addon apparently passes a UTF-8 encoded char path into a std::filesystem::path / char→wide conversion that uses the ANSI code page, which fails on the UTF-8 bytes of the Korean characters and throws std::filesystem_error ("Illegal byte sequence"). The exception is not caught, killing the Electron main process on every launch.

This should reproduce for any user whose Windows account name contains non-ASCII characters (Korean/Japanese/Chinese etc.) on app versions shipping the current windows-updater.node.

What did NOT help

  • Killing leftover processes, re-launching
  • Add-AppxPackage -Register AppxManifest.xml (repair), Reset-AppxPackage
  • Deleting the stale .staging-* directories (they are recreated and the app crashes again)
  • DISABLE_AUTO_UPDATE=true environment variable

Workaround that works

Manually pre-installing the runtime so the updater skips the failing copy:

$src = "$((Get-AppxPackage *codex*).InstallLocation)\app\resources\cua_node"
$dst = "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node\2f053e67fec2d258"
New-Item -ItemType Directory -Force $dst | Out-Null
Copy-Item "$src\*" $dst -Recurse -Force

After this, the app launches and works normally. (The directory name 2f053e67fec2d258 was taken from the .staging-2f053e67fec2d258-* prefix observed in the dumps; it will presumably change with future runtime versions, so the crash will likely return on the next update until the conversion bug is fixed.)

Suggested fix

Use wide-character (UTF-16) paths end-to-end in the Windows updater addon (e.g. construct std::filesystem::path from std::wstring, or convert explicitly from UTF-8 with MultiByteToWideChar(CP_UTF8, ...)), and wrap the runtime install in a try/catch so an updater failure cannot take down the whole app at startup.

Crash dumps are available on request.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #27409
  • #27434
  • #27327
  • #27320
  • #27367

Powered by Codex Action

lavi-kj · 1 month ago

I can confirm this also happens on Windows 10.

Environment:

  • OS: Windows 10 x64
  • Codex app version: 26.608.1337.0
  • Install source: Microsoft Store
  • Main Windows profile path: C:\Users\<Korean username>

Symptoms:

  • On the Korean / non-ASCII Windows profile, Codex silently failed to launch.
  • No window appeared and no error dialog was shown.
  • Reinstalling, repair/reset, clearing folders, setting CODEX_HOME=C:\codex-home, and rebooting did not fix it.
  • Creating a new ASCII-only Windows account, C:\Users\codexuser, allowed Codex to launch normally.

Workaround result:
The runtime copy workaround from this issue fixed the problem on my original Korean-profile Windows account.

So this is not limited to Windows 11; it also affects Windows 10 with Korean / non-ASCII user profile paths.

waterdog-log · 1 month ago

Same issue here — non-ASCII (Korean) username in profile path
Confirming this reproduces on my machine. My user profile path contains Korean characters (C:\Users\웅디), and the Codex Windows desktop app launched then silently exited after ~2–3 seconds, never showing a window.
Environment

Windows 11 (build 10.0.26200.8655)
Codex desktop (MSIX from Microsoft Store), package OpenAI.Codex_26.608.1337.0_x64
User profile path with non-ASCII characters: C:\Users\웅디

Symptoms / crash signature

App process spawned and exited within ~3s (no window).
Crashpad dump showed native crash traces involving windows-updater.node and better_sqlite3.node, with an Illegal byte sequence error — consistent with a path-encoding failure.
Running the bundled backend directly (...\app\resources\codex.exe --version) failed with "Access is denied", even from an elevated Administrator shell.

Ruled out (in case it helps others triaging): GPU (--disable-gpu made no difference), graphics driver update, WindowsAppRuntime version, Windows Defender exclusions, file ACLs (correct), WDAC/AppLocker (no block events), Smart App Control (off), full data reset, clean uninstall/reinstall, sfc /scannow (clean), and removing the latest cumulative update. None resolved it — pointing squarely at the non-ASCII path rather than any of these.
Workaround that worked
Manually pre-copying the cua_node runtime so the app skips the failing automatic runtime-copy step at startup. After doing this, Codex launches normally.
Note
This recurs whenever an update replaces/clears that runtime folder, so the manual copy has to be redone. A proper fix for handling non-ASCII / Unicode user profile paths during the startup runtime-copy step would resolve it permanently. Happy to share full logs and the Crashpad dump if useful.

dogvilz-sketch · 1 month ago

This appears to be a cua_node runtime staging issue on Windows when USERPROFILE contains non-ASCII characters.

In Codex Windows app v26.608.1337.0, the app attempts to stage cua_node under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-...

but fails to move it to the final hash directory when the Windows username contains Korean characters.

Crashpad repeatedly shows:

__char_to_wide: Illegal byte sequence

The path appears to be corrupted as:

C:\Users\?????????\...

Manually copying the cua_node runtime from the app package to the expected final directory fixed the launch issue:

$src = "$((Get-AppxPackage codex).InstallLocation)\app\resources\cua_node"
$dst = "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node\2f053e67fec2d258"
New-Item -ItemType Directory -Force $dst | Out-Null
Copy-Item "$src\*" $dst -Recurse -Force

After this, the app no longer exits immediately.

marduklien · 1 month ago

Bug report: Codex Desktop fails to launch on Windows when username contains non-ASCII (Chinese) characters

Environment

  • App version: OpenAI.Codex 26.608.1337.0 (Microsoft Store)
  • Platform: Windows 11 x64
  • Username: contains Chinese characters (e.g. C:\Users\[Chinese name]\)

Symptom
The app opens briefly and immediately closes with no error dialog. No main UI ever appears.

Root cause (diagnosed)
On every launch, Codex attempts to stage the cua_node runtime under:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-2f053e67fec2d258-XXXXX

and then rename/move it to the final hash directory:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\2f053e67fec2d258

This rename operation fails silently because the USERPROFILE path contains Chinese characters, which are mis-decoded during the internal path construction. The result is dozens of orphaned .staging-* folders and no final hash directory — so the app crashes at bootstrap every time.

The log file (only 2 lines) confirms the crash happens before any meaningful initialization:

2026-06-11T08:54:53.853Z info Launching app agentRunId=null ... platform=win32
2026-06-11T08:54:54.139Z info Appshot hotkey inactive configured=true enabled=true platform=win32

Setting CODEX_HOME as a user environment variable did not help, because the Store app sandbox does not reliably inherit user environment variables.

Manual workaround that fixed the issue
Manually copy the cua_node runtime from the app package to the expected final hash directory:

Remove-Item "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node\.staging-*" -Recurse -Force

$src = "C:\Program Files\WindowsApps\OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0\app\resources\cua_node"
$dst = "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node\2f053e67fec2d258"
New-Item -ItemType Directory -Force $dst | Out-Null
Copy-Item "$src\*" $dst -Recurse -Force

After running this, the app launched successfully.

Note: This workaround must be repeated after every app update, since a new hash directory name will be generated.

Expected behavior
The app should launch normally regardless of whether the Windows username or USERPROFILE path contains non-ASCII characters such as Chinese, Korean, or accented Latin characters.

Related issues
#16918, #16268

seibe · 1 month ago

I can reproduce the same class of crash on a Japanese Windows user profile path.

Environment:

  • Codex App: Microsoft Store / MSIX
  • Version: 26.608.1337.0
  • PackageFullName: OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0
  • Windows x64
  • User profile path contains Japanese characters: C:\Users\<Japanese username>

Observed:

  • The app starts, then exits/crashes a few seconds later.
  • Crashpad dumps contain the same exception message:
  • in __char_to_wide: Illegal byte sequence
  • The failing path in my dump points at the bundled cua_node runtime staging directory under a non-ASCII user profile path:
  • \\?\C:\Users\<Japanese username>\AppData\Local\OpenAI\Codex\runtimes\cua_node\.staging-2f053e67fec2d258-...
  • This does not look related to an external Node.js installation. The failing runtime is the Codex App bundled cua_node path copied/staged by the app updater/runtime installer.

Workaround that stabilized the app locally:

  • Copied the app resources to an ASCII-only path:
  • C:\Users\Public\OpenAI\Codex\resources
  • Set user environment variables:
  • CODEX_ELECTRON_RESOURCES_PATH=C:\Users\Public\OpenAI\Codex\resources
  • CODEX_BROWSER_USE_NODE_PATH=C:\Users\Public\OpenAI\Codex\resources\cua_node\bin\node.exe
  • CODEX_NODE_REPL_PATH=C:\Users\Public\OpenAI\Codex\resources\cua_node\bin\node_repl.exe
  • CODEX_HOME=C:\OpenAI\Codex\home
  • Manually preinstalled the bundled cua_node runtime into:
  • %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\2f053e67fec2d258

After that, the app stayed running for more than 120 seconds and no new Crashpad dump was created.

This workaround is fragile because the runtime hash/version can change on the next Store update. A permanent fix probably needs Unicode-safe Windows path handling in the native updater/runtime installer, especially around char to wide-string conversion for paths containing UTF-8/non-ASCII bytes. It would also help if runtime install errors were caught so the Electron main process does not crash during startup.

minji-819 · 1 month ago

Same root cause here — adding a few diagnostics from #27722 before closing it as a duplicate, so the evidence stays in one place.

Confirmed it's the path string itself, not env vars. Launching app\Codex.exe with PATH stripped of all non-ASCII entries still crashed with the identical exception. Redirecting USERPROFILE/LOCALAPPDATA/APPDATA/TEMP through ASCII-path junctions (e.g. C:\Users\Public\cxlocal → the real Korean ...\AppData\Local) lets staging complete and the app starts normally — which isolates the trigger to the profile-path string passed into the conversion.

Byte-level confirmation that the input is valid UTF-8 (not CP949). The conversion input on the crashing stack is:
\\?\C:\Users\<한글>\AppData\Local\OpenAI\Codex\runtimes\cua_node\.staging-2f053e67fec2d258-*
The Hangul segment is UTF-8 (5C ED 99 8D ... 5C = \<한글>\), which is not decodable on CP949 — a Hangul trail byte followed by 5C is an illegal CP949 pair. So __char_to_wide (ACP = CP949) throws filesystem_error and it's never caught.

Faulting module nuance. In my dumps the throwing module is app\chrome.dll (libc++ std::filesystem), raised in KERNELBASE.dll, ExceptionCode 0xE06D7363, ExceptionInformation[0] = 0x19930520 — i.e. the libc++ filesystem path on the cua_node staging copy, in addition to the windows-updater.node path others reported. Same conversion bug, possibly two call sites.

Recurrence. After one successful staging the app launches fine from Start — until the next runtime version bump re-runs staging, which reproduces the crash. Confirmed on 26.608.1337.0 and again on 26.609.30741.

Fix is the same as proposed above: build std::filesystem::path from wide strings (or convert UTF-8 explicitly with CP_UTF8/MultiByteToWideChar) instead of ACP-based char→wide, and wrap runtime staging in try/catch so a staging failure surfaces a dialog instead of silently killing the process.

Full Crashpad minidumps available on request (they contain full process memory, so a private upload channel would be ideal).

tbvjaosaos · 1 month ago

Additional confirmation on Stable Microsoft Store package 26.609.3341.0 with a Korean/non-ASCII Windows profile path.

Environment:

  • Codex package: OpenAI.Codex_26.609.3341.0_x64__2p2nqsd0c76g0
  • Windows user profile path contains Korean characters: C:\Users\<Korean username>
  • NODE_OPTIONS was empty at Process/User/Machine scope, so this was not the --openssl-legacy-provider variant.

Observed behavior:

  • Launching from Start Menu / AppX activation exited immediately with no visible UI.
  • Crashpad dumps were created before the workaround.
  • Manually pre-staging the older hash directory from previous reports, %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\2f053e67fec2d258, did not fix 26.609.3341.0.
  • After launching once, the app created a new failed staging directory:
  • %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-789504f803e82e2b-*

Working workaround for 26.609.3341.0:

$pkg = Get-AppxPackage -Name OpenAI.Codex
$src = Join-Path $pkg.InstallLocation 'app\resources\cua_node'
$base = Join-Path $env:LOCALAPPDATA 'OpenAI\Codex\runtimes\cua_node'
$hash = '789504f803e82e2b'
$dst = Join-Path $base $hash

Get-ChildItem -LiteralPath $base -Filter '.staging-*' -Force -ErrorAction SilentlyContinue |
  Remove-Item -Recurse -Force -ErrorAction SilentlyContinue

New-Item -ItemType Directory -Force -Path $dst | Out-Null
robocopy $src $dst /E /R:1 /W:1

Result:

  • robocopy copied 3416 files / 655 directories, 4070 total items under the destination.
  • After pre-staging %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\789504f803e82e2b, both direct app\Codex.exe launch and shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App stayed running.
  • No new Crashpad dump was created after the correct-hash pre-stage.

Main note for other affected users: the final hash directory is version-specific. For 26.609.3341.0, using the older 2f053e67fec2d258 workaround is insufficient; inspect the newly-created .staging-<hash>-* directory and pre-stage to that <hash> instead.

sunghyun123 · 1 month ago

Confirming this still reproduces on the newer Windows Store/MSIX package 26.611.7849.0.

Environment:

  • Package: OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0
  • Install path: C:\Program Files\WindowsApps\OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0
  • Platform: Windows x64
  • Windows profile path contains Korean/non-ASCII characters: C:\Users\<Korean username>
  • Codex CLI still works; only the Windows desktop app fails to launch.

Observed behavior:

  • Launching OpenAI.Codex_2p2nqsd0c76g0!App creates a Codex.exe process, then it exits within ~2 seconds.
  • No visible UI and no error dialog.
  • AppModel Runtime logs only show process/container creation followed by container deletion.
  • Desktop app log contains only the usual two startup lines:
  • Launching app ... packaged=true platform=win32
  • Appshot hotkey inactive configured=true enabled=true platform=win32

Crash/staging details:

  • Crashpad dump is created on every launch under:

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

  • Latest dump observed: 8d63ab34-fb09-42c1-acd2-c66c164972b7.dmp, ~36 MB.
  • Minidump exception code: 0xe06d7363 (MSVC C++ exception).
  • Exception address maps to KERNELBASE.dll.
  • Each launch leaves a failed runtime staging directory under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

  • Current staging hash for 26.611.7849.0 appears to be:

.staging-a89897d3d9baa117-*

Tried, did not resolve:

  • Launching via AppsFolder
  • Direct launch of app\Codex.exe
  • Direct launch with --disable-gpu
  • MSIX package re-register with Add-AppxPackage -DisableDevelopmentMode -Register
  • Temporarily moving the Chromium profile/cache aside and launching with a fresh profile

This looks consistent with the same non-ASCII Windows profile path / runtime staging path conversion issue reported above, now still present in 26.611.7849.0.

Tommy0813 · 1 month ago

I can reproduce what appears to be the same issue on Windows when the user profile path contains Chinese characters.

Environment

  • OS: Windows
  • Codex app: Windows desktop app
  • Original Windows profile path contains Chinese characters:
  • C:\Users\<Chinese characters>
  • Test Windows profile path uses ASCII-only characters:
  • C:\Users\codexuser

Behavior

On my original Windows account, Codex fails to launch. The app does not open successfully after updating/reinstalling.

I created a new local Windows administrator account with an ASCII-only username:

codexuser

Then I logged into that account and launched Codex again. Codex opened successfully under:

C:\Users\codexuser

A/B test result

  • C:\Users\<Chinese characters> → Codex fails to launch
  • C:\Users\codexuser → Codex launches successfully

This strongly suggests the Windows desktop app is still failing when the Windows user profile path contains non-ASCII characters, including Chinese characters.

Workarounds tried

  • Reinstalled/updated Codex
  • Killed existing Codex/OpenAI processes
  • Created a new ASCII-only Windows user account
  • Attempted to redirect Codex-related home paths via environment variables, but the original account still failed to launch

The ASCII-only Windows account workaround confirms that the app itself can run on the same machine, but fails under the original non-ASCII profile path.