Windows: apply_patch.bat fails for non-ASCII user profiles because UTF-8 wrapper is parsed using the legacy code page

What version of Codex is running?

• Codex Desktop: 26.715.4045.0
• Codex CLI/backend: 0.145.0-alpha.18

Platform

• Windows 11 25H2, build 26200.8875, x64
• Native Windows workspace
• workspace-write Windows sandbox
• Active cmd.exe code page: 936
• Windows user profile contains non-ASCII characters

Issue

On Windows, Codex generates temporary apply_patch.bat and applypatch.bat wrappers under:

%USERPROFILE%\.codex\tmp\arg0\codex-arg0*\

When %USERPROFILE% contains non-ASCII characters, the generated wrapper cannot launch the underlying codex.exe from a sandboxed shell. The wrapper is UTF-8 without a BOM and uses LF-only line endings, while cmd.exe parses it using the active legacy code page. The executable path is therefore corrupted before launch.

This fails before patch parsing and is not caused by patch syntax or workspace write permissions.

Generated wrapper

Sanitized content:

@echo off
"C:\Users\<non-ASCII-user>\AppData\Local\OpenAI\Codex\bin\<version-hash>\codex.exe" --codex-run-as-apply-patch %*

Observed byte properties:

Encoding: UTF-8 without BOM
Line endings: LF
Contains a non-ASCII executable path: yes

Decoding those bytes using code page 936 corrupts both the username and an adjacent path separator.

Reproduction

1. Use a Windows account whose %USERPROFILE% contains Chinese or other non-ASCII characters.
2. Start Codex Desktop with the native Windows workspace-write sandbox.
3. Locate the generated wrapper under %USERPROFILE%\.codex\tmp\arg0\codex-arg0*\apply_patch.bat.
4. Run the generated wrapper with no argument.

Actual result:

The system cannot find the path specified.

1. Run the exact target executable directly:

& 'C:\Users\<non-ASCII-user>\AppData\Local\OpenAI\Codex\bin\<version-hash>\codex.exe' --codex-run-as-apply-patch

Result:

Error: --codex-run-as-apply-patch requires a UTF-8 PATCH argument.

This confirms the executable launches successfully and reaches apply-patch argument validation.

1. Pass the same quoted Unicode executable path directly to cmd.exe instead of reading it from the batch file.

Result: the executable again launches successfully and reaches argument validation.

ACL verification

The generated wrapper, its target directory, and codex.exe grant CodexSandboxUsers ReadAndExecute. The active sandbox identity can see the target executable. This is not the earlier WindowsApps ACL failure.

Expected behavior

apply_patch should work when the Windows user profile contains non-ASCII characters. Generated launch helpers should preserve Unicode paths.

Suggested fix

Prefer a Unicode-safe native Windows launcher / CreateProcessW path instead of a generated batch file. If a batch wrapper must remain, generate it in a format that cmd.exe can reliably parse for non-ASCII paths and test it under non-UTF-8 active code pages.

Related issues

• #13840 — apply_patch.bat breaks multiline arguments on Windows
• #13965 — older WindowsApps CreateProcessAsUserW / ACL failure (closed; different root cause)
• #15371 — unstable Windows apply_patch wrapper/interception behavior

The current report is narrower: the target executable is outside WindowsApps, its sandbox ACL is present, and direct execution succeeds. Failure occurs only when the UTF-8 batch wrapper parses a non-ASCII target path.