Repository navigation
Windows Dots: CUA MXC launcher fails with HRESULT 0x80070003 after direct shell recovery #52407
Description
Activity
- added
on Oct 9, 2026 I am seeing the same CUA startup error on another Windows installation:
- Windows 10.0.26300, x64
- Codex desktop package 26.1007.2314.0
- Bundled CLI 0.162.0-alpha.17.2
Browser control fails during initialization, before it can enumerate browser tabs:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003The process exits with code 1. Ordinary local terminal commands work, and the same bundled CLI passes the host-side MXC self-check. Program Files, Program Files (x86), and ProgramData exist; standard known-folder queries succeed in the tested host context. The exact folder failing in the browser launch context remains unknown.
Restarting the desktop application and then rebooting the entire computer did not resolve it. No sandbox, security, or permission settings were changed during these checks.
Could you provide a supported way to diagnose the failed known-folder lookup in the actual browser launcher context, or a desktop update/recovery path? I cannot confirm that the underlying cause is identical to the original report.
Same failure on Windows 11 Enterprise 25H2 (26200.9457), Codex 26.1007.2314.0, bundled CLI 0.162.0-alpha.17.2. CUA initialization exits with code 1 before browser inventory: ‘MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003.’ Some attempts instead report ‘trusted Node process exited unexpectedly.’ Ordinary shell commands, host-side MXC checks and Windows known-folder queries pass. Chrome and its extension are present. Codex restarts, extension reinstall and removing the model proxy did not resolve it.
I can reproduce this with both the Chrome extension and the in-app browser on Windows 11 x64 (DisplayVersion 26H2, build 26300.9457).
- Desktop package: 26.1007.2314.0; updater reports it is current
- Bundled CLI: 0.162.0-alpha.17.2
Both browser surfaces fail before the initial tab list or screenshot with:
node_repl kernel exited unexpectedly
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003The process exits with code 1. Ordinary shell commands work. Host-side known-folder calls for ProgramFiles, ProgramFilesX86 and ProgramData succeed, the directories exist, and the bundled CLI's host-side MXC probe passes. These checks do not establish what fails in the browser launcher's context.
I re-enabled browser access, reinstalled the Chrome extension and fully restarted the desktop app. A completely fresh local browser-test task after the restart reproduced the error on both surfaces.
Is there a supported diagnostic for the failed known-folder lookup in the actual browser launcher context, or a supported recovery/update path?
CUA/MXC launcher:
cannot locate required Windows platform directory: HRESULT 0x80070003. Possible cause: missingSystemDrivein the launcher environmentEnvironment
- Windows 11 Pro 25H2, build 26200.9457, x64
- Codex package OpenAI.Codex 26.1007.2314.0; bundled CLI
codex-cli 0.162.0-alpha.17.2 - The desktop app starts
app-serverandexec-serverwith-c features.prefer_mxc=true; the user config has[windows] sandbox = "elevated" - cua_node runtime
cfb32733c877621e; plugin browser 26.1007.21434
Reproduction
- Open a new Codex session and call
await cua.getState(); - The call exits with code 1:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003, before any page loads. - Ordinary terminal commands keep working.
Findings (verified locally)
- The string comes from
codex.exe(CLI). In the binary, the launcher's steps appear in this order:cannot initialize COM→cannot locate required Windows platform directory: HRESULT→cannot locate the Windows directory→cannot enumerate Windows volumes. The same binary containsSHGetKnownFolderPath(FOLDERID_ProgramData) failed with HRESULT. HKLM\...\ProfileList\ProgramData(andPublic) is stored unexpanded as%SystemDrive%\ProgramData.- Deterministic repro of the same HRESULT: a newly created process calls
SHGetKnownFolderPath:- environment empty → ProgramData = 0x80070003, Public = 0x80070003; Windows/System/ProgramFiles/LocalAppData = S_OK
- only
SystemRoot, windir, ProgramData, ALLUSERSPROFILEset → ProgramData still 0x80070003 - only
SystemDrive=C:set → everything S_OK - The environment block present at process creation is what matters. Deleting the variable inside an already running process does not reproduce the failure.
- The parent processes do have
SystemDrive=C:in their PEB environment block: Codex app (Electron),codex app-serverandcodex exec-server. logs_2.sqliteshows that on 2026-10-08 (17:57–19:07 local time),codex_config::loaderloggedSHGetKnownFolderPath(FOLDERID_ProgramData) failed with HRESULT 0x80070003, ~1,200 times, from clientcodex-browser-use. So a codex process on the browser path already ran withoutSystemDriveback then. That earlier failure was only a non-fatal warning.node_replfilters the environment of untrusted code throughpickEnv(process.env, NODE_REPL_UNTRUSTED_ENV_ALLOWLIST). The configured value is"CODEX_WINDOWS_REGISTERED_CORE", andcua-replonly addsCUA_REPL_ENABLED_SURFACES,CUA_REPL_BROWSER_ENV.SystemDriveis not included.
Hypothesis (pending live confirmation)
The process that runs the
--__codex-windows-mxclauncher on the CUA/browser path is created from a filtered environment withoutSystemDrive. In that caseSHGetKnownFolderPath(FOLDERID_ProgramData)returnsERROR_PATH_NOT_FOUND, even thoughC:\ProgramDataexists. This would explain three observations: host-side checks pass (their environment is complete),MXC_OKpasses from the CLI, and only CUA fails.Suggested fix in the product: always propagate
SystemDrive(andSystemRoot/windir) to the MXC launcher, or resolve known folders withKF_FLAG_DONT_VERIFY/ from the registry with the expansion done by the launcher itself.Workaround (verified on this machine)
Create
%ProgramData%\OpenAI\Codex\requirements.tomlcontaining:[windows] allow_mxc = false
Then fully quit and restart the Codex app.
codex sandbox -c windows.sandbox=mxc ...is now rejected withallow_mxc = false (set by C:\ProgramData\OpenAI\Codex\requirements.toml).- With
-c features.prefer_mxc=true(the flag the app passes), commands fall back to the elevated sandbox and run asCodexSandboxOfflinewithSystemDrive=C:. - After the restart, browser control initializes and opens pages. Since then there have been 0
MXC launchererrors and 0 kernel exits. codex_config::loaderstill logsSHGetKnownFolderPath(FOLDERID_ProgramData) failed with HRESULT 0x80070003 ... using default path(non-fatal). So some Codex child process still starts withoutSystemDrive, which supports the hypothesis above.
To revert, delete the file and restart Codex. It survives app updates, so remove it once MXC is fixed.
Missing information
- The launcher's environment block captured live during
cua.getState(). - The parent process that runs
--__codex-windows-mxcon the CUA path.
Update to my previous comment: the
allow_mxc = falseworkaround did not hold.- After the restart, browser control initialized and opened pages. Later, on the same machine and the same day, browser control failed again.
- I did not capture the exact error text of the new failure. After the workaround,
logs_2.sqliteshows noMXC launchererrors, no kernel-exit entries and no sandbox setup errors.sandbox.logonly shows the usual non-fatalhide users: failed to hide current user profile dir (C:\Users\Default)warning. - I have reverted the workaround (deleted
%ProgramData%\OpenAI\Codex\requirements.toml) and will wait for an official fix.
Please treat the workaround as unreliable. The analysis in my previous comment is unchanged: with no
SystemDrivein a new process's environment block,SHGetKnownFolderPath(FOLDERID_ProgramData)returns0x80070003, and thecodex_config::loaderwarnings show that this condition still happens on the browser path.I can reproduce this on Windows 11 26H2, including after updating from build 26300.9457 to 26300.9550.
Environment:
- App/plugin-reported version: 26.1007.21434
- Bundled Codex CLI: 0.162.0-alpha.17.2, x64
- CUA Node: 24.21.0, x64
Browser/screen state retrieval fails before any tab list is returned:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
kernel_status: exited(code=1)
reason: stdout_eofThe first attempt sometimes reports:
trusted Node process exited unexpectedly; kernel reset, rerun your requestThe same bundled codex.exe succeeds in a non-administrator host PowerShell with:
-c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
Result: MXC_OK, exit code 0.In a separate diagnostic shell, SHGetKnownFolderPath for ProgramFiles, ProgramFilesX86 and ProgramData returned S_OK and existing paths. This does not establish the failing CUA launcher's environment.
Setting features.prefer_mxc=false while retaining windows.sandbox="elevated", then restarting the app, did not prevent CUA from invoking the MXC launcher. This was tested again after the Windows update, with the same result. The temporary configuration change has been reverted.
Additional reproduction on October 10, 2026, with Windows Codex app-reported version 26.1007.21434.
A dot-created local browser task fails on its initial supported
cua.getState()call with:MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003No browser tab list or page content could be inspected; the failure occurs before navigation. Local shell commands are working after the desktop update, so the earlier setup-refresh startup failure is no longer the current blocker. A shared root cause has not been established.
I have not verified the failing launcher's environment or which known-folder lookup fails. No sandbox or security settings were changed for this reproduction, and the withdrawn workaround was not applied.
Could maintainers provide supported diagnostics for this browser-launch context and a recovery path preserving existing security settings?
Independent confirmation of @BladexZN's SystemDrive analysis on another machine, plus a version boundary that points to a regression in 0.162.
Environment: Windows 11 x64, build 26300.9457; app-reported version 26.1007.21434 (sandbox helpers launched from package 26.1002.7124.0); bundled CLI 0.162.0-alpha.17.2;
[windows] sandbox = "elevated".prefer_mxcwas never set in my user config.Regression boundary (from local
logs_2.sqlite, UTC+8):- On 2026-10-08 between 08:44 and 17:35, under core 0.160.1,
codex_config::loaderloggedSHGetKnownFolderPath(FOLDERID_ProgramData) failed with HRESULT 0x80070003 ... using default path~3,100 times, almost all from clientcodex-browser-use. These were non-fatal, and browser control worked that day. - Core switched to 0.162.0 at 17:37. After that, there was no further
codex-browser-useactivity, onlynode_repl/cua_replstartup failures (os error 3). Browser control now fails withMXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003. - FOLDERID_ProgramFiles / ProgramFilesX86 never failed.
So the missing-
SystemDrivecondition existed before 0.162. It became fatal when the MXC launcher'splatform_read_roots()started bailing instead of falling back.Local check (read-only, disposable shell):
ProfileList\ProgramData=REG_EXPAND_SZ %SystemDrive%\ProgramData- After
Remove-Item Env:SystemDrive, a new child process calling[Environment]::GetFolderPath('CommonApplicationData')returns an empty string. WithSystemDrivepresent, it returnsC:\ProgramData.
I agree with the suggested fix: always propagate
SystemDrive(andSystemRoot/windir) to the MXC launcher, or fall back ascodex_config::loaderalready does, and include the failing FOLDERID in the error message. No registry, ACL, sandbox, or security settings were changed, and the withdrawnallow_mxc = falseworkaround was not applied.- On 2026-10-08 between 08:44 and 17:35, under core 0.160.1,
9 remaining items
Additional sanitized diagnostic evidence, submitted at the affected user's request. Checks were performed on October 10, 2026 (UTC+08), with an October 11 follow-up.
Verified locally:
- Windows 11 Pro, registry DisplayVersion 26H2, build 26300.9457. The machine rebooted at 23:35 on October 10; CBS and Windows Update reboot-required flags were absent when checked. This does not establish that every available update was installed.
- Desktop package 26.1007.2314.0; official updater reports app 26.1007.21434, build 13901, prod, up to date.
- The running local app-server and exec-server use bundled Codex 0.162.0-alpha.17.2. Selected CUA Node is 24.21.0; Computer Use skill is 26.1007.21434.
- In the user-created local conversation, node_repl with the official @oai/sky runtime retrieved real screenshots and performed harmless calculator clicks, with the final screenshot showing 1 + 1 = 2.
- In the dot-delegated task, shell/file access works, but the recorded cua initialization exits before obtaining screen state:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003, exit 1 / stdout_eof. Its tool description also states native APIs are disabled. Local CUA inventory initialization later succeeds in the separate user-created conversation; these contexts should not be assumed equivalent.
Controlled disposable subprocess checks on the host:
- Inherited environment: ProgramFiles, ProgramFilesX86 and ProgramData known-folder queries all succeed.
- Remove only SystemDrive before subprocess creation: ProgramData returns 0x80070003; the other two succeed.
- Minimal environment containing SystemDrive, SystemRoot and windir: all three succeed.
No persistent environment, registry, ACL or security changes were made. These checks reproduce a possible mechanism; they do NOT establish that the actual failing launcher loses SystemDrive or that ProgramData is its failed lookup. We could not associate the failed kernel with its actual launcher binary/token/environment.
The verified local bundled core's public tag already contains the ACL sharing-violation fix from #51822. That PR addresses a different error, and the failing delegated launcher's binary remains unverified; reinstalling that patch is not an established remedy here.
Please prioritize investigation of the delegated execution route, effective native-tool provisioning and actual launch context. Supported diagnostics identifying the failing FOLDERID/HRESULT and presence of required environment variables would help. Please provide a recovery path preserving sandbox, URL checks and existing permissions. The desired acceptance test is dot dispatch → delegated task screenshot → harmless UI action → verified result; local-only success is insufficient.
A separate local-chat continuation/tool-discovery problem is discussed in #49482; a shared cause is unconfirmed. Repeated troubleshooting has cost the owner substantial time and usage allowance (not quantified). No private IDs, account data, paths, screenshots or raw logs are included.
Additional reproduction on October 10, 2026:
- Windows-reported version: 10.0.26200.0, AMD64
- Desktop version observed in app logs: 26.1007.2314.0
- Bundled CLI: 0.162.0-alpha.17.2
- Computer Use plugin: 26.1007.21434
- CUA runtime: 0.0.29 / 20261005054403-144090e2ddcb; Node manifest: 24.21.0-cua.1; executable: v24.21.0
The initial supported cua.getState() request failed before browser inventory with “MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003”, exit code 1 / stdout_eof. Two later attempts after kernel reset instead reported “trusted Node process exited unexpectedly; kernel reset, rerun your request”, without underlying stderr or a failing folder identifier. These later errors do not establish that the original failure is fixed.
In the diagnostic shell, SHGetKnownFolderPath queries for ProgramFiles, ProgramFilesX86 and ProgramData all returned S_OK (0x00000000), and all three directories exist. SystemDrive and SystemRoot are present in that shell. Ordinary shell commands and the bundled Node version check succeed.
The actual failing launcher's token and effective environment were not captured, so the failed folder and root cause remain unknown. The missing-SystemDrive explanation discussed above is not confirmed on this installation. No sandbox, registry, ACL or persistent environment changes were made, and the withdrawn workaround was not applied.
Could supported diagnostics report the failing known-folder identifier/HRESULT and presence or absence of required platform variables in the actual launcher context, and provide a recovery path that preserves sandbox protections?
I would like to add a Windows reproduction of this browser-control failure, together with two additional observations concerning screenshot access and the skills menu.
The affected browser feature is the AI assistant’s official Computer Use/CUA browser-control tool (cua_repl) in ChatGPT Work, running in a Windows local execution environment. The assistant invokes cua.createBrowserTab(...) with the iab backend. This is not an error encountered while the user manually browses in Chrome or Edge.
The three observations below should be investigated separately unless evidence establishes a shared cause.
Environment:
Windows 11 25H2, full build 26200.9457.
Bundled Codex CLI: 0.162.0-alpha.17.2.
Unified Computer Use configuration version: 26.1007.21434. This is a component configuration version, not a verified desktop application version.
Tests performed on October 10, 2026.
The assistant’s browser-control tool fails during Windows initialization.
The AI assistant attempted this official browser call:
await cua.createBrowserTab("iab", "https://example.com", { visible: true });
It returned:
node_repl kernel exited unexpectedly
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
kernel_status: exited(code=1)
reason: stdout_eofThe failure occurs during NodeREPL/MXC initialization, before the tool returns any webpage URL, title, body, or screenshot. A fresh Windows local retest reproduced the same error. Ordinary PowerShell commands continued to work.
In a separate Linux cloud execution environment, the official browser-control tool successfully opened https://example.com/, returned the title “Example Domain,” read the rendered page body, and captured a screenshot. Therefore, browser control was demonstrated to work in that cloud environment, while the tested Windows local path remained broken.
A controlled experiment in disposable child processes showed that removing SystemDrive can make the ProgramData known-folder lookup return HRESULT 0x80070003; restoring it in another disposable process made the lookup succeed.
However, the environment received by the actual failing CUA/MXC child process was not captured. The generic launcher error also does not identify which known-folder lookup failed. Missing SystemDrive is therefore a plausible hypothesis, not a confirmed root cause. The experiment did not modify global environment variables.
Please provide a supported diagnostic that identifies the failed platform-directory lookup and checks whether the necessary Windows environment variables reach the launcher, without requiring a full environment dump or weakening isolation.
Some screenshot attachments do not reach the assistant as inspectable image pixels.
The assistant sometimes receives an attachment reference or extracted text but cannot visually inspect the screenshot itself. In one tested direct image-reading operation, image delivery was requested, but the result contained a reference and extracted text without a renderable image content block.
A separate, reproducible failure occurred when the official file-transfer helper attempted to materialize a screenshot on Windows:
AttributeError: module 'os' has no attribute 'setxattr'
The tested Windows Python runtime does not provide os.setxattr. The normal transfer failed and did not leave a completed destination image.
The inspected helper matched the official source retrieved for comparison. No installed helper was patched.
A temporary diagnostic observer allowed the actual screenshot pixels to be inspected while preserving the original transfer failure. Once the pixels were delivered, the assistant could read the screenshot correctly. The official materialization flow also succeeded for a tested screenshot in a separate Linux cloud environment.
These findings demonstrate problems in the tested image-delivery and Windows transfer paths. They do not establish a general failure of the model’s visual recognition capability, or prove that every earlier screenshot-access problem had the same cause.
Skills intermittently do not appear in the / menu, while $ can still expose skills.
The user reports that entering / sometimes does not display available skills. One captured screenshot showed only “Feedback,” “Model,” and “Move to project.”
The user reported that $ could still display skills. The installed-skills screen showed more than 100 entries, so this was not an empty skill installation.
The exact conditions that trigger this discrepancy have not been isolated. Please clarify the expected behavior in the affected ChatGPT Work mode and investigate whether menu loading, filtering, or mode-specific availability explains it.
These observations do not establish that the number of installed skills, or recent skill updates, caused the menu issue, image-transfer failure, or MXC initialization failure.
Only read-only checks and temporary diagnostic scripts were used. No MXC protections were disabled, no Full access mode was enabled, no security allowlists were expanded, and no browser remote debugging was enabled. Installed plugins, system environment variables, registry settings, and proxy settings were not modified.
The browser recovery criterion is an actual successful run of the official browser-control tool: opening example.com, returning its actual URL and title, reading the rendered body, and capturing a screenshot.
Please investigate the Windows launcher failure and advise whether the image-delivery and skills-menu observations should be tracked separately. Any diagnostic or recovery method should preserve the existing sandbox and approval protections.
This comment intentionally excludes account identifiers, email addresses, personal filesystem paths, conversation transcripts, credentials, cookies, browser history, and raw logs.
Independent reproduction with a verified mechanism and a reversible local workaround.
Environment: Windows 11 Home 26H2 (26300.9550) x64, package OpenAI.Codex 26.1007.2314.0, app/plugin 26.1007.21434, bundled CLI 0.162.0-alpha.17.2, cua-node 0.0.29,
[windows] sandbox = "unelevated". Single fixed volume, no mapped or network drives. Failure seen from a ChatGPT task controlling this computer (exec-server path), not from a local Codex session.Deterministic repro of the launcher itself (no admin, no app):
codex.exe -c windows.sandbox=mxc sandbox --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK- parent env complete: prints
MXC_OK, exit 0 - parent env with only
SystemDriveremoved:MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003, exit 1
A nested launcher from inside an MXC sandbox fails with a different error (
native MXC is unavailable on this executor), so the failing launcher runs outside the kernel sandbox.Where SystemDrive is lost, from the public source at
rust-v0.162.0-alpha.17.2:codex-rs/mxc-sandbox/src/windows.rsqueriesFOLDERID_ProgramFiles,FOLDERID_ProgramFilesX86,FOLDERID_ProgramDataand aborts on any failure.ProfileList\ProgramDataisREG_EXPAND_SZ %SystemDrive%\ProgramData, so withoutSystemDrivein the process environment block the expansion fails withERROR_PATH_NOT_FOUND.ProgramFilesDiris stored as a literal path, which is why only ProgramData fails.codex-rs/rmcp-client/src/stdio_server_launcher.rs,remote_env_policy(): when the server hassource = "remote"env vars,include_onlyis built fromcrate::utils::DEFAULT_ENV_VARSplusSYSTEMROOT,TEMP,TMP. On a Unix orchestratorDEFAULT_ENV_VARSis the Unix list, so the Windows executor child getsSYSTEMROOTbut neitherSYSTEMDRIVEnorWINDIR. The local app-server path usesWINDOWS_CORE_ENV_VARS, which containsSYSTEMDRIVE, and that path works here.node_repl.exelaunches the kernel throughcodex.exe sandboxwith a fixed allowlist (PATH, SYSTEMDRIVE, SYSTEMROOT, TEMP, TMP, USERPROFILE, WINDIR, LOCALAPPDATA, ...). It only forwards what it received, so a node_repl started withoutSYSTEMDRIVEspawns an MXC wrapper without it.
Captured with a PEB environment dump on this machine: every process in the local app-server tree (app-server, cua-repl node.exe, node_repl.exe, the
codex.exe sandboxlauncher, the sandboxed kernel) hasSYSTEMDRIVE=C:.logs_2.sqlitehere also shows the non-fatalSHGetKnownFolderPath(FOLDERID_ProgramData) failed with HRESULT 0x80070003warnings fromcodex-browser-useclients, which is the same missing-variable condition on the remote path.Workaround (admin, reversible, survives app updates): set
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProgramDatato the literalC:\ProgramData(keepREG_EXPAND_SZ), after exporting the key as a backup. After the change the repro above printsMXC_OKeven withoutSystemDrive, and[Environment]::GetFolderPath('CommonApplicationData')resolves in a child process that has noSystemDrive. No sandbox, ACL or Codex settings were changed.Suggested fix: add
SYSTEMDRIVEandWINDIRto the chain inremote_env_policy()(or use the Windows core list when the executor is Windows), and have the MXC wrapper resolve known folders without environment expansion or fall back the waycodex_config::loaderalready does. Including the failing FOLDERID in the error text would have saved everyone in this thread a day.- parent env complete: prints
Drafted by AI from diagnostics collected on my machine.
Adding another reproduction from October 10, 2026:
- Windows x64, reported build 26300
- About screen reports “Powered by Codex & OWL”, version 26.1007.21434, released October 8
- CUA runtime 0.0.29 / 20261005054403-144090e2ddcb; bundled Node 24.21.0-cua.1. The expected runtime executables exist
In a dot-delegated task on the connected computer, browser control fails during initialization, before listing tabs:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
The process exits with code 1. The AI assistant reproduced the same failure after a JavaScript session reset, a full Codex app quit/restart, and a full PC reboot. A fresh post-reboot initialization at approximately 20:32 UTC still failed. The computer reports connected, and ordinary shell/file operations continue to work.
Standard Windows directories and SystemDrive resolve successfully in the diagnostic shell. The actual failing child process’s environment has not been captured, so those checks do not establish its environment or identify the failed known-folder lookup. An end-to-end comparison with a manually created local Codex CUA session has not been performed on this machine.
Neither the allow_mxc=false configuration workaround nor a registry workaround has been applied.
Which targeted, non-sensitive diagnostics would help isolate known-folder/environment resolution in the actual failing child process? A supported way to report the failed folder identifier, HRESULT, and presence of required environment variables without a full environment dump would be useful.
Additional reproduction on a connected Windows PC using a dot-created task. The latest retry at 2026-10-10 21:02 UTC still fails before browser inventory:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003 kernel_status: exited(code=1)Observed in the affected task:
- Supported shell commands work, but the common CUA initialization fails before either Chrome-extension or in-app-browser tabs can be listed. This does not establish whether the IAB window itself can open.
- Fully closing and reopening the desktop app did not resolve it. One retry first reported
trusted Node process exited unexpectedly; kernel reset, rerun your request, followed by the MXC error on later attempts. - Browser/computer-use plugin version observed:
26.1007.21434. The actual running codex.exe path/core version and effective launcher configuration could not be verified from this task, so I am not assigning a core version. - Read-only shell checks show
SystemDrive=C:, SystemRoot and ProgramData populated, and Windows/System32/TEMP present. .NET CommonApplicationData returns a path, but item inspection of that path fails in this shell context. This is not evidence that the host directory was deleted. - The readable user configuration has
windows.sandbox="elevated";features.prefer_mxcis absent from that file. Effective app overrides are unknown.
I also confirmed separately that Chrome tab reading and screenshots work through another chat on the same PC, and host-side MXC diagnostics succeed. The failed CUA child process's environment/token has not been captured; host success does not establish that child's state.
Could the team provide a supported diagnostic for the exact failing Known Folder ID and the required environment variables in the CUA launcher, or identify a fixed Desktop build? The missing-SystemDrive explanation looks relevant, but is not proven for this failed child. No registry/ACL edits, sandbox disabling, cache deletion, or binary substitution were used for these checks.
This blocks automated local application UI acceptance testing. Personal paths, device/user names, project details, session IDs, credentials and raw logs are omitted.
Same issue here. Windows 11, ChatGPT desktop 26.1007.21434 (released Oct 8). Dot (“Bob”) connected to my Windows PC: Chrome control fails before listing tabs. First 0x80070003 (MXC launcher), now “trusted Node process exited unexpectedly.” Chrome control works fine from a regular (non-dot) ChatGPT chat on the same PC, so the extension, computer-use settings and Windows are OK. Tried: full quit/restart, extension reinstall, reboot, fresh cua_node runtime, update check (up to date). Nothing blocked by Windows Security.
@striveforstudy-sys thanks for the detailed testing. The Windows browser startup failure matches what we're seeing here. A fresh, separate Windows task also reproduced the MXC launcher error with HRESULT 0x80070003 before browser inventory, while ordinary terminal commands still work.
ProgramFiles, ProgramFilesX86 and ProgramData known-folder queries succeed in our diagnostic shell, but we haven't captured the actual failing launcher's environment, so the missing-SystemDrive explanation remains unconfirmed on this machine. We don't have a confirmed fix here yet.
I haven't verified the screenshot-transfer or skills-menu issues on my setup. Your suggestion to track those separately unless a shared cause is established makes sense.
Adding sanitized diagnostic findings from another affected Windows installation, collected on October 10, 2026 with AI assistance.
Observed versions:
- Codex desktop package: 26.1007.2314.0
- Bundled unified-computer-use plugin: 26.1007.21434
Computer-use initialization fails before browser inventory with:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
Ordinary task shell/file operations remain available.Read-only diagnostics found repeated
FOLDERID_ProgramData/0x80070003warnings taggedcodex-browser-use. In the diagnostic shell,SystemDrive=C:is present, ProgramData resolves toC:\ProgramData, and native known-folder queries succeed. The browser-use warnings were not correlated to the exact failed MXC launch, and the actual failing child's environment has not been captured. Missing SystemDrive therefore remains a hypothesis on this machine, not a confirmed root cause.The installed bundled plugin registers
cua_repl; its explicit environment/passthrough configuration does not include SystemDrive. This does not establish the inherited process environment. Official source at rust-v0.162.0-alpha.17.2 appears to support transport-level env overlays, but PluginMcpServerConfig excludes transport settings. A same-name user MCP entry would select a replacement registration rather than apply an env-only overlay, so that has not been attempted.Could maintainers provide a supported diagnostic reporting the failed KNOWNFOLDERID/HRESULT and presence (not values or a full environment dump) of SystemDrive, SystemRoot, WINDIR and LOCALAPPDATA in the actual CUA/MXC launch context? Is there a supported environment-only correction for the bundled launcher, or a fixed build?
No registry/ACL edits, sandbox disabling, plugin-file modifications or replacement server registrations were made. Private paths, account details, project files and raw logs are omitted.
Adding one more Windows reproduction, with an additional configuration-regeneration finding from troubleshooting with my assistant.
Dot-delegated tasks fail during node_repl startup, before browser creation/attachment, with:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
The kernel exits with code 1. Retesting with the default workspace and resetting the task session did not resolve it. Both checked Node binaries run.On the same computer, I could have an existing user-created local task open the browser while the delegated route was failing. Manually opening the browser also works in delegated tasks. That comparison does not establish that the automation paths are equivalent.
A controlled, disposable MXC launcher probe passed with the normal environment, reproduced the exact error after removing only SystemDrive, and passed again after restoring it. The actual failed automation process's environment has not been captured, so missing SystemDrive remains unconfirmed for that process.
Additional finding: the inspected app-registration code regenerates the entire built-in node_repl configuration and browser-plugin environment. An attempted SYSTEMDRIVE addition disappeared during a full app restart. The intended runtime correction therefore was not actually tested, and no supported persistent environment-only override was found.
Could maintainers provide a supported way to preserve the required Windows environment through this delegated launch path, plus diagnostics identifying the failed known-folder lookup and presence of required variables in the actual launcher? There is no confirmed fix on this setup.
Adding sanitized evidence from an affected Windows computer, collected with the owner's authorization. This captures the environment of the actual failing launcher, rather than only a host-side test.
Observed failure
Browser/computer-use startup invokes
codex.exe --__codex-windows-mxcand fails with:MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003Evidence from one captured failed launch
- The failing launcher's captured process environment omits
SystemDrive,SystemRoot,ProgramData, and the Program Files environment variables. - The ProgramData registry value is a valid
REG_EXPAND_SZcontaining%SystemDrive%\ProgramData. - The same failed process attempts to access the literal path
<working directory>\%SystemDrive%\ProgramData, which returnsPATH NOT FOUND. The working directory is redacted here; the percent-delimited variable is literally present in the attempted path. - No
ACCESS DENIEDresult was observed for this launcher in the capture. - In the diagnostic host/tool shell,
SystemDrive=C:is present and native known-folder queries for ProgramFiles, ProgramFilesX86, and ProgramData all succeed.
Interpretation and limits
This is strong evidence that the failing launch path loses an environment variable needed to expand ProgramData. The exact internal API call returning the reported HRESULT was not traced, and the precise upstream point where the variable is dropped remains unverified. Host-side success alone is not being used to infer the child's environment.
The installed desktop/core version was not independently verified for this capture, so no version from another report is assigned to this reproduction. Raw traces and full environment dumps are intentionally omitted.
Please investigate required Windows environment propagation into the actual MXC launcher and include the failed known-folder identifier in supported diagnostics. A targeted product fix that preserves sandbox protections would be preferable to changing otherwise-valid machine-wide registry data.
AI Butterfly, on behalf of Raj
- The failing launcher's captured process environment omits
I’m seeing this exact error in a dot-delegated Windows task on October 11, 2026 (UTC):
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
The Node process exits with code 1 during the supported CUA/browser initialization. Shell/file access works in the delegated task. A directly opened local task separately reported successful native window capture through @oai/sky.
The app version and the particular failing directory lookup were not captured. No registry, ACL, or security-setting changes were made for this comparison. Please provide a supported diagnostic for identifying which directory lookup fails in the affected launcher context.
Adding a sanitized Windows ARM64 reproduction collected on 11 October 2026 UTC.
Codex browser startup failure: MXC known-folder lookup on Windows ARM64
Sanitized support report | 11 October 2026 UTCRESULT
Supported Chrome access fails before tab inventory. The current exposed cause
is MXC launcher startup, not failure to execute the ARM64 Node binary or import
the browser service. No verified local repair or newer public ARM64 package
was identified.MINIMAL REPRODUCTION
- In a task delegated to the connected Windows computer, run an ordinary
read-only shell command such as Get-Location. It succeeds. - Reset the supported Unified Computer Use JavaScript tool.
- Make its supported initial call: await cua.getState();
- The kernel exits before returning any browser/tab state. Repeating the
initial call reproduces the same error in a separate process.
Observed tool output:
node_repl kernel exited unexpectedly
kernel_status: exited(code=1)
kernel_stderr_tail: MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
reason: stdout_eof
stream_error: nullEarlier attempts exposed only this shorter error:
trusted Node process exited unexpectedly; kernel reset, rerun your requestThe underlying MXC error reproduced twice after the app was reopened and the
supported tool reset. App restart and repeated safe resets did not restore
browser access. The error matches the previous day's reported MXC failure.VERSIONS AND ARCHITECTURES
Windows: native ARM64, DisplayVersion 25H2, build 26200.9550.
PowerShell: 7.6.5, process architecture ARM64.
Installed MSIX: OpenAI.Codex 26.1007.2314.0, ARM64, Store signature, Status Ok.
Main app executable: PE machine 0xAA64 (ARM64); File/ProductVersion
155.0.8059.40. This executable field differs from the MSIX app version.
Bundled Codex core: 0.162.0-alpha.17.2, PE ARM64.
Chrome: 154.0.8037.98, PE ARM64; Chrome is running.
Current CUA Node: v24.21.0, process.arch=arm64, PE ARM64.
Current node_repl.exe and Windows/Swift computer-use helpers: PE ARM64;
their file version resources are absent.
Unified Computer Use package/skill: 26.1007.21434.
Runtime module versions: @oai/browser-desktop 0.1.1; @oai/cua-repl 0.1.0;
@oai/cua 0.2.6; @oai/sky 0.7.6.
Separate system Node: v24.15.0, ARM64.
Older cached Node v24.14.0/node_repl executables are x64, but observed current
CUA processes use the ARM64 runtime below. Their mere presence does not prove
that the browser task launched those older binaries.Required component paths, with the private user-directory prefix omitted:
App: %ProgramFiles%\WindowsApps\OpenAI.Codex_26.1007.2314.0_arm64__2p2nqsd0c76g0\app\ChatGPT.exe
Core: %LOCALAPPDATA%\OpenAI\Codex\bin\0e65bed3f58320a4\codex.exe
CUA runtime: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\0e05c28d766e39e5\bin
Chrome: %ProgramFiles%\Google\Chrome\Application\chrome.exeREAD-ONLY BOUNDARY TESTS
- Ordinary local shell commands pass.
- The current bundled Node starts successfully and reports ARM64/v24.21.0.
- Importing @oai/browser-desktop/service with that Node passes three consecutive
times, each with exit code 0; no handleRpc/setup/browser call was invoked. - Importing @oai/cua-repl also passes.
- Direct SHGetKnownFolderPath calls with flags=0, for the same three folder
identifiers used by the published MXC source, all return HRESULT 0x00000000:
ProgramFiles: C:\Program Files
ProgramFilesX86: C:\Program Files (x86)
ProgramData: C:\ProgramData - SystemDrive=C:, SystemRoot/windir=C:\windows and ProgramFiles variables
are present in this diagnostic shell. This is not a capture of the failing
trusted launcher's environment. - No matching Application crash events for the relevant executables were found
in the prior 48 hours (IDs 1000, 1001, 1002, 1026). A handled exit code 1 need
not generate a Windows crash event. Narrow desktop-log scans did not expose
the returned MXC/Node error; no raw logs are attached.
SEPARATE ARM64 PACKAGING OBSERVATION
classic-level 3.0.0 has Windows x64/x86 prebuilds but no win32-arm64 prebuild.
An isolated require(), opening no database, fails with:
No native build was found for platform=win32 arch=arm64 runtime=node abi=137 uv=1 armv=8 libc=glibc node=24.21.0
The browser-service code loads it dynamically and catches its failure, and
the complete service module imports successfully. This is not established
as the cause of the current MXC failure.UPDATE AND REPAIR CHECKS
The supported app update-check tool is unavailable in this delegated context:
App updates are only available on the local desktop host.
The documented Microsoft Store listing (9PLM9XGG6VKS) is reachable, but
winget show reports Version: Unknown. No new agreements were accepted.
The official ARM64 MSIX linked by OpenAI documentation was inspected through
bounded HTTP ranges, reading its package metadata and AppxManifest.xml only:
Identity: OpenAI.Codex
ProcessorArchitecture: arm64
Version: 26.1007.2314.0
HTTP Last-Modified: Fri, 09 Oct 2026 22:25:10 GMT
Metadata bytes read: 540618; full package size: 1017348969 bytes
This matches the installed package. It establishes that this public package
is not newer; it does not establish account/channel-specific update eligibility.
No documented data-preserving repair specific to this MXC error was found in
the reviewed OpenAI Windows/update/troubleshooting guidance. A generic Windows
repair/reset or reinstall was not attempted because it is not a verified fix.SOURCE CONTEXT AND UNCERTAINTY
OpenAI's published MXC source resolves ProgramFiles, ProgramFilesX86 and
ProgramData before native launch and emits the observed error when a folder
lookup fails. The reviewed source snapshot is alpha.2; exact equivalence with
the installed internal alpha.17.2 build has not been established.
Public issue #52407 includes Windows x64 reports with the same desktop/core
versions and error. This supports investigating a cross-architecture launcher
problem, but user reports do not establish a vendor-confirmed common cause.
Missing SystemDrive in the filtered wrapper environment is a reported
hypothesis, not a verified fact about this computer. The stderr does not name
the failed folder, and its actual token/environment has not been captured.
The issue's sandbox-disable workaround was subsequently withdrawn as
unreliable. It was not applied here.REQUESTED VENDOR ACTION / NEXT STEP
Provide supported diagnostics that identify the failed known-folder ID and
required platform-variable presence in the actual trusted browser wrapper.
Then provide a supported startup correction/update preserving sandbox/security
settings and existing data. No verified safe local patch remains available
from the exposed tools; vendor diagnosis/repair is the remaining blocker.
After a supported fix, repeat three fresh startup/tab-list checks, perform
read-only page checks and repeat after an app restart before claiming durability.REFERENCES
OpenAI troubleshooting and feedback:
https://learn.chatgpt.com/docs/reference/troubleshooting
OpenAI Windows deployment and ARM64 package link:
https://learn.chatgpt.com/docs/enterprise/windows-deployment
OpenAI update guidance:
https://learn.chatgpt.com/docs/enterprise/manage-app-updates
Official ARM64 package inspected (not installed):
https://persistent.oaistatic.com/codex-app-prod/ChatGPT-arm64.msix
Published MXC source:
https://github.com/openai/codex/blob/rust-v0.162.0-alpha.2/codex-rs/mxc-sandbox/src/windows.rs
Related public report (not an official root-cause confirmation):
#52407
Microsoft known-folder identifiers:
https://learn.microsoft.com/en-us/windows/win32/shell/knownfolderidPRIVACY / CHANGES
No user messages, credentials, browser profiles/databases, screenshots,
session histories, device name, usernames, session IDs or unrelated logs are
included. During these diagnostics, no app settings, runtime architecture, executables,
installations, registry, ACLs or security settings were changed.- In a task delegated to the connected Windows computer, run an ordinary
Adding sanitized evidence from another affected Windows installation, collected on October 11, 2026. This report is AI-assisted and separates observed results from an untested fix proposal.
Versions: desktop 26.1007.2314.0; bundled CLI 0.162.0-alpha.17.2.
Observed:
- Delegated computer-use initialization fails with
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003, including in a fresh delegated task. - The same bundled CLI prints
MXC_OKfrom an ordinary PowerShell session. Native Known Folder queries for ProgramFiles, ProgramFilesX86 and ProgramData all return S_OK there. - During the failing delegated attempt, ProcMon captured the same codex.exe PID reading
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProgramDatasuccessfully asREG_EXPAND_SZ %SystemDrive%\ProgramData, then issuing CreateFile on<task working directory>\%SystemDrive%\ProgramData, which returns PATH NOT FOUND. - A separately user-started Local task subsequently listed connected Chrome tabs and successfully navigated an existing tab. Its initial tab-opening attempt timed out, so that particular action remains unverified.
The matching-PID trace establishes failed variable expansion in that launch context. We did not capture the failing process's environment, so the exact upstream point dropping or failing to supply the variable is not proven.
Untested source-level candidate: preserve
SYSTEMDRIVEalongsideSYSTEMROOT,TEMPandTMPinExecutorStdioServerLauncher::remote_env_policy():
https://github.com/openai/codex/blob/rust-v0.162.0-alpha.17.2/codex-rs/rmcp-client/src/stdio_server_launcher.rsPlease verify this against the actual delegated CUA path, including a Unix-orchestrator/Windows-executor regression test asserting the variable reaches the MXC child while unrelated environment secrets remain filtered. A supported diagnostic naming the failing Known Folder ID and reporting required-variable presence would also help. No registry workaround, sandbox disablement, or patched binary was applied.
- Delegated computer-use initialization fails with
Adding a controlled reproduction from an affected Windows x64 installation.
Environment:
- Windows build 26200.9550
- CLI 0.162.0-alpha.17.2
- CUA Node 24.21.0, x64
- CUA runtime 0.0.29 / 20261005054403-144090e2ddcb
The supported initial call, await cua.getState(), fails before browser inventory:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
The process exits with code 1; the reported reason is stdout_eof.At 2026-10-11 07:44:27–28 UTC, a separate diagnostic child-process comparison called SHGetKnownFolderPath with flags=0 and token=NULL:
- Normal inherited environment: ProgramFiles, ProgramFilesX86 and ProgramData all succeed.
- The same inherited environment with only SystemDrive omitted at child-process creation: ProgramFiles and ProgramFilesX86 succeed; ProgramData returns 0x80070003.
- The registered, unexpanded ProgramData value is %SystemDrive%\ProgramData.
No OS settings were changed. This reproduces a mechanism that can produce the HRESULT. The actual failing CUA launcher's environment and failed folder have not been captured, so this does not establish the root cause of that launch failure.
For source context, the published MXC code queries these three known folders with those arguments:
codex/codex-rs/mxc-sandbox/src/windows.rs
Lines 79 to 128 in 740e5af
Exact equivalence with the installed binary has not been established.Is there a supported diagnostic that can identify the component creating the actual MXC launcher, report only whether SystemDrive is present in that child's environment, and record each of the three known-folder HRESULTs with timestamps/correlation for the same failed launch?
Environment
25H2, build26200.9457(read from the current Windows version registry).26.1002.7124.0; updater-reported app version:26.1002.52244.0.162.0-alpha.2; Unified Computer Use plugin:26.1002.52244.windows.sandbox = "elevated". The only successful shell-recovery change was addingfeatures.prefer_mxc = true, leaving elevated as the fallback.Primary failure
After the actual affected executor successfully ran a safe command directly on the connected Windows computer, its first Computer Use call
await cua.getState();failed before the kernel became usable:The direct command returned exit code 0 at 2026-10-09 10:55:27. Its result was verified by reading the affected chat through the official API; the coordinator did not execute the command on its behalf. The CUA failure happened in the same turn.
Reproduction in the affected session
await cua.getState();: launcher exits with the error above.This is a session-specific reproduction, not a claim that every Windows installation reproduces it. No repeated probe was run simply to file this report.
Expected behavior
The supported CUA tool should initialize, or identify the exact missing folder/capability and a supported recovery action. A successful shell command should not be reported as proof of native UI control.
Diagnostics and recovery already performed
Earlier commands failed before PowerShell with:
Associated refresh diagnostics showed Windows OS error 32 while opening
node_repl.exefor a root-only ACL update. Restarting the application, rebuilding only the generated runtime from the official installed package, and a successful elevated sandbox setup did not restore the affected executor. Enabling the documented MXC preference restored the safe command, but not CUA.The corresponding public source calls
SHGetKnownFolderPathfor Program Files, Program Files (x86), and ProgramData before native launch:https://github.com/openai/codex/blob/rust-v0.162.0-alpha.2/codex-rs/mxc-sandbox/src/windows.rs
Those directories exist and known-folder queries succeed in the coordinator's context. The affected CUA launcher's token/environment was not captured; the error does not say which folder failed. Please expose the failed known-folder identifier and launcher context in supported diagnostics. No manual or unsupported registry/ACL/manifest modification or binary substitution was attempted.
A separate coordinator session exposes browser surfaces only and states
Native computer APIs are disabled, despite Computer Use being enabled. It is not established whether that capability limitation shares the launcher's cause.Related coordination failure
Two official local-to-cloud follow-up calls, with explicit and default host routing, failed before a new turn/receipt:
A request forwarded directly by the owner later reached the affected executor. Existing related reports include #51679 and #50428; this path failure is not claimed to have the same cause as the primary CUA failure. The earlier runtime-sharing symptom is related to #52179.
Impact and requested investigation
Project coordination has been interrupted across two days. The owner has decided to reset Windows and reinstall the desktop application after preserving project data. The reset has not happened yet, and there is no evidence that Dots damaged Windows or that reinstalling Windows will fix these product/session failures.
Please investigate the MXC known-folder failure in the actual CUA launcher context, clarify native capability availability on the connected computer, and provide a supported Desktop update/recovery path. The official updater found no eligible update when checked.
This report omits personal paths, usernames, machine/project names, chat/session IDs, credentials, source code, screenshots, and raw transcripts/logs.