Windows Desktop mangles Korean USERPROFILE in generated notify/node_repl paths, causing invalid config.toml and setup loop

[LeeJeongHeon02]

Summary

On Windows, Codex Desktop generated notify and node_repl paths containing a mojibake/corrupted form of a Korean username from %USERPROFILE%. The generated notify value also used unsafe backslash escaping inside a TOML double-quoted string, making the entire user config.toml unparseable.

The Desktop UI did not show the configuration error. Instead, it became stuck on Complete Windows setup / Windows setup didn't finish. Retry did not open a real UAC prompt, and Continue with limited access did nothing.

Removing only the invalid generated notify line immediately restored both the bundled Codex CLI and Desktop. Later, adding an MCP server reproduced or triggered regeneration of the same invalid notify value. The available evidence does not establish whether the MCP installer wrote it directly or whether a subsequent Desktop/runtime/plugin reconciliation rewrote it.

Environment

• Windows (registry product name: Windows 10 Education), version 25H2, build 26200.8875, x64
• Microsoft Store package: OpenAI.Codex 26.803.5235.0
• Bundled Codex: codex-cli 0.147.0-alpha.6.5
• USERPROFILE contains Korean/non-ASCII characters: C:\Users\<Korean username>
• The same Windows account had previously run ChatGPT/Codex Desktop normally; the problem appeared after a recent app update.

Observed behavior

Desktop was blocked by the Windows setup overlay:

• Retry Windows setup did not produce an actual UAC prompt.
• Continue with limited access had no observable effect.
• A Settings deep link only flashed behind the setup overlay.
• Windows App Repair, Reset, and confirming the latest Store version did not help.
• Setting [windows] sandbox = "unelevated" did not bypass the setup gate.

Running the bundled executable directly:

%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe

exposed the underlying error:

Error loading config.toml
missing escaped value

The user config contained a Desktop/runtime-managed value shaped like this (username and hashes redacted):

notify = [ "C:\Users\\<mojibake>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_modules\\@oai\sky\bin\windows\codex-computer-use.exe", "turn-ended" ]

The Korean username portion had been stored as mojibake/corrupted characters, and the Windows path was not safely escaped for a TOML double-quoted string. The parser reported:

missing escaped value, expected b, e, f, n, r, \, ", x, u, U

Recovery and before/after evidence

I removed only the invalid generated notify line. I did not delete .codex or reset the complete config.

Before:

invalid generated notify path
-> config.toml parsing failure
-> bundled Codex bootstrap failure
-> Desktop stuck at Windows setup incomplete

After:

remove only invalid notify line
-> bundled Codex starts normally
-> Desktop starts normally

After Desktop had recovered, adding an MCP server via its installer reproduced or triggered the problem. codex mcp list then failed during bootstrap configuration loading with the same invalid generated notify value and TOML parse error. Removing only that line again restored codex mcp list; the newly registered MCP server remained enabled and its OAuth registration remained intact.

This confirms the failure was not resolved permanently by the first manual removal. It does not establish whether the third-party installer or a later Codex-managed reconciliation step regenerated notify.

Related node_repl path corruption

The generated node_repl.command path contained the same USERPROFILE corruption and was shaped like:

C:\Users<mojibake>AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe

The executable actually existed at:

C:\Users\<Korean username>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe

Before correcting node_repl.command, bundled Codex reported:

MCP client for node_repl failed to start:
The filename, directory name, or volume label syntax is incorrect. (os error 123)

After setting node_repl.command to the actual Unicode path, codex mcp get node_repl showed the correct path and the os error 123 startup warning disappeared.

Reproduction

1. Use Windows with a Korean/non-ASCII USERPROFILE such as C:\Users\<Korean username>.
2. Use ChatGPT/Codex Desktop normally so its Computer Use/node_repl configuration is generated.
3. Observe that the generated notify path contains a corrupted USERPROFILE and invalid TOML backslash escaping.
4. Restart/open Desktop and observe the Windows setup didn't finish loop.
5. Run the bundled Codex executable and observe the config.toml parsing error.
6. Remove only the invalid generated notify line; bundled Codex and Desktop recover immediately.
7. Add an MCP server. In this reproduction, doing so reproduced or triggered regeneration of the invalid notify value and the same failure.
8. Remove the invalid notify line again and correct the generated node_repl.command to the actual Unicode path.
9. Observe that Codex and Desktop start normally and the node_repl os error 123 warning is gone.

