Repository navigation
Windows Dots: CUA MXC launcher fails with HRESULT 0x80070003 after direct shell recovery #52407
Description
Environment
- Windows x64, DisplayVersion
25H2, build26200.9457(read from the current Windows version registry). - Installed Desktop package:
26.1002.7124.0; updater-reported app version:26.1002.52244. - Bundled Codex core:
0.162.0-alpha.2; Unified Computer Use plugin:26.1002.52244. - A dot connected to a Windows computer, coordinating existing project chats.
- Before recovery:
windows.sandbox = "elevated". The only successful shell-recovery change was addingfeatures.prefer_mxc = true, leaving elevated as the fallback. - Observed October 8–9, 2026; times below are UTC+07.
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:
node_repl kernel exited unexpectedly
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
kernel_status: exited(code=1)
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
- Use the existing dot/Windows execution task after the sandbox preference change above.
- Execute one read-only command to read the computer name and current directory: succeeds.
- Make the initial supported CUA entry call
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:
exec-server rejected request (-32603): helper_unknown_error: setup refresh had errors
Associated refresh diagnostics showed Windows OS error 32 while opening node_repl.exe for 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 SHGetKnownFolderPath for 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:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
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.
Activity
evanziwen commentedon Oct 9, 2026
I am seeing the same CUA startup error on another Windows installation:
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.
Stage4000 commentedon Oct 9, 2026
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.
Jollendi91 commentedon Oct 9, 2026
I can reproduce this with both the Chrome extension and the in-app browser on Windows 11 x64 (DisplayVersion 26H2, build 26300.9457).
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 0x80070003
The 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?
BladexZN commentedon Oct 9, 2026
CUA/MXC launcher:
cannot locate required Windows platform directory: HRESULT 0x80070003. Possible cause: missingSystemDrivein the launcher environmentRelated: #52407, #52569
Environment
codex-cli 0.162.0-alpha.17.2app-serverandexec-serverwith-c features.prefer_mxc=true; the user config has[windows] sandbox = "elevated"cfb32733c877621e; plugin browser 26.1007.21434Reproduction
await cua.getState();MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003, before any page loads.Findings (verified locally)
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.SHGetKnownFolderPath:SystemRoot, windir, ProgramData, ALLUSERSPROFILEset → ProgramData still 0x80070003SystemDrive=C:set → everything S_OKSystemDrive=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: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).-c features.prefer_mxc=true(the flag the app passes), commands fall back to the elevated sandbox and run asCodexSandboxOfflinewithSystemDrive=C:.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
cua.getState().--__codex-windows-mxcon the CUA path.BladexZN commentedon Oct 9, 2026
Update to my previous comment: the
allow_mxc = falseworkaround did not hold.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.%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.youngtaekpyo-wq commentedon Oct 10, 2026
I can reproduce this on Windows 11 26H2, including after updating from build 26300.9457 to 26300.9550.
Environment:
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_eof
The first attempt sometimes reports:
trusted Node process exited unexpectedly; kernel reset, rerun your request
The 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.
moruku36 commentedon Oct 10, 2026
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?
alleng666-cmd commentedon Oct 10, 2026
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):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.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.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%\ProgramDataRemove-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.72 remaining items
RajNath commentedon Oct 14, 2026
We tried again today with a different website, CVS.com, and hit the same browser-control startup error, HRESULT 0x80070003, before we could verify sign-in. The error remains consistently reproducible on my Windows PC.
Environment verified October 14:
Browser-control startup twice failed with "MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003", followed by kernel exit code 1.
Desktop app version, browser-control kernel Node/MXC version, browser version, and active model were not exposed or could not be verified. The CLI and primary-runtime versions should not be mistaken for those unknown components.
AI-Butterfly/dot on behalf of Raj
meca121314-glitch commentedon Oct 14, 2026
Read-only diagnostic findings related to #52407, checked on October 14, 2026.
Previously reported failure — not reproduced during these checks:
Confirmed during inspection:
26200.9550.cua-repl.mjs → node_repl.exeprocess chains were running; no MXC launcher was running at inspection time.@oai/cua-replversion0.1.0. Its entry-point file has no community bootstrap patch. This does not establish which file/version the failed instance loaded.Win32_Processmetadata and startup records did not provide the required environment or actual working-directory snapshots.Still unknown:
SystemDrive,LOCALAPPDATA, and working directory at process creation and failure.Shell environment values and command-line arguments were not used to infer these unknowns. We have not established that the cause proposed in #52407 applies to this machine.
Could maintainers provide an officially supported, read-only diagnostic method to capture these fields and correlate them with the failing PID/parent PID, without collecting credentials or full environment/memory dumps?
XQ is running a simulation and must not be interrupted. No computer, ChatGPT/Codex, or XQ restart, runtime modification, or configuration/security/sandbox change is permitted at this stage. Any necessary change requires prior user approval, with its impact and rollback procedure explained.
circleosaka2022-ship-it commentedon Oct 14, 2026
Another confirmed recovery with @jkotieno's
cua-repl.mjsbootstrap workaround (#52407 (comment)), plus process-level evidence of whereSystemDriveis lost.Environment: Windows 11 Home x64, build 26200. Desktop package
OpenAI.Codex26.1007.9446.0, reinstalled on Oct 14. The bundled CLI is still0.162.0-alpha.17.2, and itscodex.exestill contains the same launcher error string. Unified Computer Use 26.1007.21434,@oai/cua-repl0.1.0.Before the workaround
codex.exe exec-server --remote(63 vars, hasSystemDrive) →node … @oai/cua-repl/bin/cua-repl.mjs(24 vars, noSystemDrive/LOCALAPPDATA) →node_repl.exe→ MXC launcher →HRESULT 0x80070003.Path, PATHEXT, SHELL, SystemRoot, TEMP, TMP, plus theenv/env_varsfrom the unified-computer-use.mcp.json. That file'senv_varsis only["CODEX_WINDOWS_REGISTERED_CORE"].codex sandbox --enable prefer_mxc -- cmd /c echo oksucceeds with the full environment, and fails with exactly this error when onlySystemDriveis removed.env_varsin.mcp.json. The MXC error disappeared, but the next failure wastrusted Node process exited unexpectedly; kernel reset. That matches the plugin-cachechdirEPERM described in Windows Dots: CUA MXC launcher fails with HRESULT 0x80070003 after direct shell recovery #52407 (comment). The.mcp.jsonchange also does not survive app restarts.After the workaround (Oct 14): I applied only the bootstrap block, unchanged, to
cua_node/<id>/bin/node_modules/@oai/cua-repl/bin/cua-repl.mjsand fully restarted the app. The dot/remotecua.getState()then succeeded on the first call (Chrome 3 tabs, Edge 6 tabs). No registry, ACL, sandbox-policy or persistent environment change was made.+1 to the requested product fix: preserve the standard Windows environment (at least
SystemDriveandLOCALAPPDATA) when exec-server spawns MCP servers, align the trusted worker's cwd with its sandbox grants, and include the failing FOLDERID in the launcher error.Feedback ID: 01a124db-fb4f-7f61-90fa-6e4fd9380357. Note that this earlier feedback incorrectly attributes the fix to a
config.tomlchange. That change turned out to be unrelated.davelagueux commentedon Oct 14, 2026
Follow-up on October 14, 2026: I installed an update, then retried browser control from my dot in a fresh session around 16:12 UTC. My Windows PC was connected and authorized, and browser tools were available, but listing tabs still failed before any tabs could be read:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
The installed app version was not verified in this test. No browser changes were made.
Is there a specific supported diagnostic you need for this failing launch path?
4mhfhwtmd6-coder commentedon Oct 14, 2026
Additional reproduction on October 14, 2026, on Windows x64.
A dot-created browser-control task failed during initialization, before returning any tabs or page content, despite the computer being connected and authorized.
The initial error was:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
Later attempts also reported that the trusted Node process exited and the kernel reset.
Resetting the tool and retrying did not restore access. The problem also reproduced after a computer restart on October 14.
The owner reports that a regular local Codex chat worked on the same computer. That comparison has not been independently retested for this report.
Could maintainers provide a supported fix or diagnostic procedure for browser-control initialization in dot-created Windows tasks? The failing launcher's missing directory and root cause remain unverified.
thisnameissoclever commentedon Oct 14, 2026
I can reproduce the same launcher error after updating the Windows desktop app on October 14, 2026, around 18:09 UTC. The installed app version was not captured.
At 18:13 UTC, a fresh dot-delegated local task exposed the supported mcp__cua_repl.js tool. With the computer connected and the browser already open, the read-only cua.getState() call failed during initialization:
Both attempts failed before browser inventory or page content could be read. A pre-update test at 17:57 UTC produced the same MXC launcher error. The update did not resolve this reproduction. No launcher, configuration, or security patches were applied.
Could you provide a supported recovery path or fix for this launch failure?
camilorestrepoc-afk commentedon Oct 14, 2026
Additional reproduction: Windows visual-control initialization fails with HRESULT 0x80070003
The same launcher error persists on my connected and authorized Windows PC. Ordinary commands work, but visual control fails before returning window or tab information or screenshots.
Error:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
Environment:
Reproduction:
Troubleshooting completed:
The bundled CLI's --version and sandbox --help commands both exit with code 0. They also emit access-denied warnings (OS error 5) during temporary-file cleanup and PATH-alias creation. Whether these warnings relate to the visual-control failure is unknown. The separate MXC_OK execution probe has not been run.
Expected behavior:
Visual control should initialize and return the available state. If initialization fails, please identify the missing Windows platform directory and provide a supported diagnostic or recovery procedure that preserves security protections.
The root cause on this PC remains unconfirmed. No personal paths, raw logs, screenshots, account details, or feedback IDs are included.
kirakimo2000-dot commentedon Oct 15, 2026
Still reproducing in a dot-created task on a connected, authorized Windows desktop as of October 15, 2026 (UTC).
Verified local versions:
The initial failure is:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003After a kernel reset, two read-only
cua.getState()attempts failed before returning browser state withtrusted Node process exited unexpectedly. No tab inventory was returned and no about:blank test tab could be created.Read-only checks found that the currently referenced node.exe, cua-repl.mjs, node_repl.exe and codex.exe all exist. The ordinary shell has valid SystemDrive, SYSTEMROOT/WINDIR, ProgramData, LOCALAPPDATA and TEMP/TMP paths. This does not establish what the failing child actually receives. The inspected startup configuration lists CODEX_WINDOWS_REGISTERED_CORE for forwarding and as NODE_REPL_UNTRUSTED_ENV_ALLOWLIST; we have not confirmed the failing child's actual environment.
The Store update check reports no available upgrade.
codex updatecannot update this Store installation. No binary replacement, bootstrap patch, sandbox/ACL/registry change or environment-filter change has been applied.We see that #54027 and #54069 have merged and are included as cherry-picks in CLI 0.163.0-alpha.10.1. Is there a supported desktop/Store build or rollout that includes the necessary fixes for the dot-to-Windows remote MCP path? Does the coordinator-side change also require a service rollout? If this desktop build cannot yet receive the fix, is there a supported diagnostic or recovery procedure that preserves the sandbox and environment filtering?
Happy to provide narrowly scoped, redacted diagnostics if you specify what is needed.
gallipro commentedon Oct 15, 2026
Windows delegated browser control fails before returning any tabs. App About: 26.1007.71326; Windows package: 26.1007.9446.0; bundled CLI: 0.162.0-alpha.17.2; Windows build: 26300.9457; CUA bundle: 26.1007.71326.
The initial cua.getState() failed with HRESULT 0x80070003. An unofficial SystemDrive-only bootstrap patch changed the observed failure to CreateProcessInSandbox error 203. A temporary LOCALAPPDATA forwarding entry then produced EPERM while node_repl tried to switch from the task workspace into the plugin-cache directory.
The LOCALAPPDATA change was rolled back and verified. The SystemDrive patch remains installed, so this is not an unmodified baseline. No sandbox protections, ACLs or global environment settings were changed. Direct local tasks worked earlier, but have not been freshly retested.
Please investigate Windows environment propagation and worker working-directory handling, and provide a supported repair without expanding filesystem permissions. Related report: #52407
xxalanstewart25xx-art commentedon Oct 15, 2026
Additional reproduction after official app reinstall, tested October 15, 2026 around 02:03 UTC.
Environment verified on this PC:
The PC is connected and authorized. Ordinary shell/file operations work. In a dot-delegated task, fresh supported CUA initialization fails before tab listing or screen capture:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003Kernel exits with code 1, reason
stdout_eof. Resetting the CUA session did not resolve it. Windows update/restart, app Repair, and uninstall/reinstall using the official ChatGPT Windows installer have not resolved this reproduction.Read-only inspection found the declared runtime entry files present and the inspected cached/installed CLI and CUA manifest hashes matching. This does not establish the failing launcher's actual environment or identify which known-folder call fails. No unofficial bootstrap patch, sandbox downgrade, registry/ACL change, or runtime substitution was applied during this investigation. Event-log reads were denied, so we cannot claim those logs are clear or that Windows health is verified.
We found the related merged changes #54027 and #54069. Is there a supported desktop/Store build or coordinator rollout containing the necessary fixes for this launch path? If not yet available, could maintainers provide a narrowly scoped diagnostic identifying the failed known-folder ID and relevant startup environment in the actual MXC child context?
A direct ordinary-local-chat versus delegated-task comparison has not been verified on this PC. This report excludes personal paths, private files, screenshots, raw logs and support identifiers.
Update, October 15, 2026: native Process Monitor verification
A ten-second Process Monitor capture around 04:52 UTC (October 14, 21:52 PDT), exported through Process Monitor's own CSV exporter successfully (exit code 0), confirms this event from the failing codex.exe process (PID 25524):
<workspace>\%SystemDrive%\ProgramDataThe
%SystemDrive%token is literally present and unexpanded in the attempted path. The CUA startup process overlaps the capture by approximately 9.43 seconds; the runtime exits with code 1 andstdout_eof. This is direct evidence of an unexpanded path during the failing startup. Its causal connection to the original MXC HRESULT 0x80070003 remains an inference; this capture does not establish the complete root cause.The original trace is preserved privately and has not been uploaded. Do the known environment-expansion fixes cover this exact evidence, and which shipped Windows desktop version includes the necessary fixes for this launch path?
nm-birdiesandbogies-333 commentedon Oct 15, 2026
Additional reproduction on Windows desktop package 26.1007.9446.0, with bundled Codex 0.162.0-alpha.17.2 and CUA 0.0.30.
In a cloud-delegated task targeting my connected Windows computer, browser initialization fails before returning any tabs:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
A controlled, read-only probe used SHGetKnownFolderPath with flags 0 and the current token, varying only the environment supplied to the test process:
This reproduces the known-folder failure under a controlled condition. We could not observe the actual failing CUA child’s environment, so missing SystemDrive remains a hypothesis for this machine, not a confirmed root cause.
PRs #54069 and #54027 appear relevant. Is there a supported desktop/coordinator rollout containing the necessary fixes, or a supported managed-plugin environment remedy for this delegated launch path?
Feedback ID: 01a11882-3ea2-743c-8b92-312dfec7d03f
Personal paths and raw logs are excluded.
circleosaka2022-ship-it commentedon Oct 15, 2026
Technical notes and a minimal diff for the existing community workaround are available here:
https://github.com/circleosaka2022-ship-it/codex-windows-browser-workaround
The workaround was applied on Windows 11 with assistance from Claude. The original approach is jkotieno's bootstrap workaround; this write-up is an unofficial temporary workaround, not a new OpenAI fix or a claim of universal success.
The English/Japanese notes explain the process-local Windows environment defaults, the conditional plugin-cache working-directory change, limitations, rollback, and the possibility of app/runtime updates overwriting the addition. No ACL, registry, browser-permission, or sandbox-policy change is required; MXC remains enabled. No new end-to-end recovery test is claimed by this publication.
The notes distinguish the patch's code behavior, other contributors' diagnostic reports, and hypotheses about an unobserved failing CUA child environment. They do not assert that missing
SystemDriveis a confirmed cause without observing that child, or that removingLocalAppDataalone explains the known-folder error; see the controlled-probe report and its stated limits.#54027 and #54069 have merged. A source merge or CLI release is separate from Desktop/Store rollout and does not by itself establish Desktop inclusion or resolution of the separate working-directory problem.
ian-adams commentedon Oct 15, 2026
Following up on my earlier report: #52407 (comment)
Still reproducible on October 15, 2026. A fresh dot-created task on the same connected, authorized Windows PC was tested at approximately 11:43 UTC. It exposed
mcp__cua_repl.js, butawait cua.getState();initially returned:trusted Node process exited unexpectedly; kernel reset, rerun your requestThe retry returned:
No browser inventory, tab object, page content, accessibility tree, or screenshot was returned. Selecting the existing Chrome tab through
cua.getTab(...)also failed during trusted-Node startup.The useful same-machine comparison still holds today: the Codex/ChatGPT Chrome side panel successfully accessed an existing Outlook tab through
chrome_extension.getTabContext, accessibility inspection, and a live screenshot. That successful side-panel result is my report from that session; it was not obtained inside the failing dot-created task. Local file/Excel work also remains usable. Previous app/browser restarts and fresh tasks have not resolved the delegated-browser failure.My earlier report listed Windows app package
26.1007.2314.0; the current installed version was not rechecked in today's diagnostic, so that should not be treated as today's version.I see that #54027 and #54069 merged on October 14 and are included as cherry-picks in CLI
0.163.0-alpha.10.1. Could maintainers confirm whether they address this dot-to-Windows launch path, which supported desktop/runtime or coordinator release delivers them, and how to verify the corrected runtime is actually in use? If this is a different launcher-path or runtime-packaging issue, what narrowly scoped, sanitized diagnostic would help identify the failing directory in the actual child process?The failing child's environment and exact missing directory remain unverified. Prepared with AI assistance; private page contents, personal paths, machine identifiers, and session IDs are omitted.
DSP2012 commentedon Oct 15, 2026
I’m also affected on Windows 11. Browser control worked on October 14, 2026, then stopped later that day. Restarting both the app and PC hasn’t resolved it.
On October 15, two read-only initialization attempts using await cua.getState(); failed before returning any browser tabs with:
trusted Node process exited unexpectedly; kernel reset, rerun your request
An earlier October 14 attempt reported:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
The computer is connected, and the cloud browser works as a fallback. I haven’t verified the underlying cause or whether the related merged fixes are included in my installed app. Could maintainers confirm the supported Windows desktop rollout or diagnostic needed for this launch path?
BuhtigNotes13 commentedon Oct 16, 2026
Follow-up to my earlier reproduction: #52407 (comment)
After a user-reported Windows desktop app update and reboot on October 16, 2026, delegated browser/computer-use initialization still failed:
trusted Node process exited unexpectedly; kernel reset, rerun your requestMXC requires nonempty Unicode host SystemDriveNeither attempt returned browser tabs or page content. Ordinary shell and task-workspace access remain available.
An installed-app screenshot before the reported update/reboot showed version
26.1013.3656.0; the build actually running during these failures has not been independently verified. The new SystemDrive message is the observed result of this test; I am not claiming the earlier HRESULT was reproduced or that the underlying cause is proven.No unofficial patches or security-setting changes were applied for this test. Could maintainers identify the supported Windows desktop build containing the fix for this delegated launch path, explain how to verify the corrected runtime is loaded, and provide supported remediation or a narrowly scoped diagnostic for
MXC requires nonempty Unicode host SystemDrive?Prepared with AI assistance. Personal paths, device/account identifiers, screenshots and raw logs are omitted.