Codex on Windows: "MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003", how to fix it
Back to the blog
Articlecodexopenaitroubleshootingagente de programaçãodev tools

Codex on Windows: "MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003", how to fix it

MafraOctober 14, 20266 min read

Since October 8, 2026, anyone using the Codex app on Windows who asks a dot to drive the PC's browser has watched the task die before the first tab opens. The call await cua.getState(); comes back with MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003 and the kernel exits with code 1. Issue #52407 passed 80 comments in five days, and #53188 describes the same error.

As of October 14, 2026 there is no official fix. This guide shows what the error means in the Codex source, how to confirm it is your case, and what you can do until the fix ships.

What does "cannot locate required Windows platform directory" mean?

It means the Codex MXC sandbox launcher asked Windows for the path of a system folder and Windows replied that the path does not exist. The code 0x80070003 is Win32 error 3, ERROR_PATH_NOT_FOUND ("The system cannot find the path specified", per Microsoft's documentation).

In the open Codex source, the message comes from the platform_read_roots() function in codex-rs/mxc-sandbox/src/windows.rs. Before launching the sandboxed process, it calls SHGetKnownFolderPath for three folders: Program Files, Program Files (x86) and ProgramData. If any of them fails, the launcher aborts with exactly this message. MXC is the native Windows sandbox backend the app now uses, switched on by the features.prefer_mxc option.

Why does Windows say ProgramData doesn't exist when the folder is right there?

Because the launcher process starts without the SystemDrive environment variable. Windows stores the ProgramData path in the registry as %SystemDrive%\ProgramData (a REG_EXPAND_SZ value under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList). Without SystemDrive, that expansion never happens and the lookup returns 0x80070003.

This cause is not official yet, but several users confirmed it independently in the issue: Procmon captures on different PCs show the launcher reading the registry value and looking up the literal, unexpanded path, and the failing process's environment has no SystemDrive. One report also shows the same lookup failure already happened before version 0.162 of the core, only as a non-fatal warning. With the MXC launcher, it now kills initialization.

Flowchart: browser control won't start with await cua.getState(), the launcher can't find ProgramData (HRESULT 0x80070003), SystemDrive is missing from the environment; if a dot started the task, run it from a local app chat
From symptom to cause to the workaround that works today.

How do I know my error is this one?

Compare against the table. If all four rows match, it is the same problem as #52407.

SignalIn the #52407 case
App versionPackage 26.1007.x, bundled core 0.162.0-alpha.17.2
Where it failsWhile initializing browser control or Computer Use, before listing tabs
Terminal commandsWork normally
Same task in a chat opened directly in the appWorks in most reports; the failure shows up in the task a dot created

To see the installed package version, in PowerShell:

Get-AppxPackage OpenAI.Codex | Select-Object Name, Version

Sometimes the first attempt shows a different message, trusted Node process exited unexpectedly; kernel reset, rerun your request, and only the second attempt reveals 0x80070003. The reports treat both as the same incident.

Can I reproduce the cause on my machine?

Yes, without touching anything in Codex. Open a new PowerShell window, run the block below and close the window afterwards. Remove-Item only affects that session:

Remove-Item Env:SystemDrive
powershell -NoProfile -Command "[Environment]::GetFolderPath('CommonApplicationData')"

With SystemDrive present, the same command returns C:\ProgramData. Without it, a new process returns an empty string. That is the same effect the Codex launcher suffers, described by a user in the issue and consistent with the registry value.

How do I work around the error right now?

Run the browser part in a chat opened directly in the Codex app, on the PC itself, instead of through the task the dot delegated. Several users reported between October 12 and 14, 2026 that on the same computer the local chat listed tabs and navigated while the dot's task failed with 0x80070003.

  1. Let the dot handle everything that doesn't need the browser (code, terminal, files).
  2. For anything that needs the browser, open a new chat directly in the Codex desktop app on the connected PC.
  3. Ask for the same browser action there and check that the tab list comes back.

Restarting the app, restarting Windows, reinstalling or running the package's Repair did not fix it in any of the reports in the issue.

What about allow_mxc = false or the community patch?

allow_mxc = false: the key exists (in the [windows] section, accepted in %ProgramData%\OpenAI\Codex\requirements.toml) and blocks MXC selection. The user who proposed this workaround in the issue withdrew it hours later: browser control came back and broke again the same day. Don't count on it.

Patch to cua-repl.mjs: a user posted in the issue a change to the browser runtime's startup file that fills in SYSTEMDRIVE and LOCALAPPDATA when they are missing and changes the process's working directory. The author and two other people reported recovery with it; another applied it and the error persisted. It edits a file packaged with the app, has no support from OpenAI, and any update overwrites it. If you try it, keep a copy of the original file first.

When will the official fix ship?

No date. We checked the repository on October 14, 2026: there is no fix PR for this path, the latest stable core release is 0.162.1 (October 9) and the 0.163.0-alpha series keeps shipping. The fix users themselves suggest is for Codex to pass SystemDrive to the launcher, as the core already does in the environment for shell commands.

Meanwhile, send feedback from the app when the error happens and paste the Feedback ID into issue #52407. That's what many users are doing to give the team logs from the failing path.

Quick questions

Is this related to "setup refresh had errors"? They are different errors. setup refresh had errors (os error 32) was fixed in version 26.1007.21434, and that same version is where 0x80070003 shows up in dot tasks.

Will changing folder permissions or the registry help? No. The folder exists and its permissions are fine; what's missing is the variable in the process environment. Don't change the ProfileList value in the registry.

If you want a coding agent that runs straight in the terminal, with no browser runtime in the way, Verboo Code works as a CLI and offers unlimited tokens.

Enjoyed this article?
Share knowledge with your network.
// Read also

Related articles