Confirmed facts vs. inference

Confirmed:

• Desktop-managed/generated config contained Windows paths with a mojibake form of the Korean/non-ASCII USERPROFILE.
• The generated notify line was invalid TOML and caused a clear parse failure in bundled Codex.
• Removing only that line immediately restored bundled Codex and Desktop.
• Adding an MCP server reproduced or triggered regeneration of the same invalid notify line and failure.
• The generated node_repl.command contained the same USERPROFILE corruption.
• Correcting node_repl.command to the actual Unicode path removed the os error 123 warning.
• Desktop surfaced the parse failure as a Windows setup failure rather than showing the configuration error.

Inference:

The evidence suggests that a Desktop-managed runtime/plugin/config reconciliation path may be serializing non-ASCII Windows profile paths incorrectly or writing generated runtime paths to TOML without safe escaping. I have not verified the internal implementation or which component performs the rewrite.

Expected behavior

1. Desktop-generated Windows paths must preserve Unicode/non-ASCII USERPROFILE values correctly.
2. Desktop-generated config.toml must always remain valid TOML.
3. Windows paths written to TOML must use safe escaping, forward slashes, or TOML literal strings where appropriate.
4. A config.toml parsing failure must not be surfaced only as Windows setup didn't finish.
5. When config.toml is invalid, Desktop should show the actual config file, line number, and parse error, or start in a recoverable safe mode.
6. MCP/config/runtime reconciliation must not regenerate invalid notify or node_repl paths.
7. Korean/CJK/non-ASCII Windows USERPROFILE paths should be covered by regression tests/CI.

Related issues

• Codex desktop app freezes on startup: MCP Windows path in config.toml triggers TOML parsing failure #37616: an unescaped Windows path in MCP configuration makes config.toml invalid and blocks Desktop startup. This report differs because the invalid notify/node_repl paths were Desktop-managed/generated, contained mojibake USERPROFILE data, reappeared after an MCP config change, and were surfaced as a Windows setup failure.
• 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 #28017 and Codex Windows app exits immediately when USERPROFILE contains Korean characters #27571: CJK/non-ASCII USERPROFILE failures while staging cua_node; related Unicode-path class, but a different failure point and error.
• Windows app stuck on "Finish Windows setup" — sandbox setup never triggers a real UAC prompt, "Retry" fails instantly #32492 and Windows setup fails before the UAC prompt, and both setup options are non-functional #32149: nearly identical Windows setup/UAC/limited-access UI symptoms without this confirmed config.toml root cause.
• Windows: NUL-filled .sandbox/deny_read_acl_state.json permanently breaks sandbox setup and survives reinstall ("Windows setup didn't finish") #35718: the same misleading Windows setup UI caused by an unparseable NUL-filled state file, but a different corruption mechanism.
• Windows Codex app rewrites node_repl / Computer Use config on startup or plugin update, breaking @oai/sky resolution #26190: Desktop/plugin rewriting of node_repl/Computer Use config, but its config still parsed and the reported failure was stale/empty module paths rather than USERPROFILE mojibake and invalid TOML.
• Windows: Codex launches PowerShell with corrupted HOME path when username contains "é" (USERPROFILE/APPDATA can also be affected) #16268: related non-ASCII Windows profile-path mojibake affecting HOME/PowerShell.

[github-actions]

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

• Codex desktop app freezes on startup: MCP Windows path in config.toml triggers TOML parsing failure #37616
• config.toml rewritten without BOM corrupts non-ASCII project paths, app fails to boot #36844

Powered by Codex Action

[LeeJeongHeon02]

Thanks — I reviewed both suggested duplicates.

#37616 concerns an unescaped user-supplied MCP path that makes config.toml invalid. #36844 concerns an agent-initiated full-file rewrite that changed the file encoding/BOM and corrupted existing non-ASCII project paths.

This report covers a different write path and reproduction: Desktop-managed/generated notify and node_repl paths contained a corrupted non-ASCII USERPROFILE, the generated notify value made the TOML invalid, Desktop surfaced the parse failure as a Windows setup loop, and the invalid value was regenerated after an MCP configuration change. Correcting the generated node_repl.command also removed the associated os error 123.

Because the responsible configuration path and confirmed reproduction are distinct, I’m leaving this issue open unless the maintainers prefer consolidation.