Windows Korean user paths are decoded as UTF-8, blocking service ownership and Codex sync

[xcbyte-cmyk]

Summary

On a Korean Windows installation, OpenCodex 2.14.0 decodes some Windows command output as UTF-8 even when the output is CP949/EUC-KR. A Korean user-profile path is therefore replaced with U+FFFD characters, causing service ownership checks and Codex write coordination to fail.

This prevents ocx sync from injecting model_catalog_json and openai_base_url, even though the proxy and provider routing themselves are healthy.

Environment

• OpenCodex: 2.14.0, installed globally via npm
• Codex CLI: 0.145.0
• Runtime: bundled Bun 1.3.14
• OS: Windows with Korean system locale
• User profile shape: C:\Users\<Korean username>\...

Symptoms

The first failure is the scheduled-task ownership probe:

Refusing to write because ownership could not be proven: the scheduled-task XML names
C:\Users\���ȭ��_��������\.opencodex\opencodex-service-launcher.vbs,
outside the expected launcher directory
C:\Users\<Korean username>\.opencodex.

After fixing that decoding site locally, the next failure is:

Codex configuration was not written: the coordinator path could not be resolved:
CodexUserIdentityRefusal: The Windows coordinator namespace cannot be created.

The nested cause shows that the LocalAppData path was corrupted in the same way:

EPERM: operation not permitted, mkdir 'C:\Users\���ȭ��_��������'

Running ocx service repair does not resolve either issue because the generated files are valid UTF-16LE; the corruption occurs while decoding child-process output.

Root cause

There appear to be two affected decoding sites:

1. src/service-manager-probe.ts — decodeWindowsText()

   • UTF-16LE/BE is handled.
   • The remaining fallback uses buffer.toString("utf8").
   • schtasks /query /xml output can be CP949 on Korean Windows.

2. src/codex/user-identity.ts — powershellValue()

   • new TextDecoder().decode(result.stdout) assumes UTF-8.
   • PowerShell known-folder output can be CP949 under this locale.

Reproduction

1. Use a Windows account whose profile path contains Korean characters.
2. Install OpenCodex 2.14.0 and its background service.
3. Configure a custom provider.
4. Run:

ocx service repair
ocx sync

5. Observe that synchronization is refused with the errors above.

Validated local workaround

I added an EUC-KR fallback when UTF-8 decoding contains U+FFFD at both sites.

const utf8 = buffer.toString("utf8").replace(/^\uFEFF/, "").trim();
if (utf8.includes("\uFFFD")) {
  try {
    return new TextDecoder("euc-kr").decode(buffer).replace(/^\uFEFF/, "").trim();
  } catch {
    // Keep the original UTF-8 decoding when the runtime lacks the Windows codec.
  }
}
return utf8;

And for PowerShell output:

let value = new TextDecoder().decode(result.stdout).trim();
if (value.includes("\uFFFD")) {
  try {
    value = new TextDecoder("euc-kr").decode(result.stdout).trim();
  } catch {
    // Keep the original UTF-8 decoding when the runtime lacks the Windows codec.
  }
}

After applying both changes:

• ocx sync completed successfully.
• 427 custom-provider models were appended to the Codex catalog.
• model_catalog_json and openai_base_url were injected.
• A request through Codex/OpenCodex/custom provider completed successfully.

Expected behavior

OpenCodex should preserve non-ASCII Windows paths regardless of the active Windows locale/code page. Ideally, child commands should be forced to emit a known encoding, or their output should be decoded using the detected Windows code page rather than assuming UTF-8.

I can provide the complete two-file patch if useful.

[github-actions]

Maintainer decision respected

A maintainer has reopened this issue. The automated closure has been deactivated.

[Splaxi]

I have the same issues with ö in my username on my local Windows installation

[Ingwannu]

Confirmed on current dev. Both reported paths currently assume UTF-8 after their UTF-16 handling, so CP949 (and Western legacy-codepage) bytes can corrupt non-ASCII profile paths before ownership/coordinator checks.

I am preparing a focused fix that will:

• preserve BOM/UTF-16 and strict valid UTF-8 first;
• use bounded legacy Windows decoding only when UTF-8 is invalid, covering Korean and Western non-ASCII paths without silently reinterpreting valid UTF-8;
• make the PowerShell identity/LocalAppData lookup emit an ASCII-safe Base64 envelope so that path no longer depends on the active console code page; and
• add byte-level regressions for Korean and Western user-profile paths.

I will link the dev PR here after exact-head tests and repository checks pass.

[Ingwannu]

The focused fix is now in #1678 targeting dev.

It preserves UTF-16 and valid UTF-8 first, uses locale-bounded CP949/Windows-1252 decoding only when required for legacy Windows tool output, and makes the PowerShell identity/known-folder path code-page independent with an ASCII Base64 envelope. Regression coverage includes Korean and Western profile paths plus unsupported-locale fail-closed behavior.

Local typecheck, privacy scan, diff checks, and the focused Windows suite are green. The full suite passed 11,666 tests; one unrelated loaded-host bridge timing watchdog fired once and then passed in three consecutive isolated reruns. I have requested maintainer review and will leave the issue open until the dev PR lands.

[lidge-jun]

Fixed by cherry-picking #1678 (fix(windows): preserve localized profile paths) onto dev at 3acf42a72, after #1674 landed.