Repository navigation
[Windows] Browser tools fail to initialize: MXC launcher HRESULT 0x80070003 #53188
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Powered by Codex & OWL Versión 26.1007.21434 Publicada el 08-10-2026
What subscription do you have?
Plan Pro 5X
What platform is your computer?
Windows 11 Pro, build 26300, x64. Windows display language: Spanish.
What issue are you seeing?
The browser-control tools in Codex fail during initialization, preventing the agent from inspecting browser tabs or testing my local web application.
The latest error is:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
The process exits with code 1 when the agent invokes cua.getState(). Other attempts returned:
trusted Node process exited unexpectedly; kernel reset, rerun your request
The same initialization error occurred when testing Google Chrome and the Codex integrated browser separately. No browser state or tab handle was returned.
The desktop connection itself is available. The Chrome extension is installed and enabled, and the native-host registry entry and manifest were verified. The exact cause of the runtime failure is still unknown.
What steps can reproduce the bug?
On the affected Windows installation:
- Open the Codex desktop app and connect the computer to the task.
- Open Google Chrome with the ChatGPT browser extension enabled.
- Ask the agent to inspect the available browser tabs using its supported browser tools.
- The agent invokes cua.getState(), but initialization fails with HRESULT 0x80070003 before returning browser state.
The failure also occurred when requesting an integrated-browser tab using cua.createBrowserTab("iab", "http://127.0.0.1:8088/", { visible: true }).
This is reproducible on my machine. I have not confirmed reproduction on another computer or a clean Windows installation. No application login is reached.
What is the expected behavior?
The browser-control runtime should initialize and return the available browser state. The agent should then be able to access an authorized Chrome tab or open a tab in the integrated browser.
If a required Windows component or directory is missing, the error should identify it and provide an actionable recovery procedure.
Additional information
Installed versions reported by local diagnostics:
- Codex MSIX package: 26.1007.2314.0
- Bundled Codex CLI: 0.162.0-alpha.17.2
- Browser / Computer Use / CUA components: 26.1007.21434
Troubleshooting already performed: - Restarted Chrome.
- Restarted Codex.
- Restarted the entire PC.
- Reinstalled Codex dependencies.
- Checked for Codex updates; none were available.
- Tested Chrome and the integrated browser separately.
A diagnostic initially reported a missing native-host registration, but this was a false negative: it looked for “(Default)” while Spanish Windows returned “(Predeterminado)”. The registry entry and manifest were subsequently verified. The isolated execution environment also uses a different LOCALAPPDATA path.
An older task referenced component version 26.1002.52244, while installed manifests referenced 26.1007.21434. A newer task exposes CUA but fails during initialization. It is not established whether these observations share a root cause.
Earlier browser testing worked through a separate direct-debugging script. That was a different access method, so it does not establish that the currently failing integrated runtime previously worked.
I would appreciate a supported recovery procedure that preserves projects, browser profiles and application settings.
Activity
github-actions commentedon Oct 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
TheIgnacioLok commentedon Oct 11, 2026
Comparison on the same PC: a new chat opened manually in Codex successfully used mcp__cua_repl.js with cua.createBrowserTab in the integrated browser to open https://example.com/ and read ‘Example Domain’. No configuration changes were made. Dot-delegated tasks failed with MXC launcher HRESULT 0x80070003. This suggests an execution-context difference, rather than a general browser installation failure.
dlbuilds1-afk commentedon Oct 11, 2026
We’ve reached a specific diagnosis, but the available controls don’t expose a supported repair. Please add this to your existing feedback:
“Procmon captured failed codex.exe PID 24152 on October 11 at 18:10:25 Eastern. It attempted C:\Projects\Codex\2026-10-11\task%SystemDrive%\ProgramData and received PATH NOT FOUND. The process environment lacked SystemDrive; normal Windows and shell known-folder tests succeeded. Please investigate retaining SystemDrive in the filtered MXC launcher environment before resolving ProgramData. App version 26.1007.2314.0.”
No need to send the full trace initially. Keep Process Monitor capture stopped. We shouldn’t change your global Windows variables or weaken the sandbox to work around an app launch defect.
KodeKicker commentedon Oct 12, 2026
We have exactly the same issue and have been waiting for a WEEK for Openai support to offer a solution. Instead, they keep asking for more and more information even though we've supplied it already.
as57430505-blip commentedon Oct 12, 2026
Windows에서 동일한 CUA 초기화 오류가 발생해 추가로 보고합니다.
확인한 도구 버전:
최초 오류:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
지원되는 세션 초기화(js_reset) 후 재시도 오류:
trusted Node process exited unexpectedly
브라우저 상태나 탭 정보를 읽기 전에 실패합니다. 현재 환경에서 근본 원인과 지원되는 복구 방법은 확인하지 못했습니다. 이 오류에 적용할 수 있는 공식 복구 절차나 수정 버전을 안내해 주시면 감사하겠습니다.
dcyk-friday commentedon Oct 12, 2026
I am also seeing this initialization error on Windows.
Is there a supported recovery procedure for this configuration? I have not applied sandbox-setting workarounds.
dcyk-friday commentedon Oct 12, 2026
Additional comparison from the same PC, without changing security settings:
A new local chat opened directly in the desktop app via Codex → This computer reported successful standard Computer Use: it launched Windows Calculator, clicked the on-screen buttons for 123 × 45, and confirmed 5,535. This is based on that local chat's completion report; the tool trace has not been independently reviewed here.
However, a task delegated to the connected Windows PC from the dot conversation still cannot use the same native-control path. The required native computer-control tool is not available to that delegated task, and the provided interface reports: 'Native computer APIs are disabled.' The latest check stopped there, without repeating the earlier MXC failure or attempting an alternative control implementation.
Thus direct local Codex and the dot-delegated task have different available control tools. Is there a supported way for dot-delegated tasks to use the same standard Computer Use capability as a directly opened local Codex chat?
gomarketing1 commentedon Oct 12, 2026
Additional controlled reproduction and source-level analysis from 2026-10-12.
Environment and observed failure
Normal host known-folder resolution and a standalone MXC probe pass on the same installation.
Controlled local reproduction
Using the installed CLI and the same standalone MXC probe, changing only the process-scoped environment:
SystemDrive: the probe reproduces the exact platform-directory error above and exits 1.SystemDrive=C:: the probe printsMXC_OKand exits 0.A separate known-folder probe isolates
ProgramData: withoutSystemDrive, resolution fails with%SystemDrive%\ProgramDataleft unexpanded, while Program Files and Program Files (x86) still resolve.These were temporary diagnostic changes, with the environment restored afterward. No persistent configuration or sandbox-security changes were made.
Candidate environment-filtering path
The following source references are pinned to commit
740e5af33c71225640e0c1c1555c514c2c93ab74; this is source analysis, not proof of the deployed cloud controller's exact implementation.SHGetKnownFolderPathfor Program Files, Program Files (x86), and ProgramData beforenative::launch. Any failed query produces the observed generic directory error.include_onlyallowlist when explicit remote environment names are present. It combines controller-sideDEFAULT_ENV_VARS,SYSTEMROOT,TEMP,TMP, and the explicit names.SystemDriveandLOCALAPPDATA.cua_repl.env_varslist contains onlyCODEX_WINDOWS_REGISTERED_CORE, with no explicitSystemDriveorLOCALAPPDATAentry.#50129 already addresses the Unix-controller/Windows-executor filtering mismatch, but adds only
SYSTEMROOT,TEMP, andTMP. #47108 documents MXC's need forSystemDriveandLOCALAPPDATAand fixes the separate filesystem-helper filter.Verification limit and proposed regression coverage
The actual environment of the failed delegated browser process was not observable in this investigation. The effective cloud-side plugin transformation was also not observable. Missing
SystemDriveis therefore a strong candidate explanation supported by the controlled reproduction, not a confirmed root cause of this delegated launch.Please check whether the remote MCP launch path preserves the Windows startup variables needed by MXC, without broadly inheriting secrets or weakening sandbox policy. A useful regression would exercise a Unix controller, Windows executor, and nonempty plugin
env_vars, then validate actual MXC ProgramData resolution and launch rather than only the constructed allowlist. Reporting the particular known-folder query that failed would also make this error more actionable.Expected behavior: the delegated browser runtime initializes successfully and returns browser state on an installation where the standalone MXC and host known-folder probes succeed. This report concerns the MXC directory-resolution error; a separate request-header-policy error should be tracked independently.
dansesmacabres commentedon Oct 12, 2026
Additional Windows same-machine comparison, 2026-10-12 around 18:33–18:40 UTC:
A fresh dot-delegated desktop task still fails at the supported
mcp__cua_repl.jscallawait cua.getState()withMXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003, before provider enumeration. A runtime reset and retry reproduced it. On the same connected computer, an existing local Codex work chat successfully uses Edge extension provider 4 for page reads and clicks. A full Windows restart and fresh task had already failed to resolve the delegated-runtime problem earlier.Current evidence:
Crucially, neither the shell probe nor configuration inspection captures the actual short-lived failing launcher environment. The SystemDrive/ProgramData filtering mechanism discussed above is a useful hypothesis, not a confirmed diagnosis on this machine. No global environment, registry, plugin, sandbox or security settings were changed.
Could engineering confirm the supported repair/build and inspect the actual delegated launch environment and failing Known Folder query? Please distinguish the local working browser context from the failing delegated context. Private paths, usernames, task/account IDs, environment values and logs are omitted. Direct existing-thread routing also fails independently under #52873; no common cause is claimed.
Update, 2026-10-12 at approximately 18:51 UTC: in-app feedback submission is now confirmed. Feedback ID:
01a118b6-32a4-74ac-bbad-a30e5ca9c0cc. Please use this reference to correlate the report internally. No private screenshot or conversation transcript is attached to this public comment.20 remaining items
JimmyGent-Ops commentedon Oct 14, 2026
Same failure here, with local evidence for the missing-
SystemDrivecause.Versions: Windows 11 Pro 26H2 build 26300.9711 (also failed on 26300.9457) · Codex MSIX 26.1007.9446.0 (also failed on 26.1007.2314.0) · unified-computer-use 26.1007.71326 · cua-node 0.0.30 / Node 24.21.0-cua.1 ·
[windows] sandbox = "unelevated"Scope: Computer control works in a task I start locally in the desktop app. It always fails when Dot starts the task or tries computer control. The first
cua.getState()returnsMXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003. Runtime reset, app restart and Windows/app updates don't change it.Findings (read-only):
codex.exeare three KNOWNFOLDERIDs: ProgramFiles, ProgramFilesX86 and ProgramData. All three resolve normally in a regular user process.SystemDrivefrom a child process's environment makesSHGetKnownFolderPath(FOLDERID_ProgramData)return 0x80070003, because the registry value is%SystemDrive%\ProgramData. Adding it back fixes it. ProgramFiles and ProgramFilesX86 are unaffected.logs_2.sqliteon this PC hascodex_config::loader WARN Failed to resolve ProgramData known folder; using default path error=SHGetKnownFolderPath(FOLDERID_ProgramData) failed with HRESULT 0x80070003. The config loader recovers from this; the MXC launcher treats it as fatal.plugins/cache/openai-bundled/unified-computer-use/26.1007.71326/.mcp.jsonsets"env_vars": ["CODEX_WINDOWS_REGISTERED_CORE"], and itsenvblock has noSystemDriveorLOCALAPPDATA. That matches theremote_env_policy()allowlist analysis above.In-app feedback (with diagnostic logs) submitted: Feedback ID
01a11839-5c02-72a7-a725-b7de4c1ca01c.Ask: preserve
SystemDrive,SystemRoot,windir,LOCALAPPDATA,ProgramDataandALLUSERSPROFILEwhen starting cua_repl / the MXC launcher for Dot-delegated tasks, and include the failing KNOWNFOLDERID in the error message.brookehoward2008-droid commentedon Oct 15, 2026
Upstream fix merged; released-tag distinction and remaining delegated verification
Updating my earlier comments: an upstream remote-MCP change now explicitly preserves
SYSTEMDRIVEandLOCALAPPDATA.0fd85b075288c4fee50f0df3e4e4f98f80c693fe. It extends the remote allowlist and handles Windows environment overrides case-insensitively.81aee8c86ba2549e53f82ea56f163c3e450fb55a. This is a related launcher change; its merge alone does not establish recovery of this issue.I checked the tagged source, rather than inferring inclusion from version numbers:
rust-v0.163.0-alpha.10.1:remote_env_policy()containsSYSTEMROOT, TEMP, TMP, SYSTEMDRIVE, LOCALAPPDATA.rust-v0.163.0-alpha.11: the corresponding list still contains onlySYSTEMROOT, TEMP, TMP.The alpha.10.1 release was published later than alpha.11, so the numerically higher suffix should not be used as evidence that this fix is included. This tagged-source check does not establish which version the desktop app or delegated controller is running.
Current-session verification on my Windows computer succeeded through the supported CUA tools:
await cua.getState()returned browser inventory, andcua.createBrowserTabopenedhttps://example.com/in the integrated browser and returned its title and page content. No fresh Dot-delegated task was tested in this verification, and no causal link between this success and the upstream changes has been established. No launcher, global environment, or sandbox settings were changed during this verification.Could maintainers identify the desktop/controller rollout containing these fixes and validate a fresh Dot-delegated Windows task through CUA initialization, MCP tool execution, and a page read? Please retain the earlier correction that my affected task was Dot-delegated with
host=local; that label alone does not identify the controller or filtering path.brookehoward2008-droid commentedon Oct 15, 2026
Fresh Windows task comparison passed; exact Dot launch path remains unverified
Follow-up to my upstream-fix update above. On October 14, 2026 (America/Los_Angeles), I tested browser control in a newly created task on the connected Windows computer.
Creation route: the task was created from an existing local Codex chat through the desktop app's
create_threadAPI, withhost=local. It was not created through the original Dot UI/controller path.Results:
OpenAI.Codexpackage26.1007.9446.0.await cua.getState();. It completed successfully in about 0.76 seconds; the task reported five browser entries.https://example.com/and reported the actual titleExample Domainand visible documentation-example text.I inspected the new task's execution trace, which records the initial CUA call, supported browser-tab creation and closure, and successful Windows/package inspection. Browser count and page content were reported by the test task; the thread readback did not expose the raw MCP response bodies.
This is a successful fresh desktop API-created task comparison, not proof that the original Dot-delegated launch path is fixed. A
host=locallabel alone does not identify the controller/environment-filter path. The exact Dot launch path remains unverified, and this test does not establish that the success was caused by the newly merged upstream changes.The remaining verification is a new task initiated through Dot itself on the connected Windows computer, with creation provenance retained, followed by successful CUA initialization, MCP tool execution, and an actual browser page read. Please identify the desktop/controller rollout containing the relevant fixes so that result can be correlated with deployed components.
brookehoward2008-droid commentedon Oct 15, 2026
Dot browser verification blocked by desktop-to-task dispatch failure; cross-reference #51049
The planned extension-browser page-read test has not run. Attempting to send the authorized follow-up from a local desktop Codex chat to the existing Dot-created task failed before a new turn started:
Readback showed that the target remained idle with its earlier completed turn; no new test turn was recorded. The earlier delegated attempt initialized CUA and reported extension browsers, but could not use
iaband did not read a page. Neither that inventory result nor the separately successful desktop-created comparison establishes recovery of the original Dot launch path.Related dispatch report: #51049 — Desktop follow-up to dot-created task fails: AbsolutePathBuf and mixed cloud/Windows cwd. Read-only inspection here found a matching mixed cloud/Windows working-directory shape in the task record and similar direct-follow-up failures in desktop logs. The full rejected request payload was not captured, so the exact failing path field and root cause remain unconfirmed. This dispatch failure is distinct from the original CUA/MXC
0x80070003error; a shared cause has not been established.Installed Windows package:
26.1007.9446.0. The configured updater reported app version26.1007.71326, build20398, production channel,up_to_date. These are separate version identifiers; the update result is not proof that a particular controller-side fix has deployed.No task metadata, installed binaries, plugins, global environment variables or sandbox settings were changed. No application restart, replacement task or browser retry was performed during the dispatch investigation, and no raw logs or private task paths are attached.
The Dot extension-browser page-read test and the original Windows MXC launch path remain UNVERIFIED. Please correlate this dispatch symptom with #51049, identify a supported continuation path or fixed desktop/controller build, and validate a task initiated through Dot through CUA initialization and an actual extension-browser page read.
brookehoward2008-droid commentedon Oct 15, 2026
Original Dot conversation: delegated extension-browser test completed successfully
On October 14, 2026 (Pacific), the browser-control request was sent through my original Dot conversation, rather than dispatched to a replacement task from a desktop chat. Dot created task
01a13dbf-e4a3-7015-a966-83851ce3a039.The task's recorded delegation identifies source thread
01a129c6-4ba0-768c-b8b0-2af9e2bd0034. Its completed execution record was read back and includes successful CUA initialization, tab creation, rendered-text read, and tab closure.Actual results
await cua.getState();, run once.5540255, athttps://example.com/.Dot initially displayed an interim disconnection notice, but the delegated task subsequently completed successfully. The result above comes from its completed record, not the interim notice.
Verification boundary: this establishes a successful extension-browser page read through the original Dot conversation's delegation route in this test. It does not establish which upstream fix is deployed, prove that PR #54027 or #54069 caused the success, independently establish the task's execution platform, or show that the native Windows MXC path was exercised. It does not verify integrated-browser or native desktop capabilities or long-term reliability.
Please retain my corrected original failure context: Dot-delegated on the installed Windows desktop app with
host=local. The new task's routing metadata is separate from that incident context.No software installation, application restart, runtime reset, file edit, environment injection, configuration/model change, or sandbox/permission change was performed during the test. Please identify the relevant production desktop/controller rollout so this successful result can be correlated with deployed components; it should not alone be treated as proof that a particular source fix is deployed.
brookehoward2008-droid commentedon Oct 15, 2026
Local/upstream comparison and attribution limit: modified launcher predates successful Dot test
Read-only inspection found a locally modified CUA JavaScript launcher configured by the installed Computer Use plugin. It restores missing SYSTEMDRIVE and LOCALAPPDATA before dynamically importing CUA, and changes to the temporary directory when startup occurs inside the plugin cache. Its file timestamp is October 14, 2026, 6:54 p.m. Pacific, before the successful Dot extension-browser test around 9:10 p.m. Saved earlier launcher versions confirm these modifications.
Important qualification to my successful-test report: task
01a13dbf-e4a3-7015-a966-83851ce3a039did initialize CUA, read Example Domain through Chrome, and close its temporary tab. However, that run occurred while this local workaround was configured. Its execution record does not expose the actual launcher file loaded or the deployed controller revision. We cannot attribute success to #54027/#54069, to the workaround alone, or prove that native Windows MXC was exercised. No workaround was added during that test or this inspection.Comparison:
3e377e5ae58c9f6712dd7040e9e8fb41d3be0488adds SYSTEMDRIVE and LOCALAPPDATA to the remote allowlist and has three passing targeted policy tests.Separate WSL dispatch diagnostic: nine tests passed
The uncommitted app-server work investigates the distinct
AbsolutePathBuf deserialized without a base pathdesktop-to-task dispatch failure. It identifies only schema-defined root-list fields and indices, without exposing path values, prompts, thread IDs, or arbitrary user-controlled keys. Normal decoding remains authoritative; it does not rewrite paths, relax validation, alter permissions, or repair MXC launching.Freshly run in Ubuntu:
The tests cover workspace/sandbox root indices, foreign paths, redaction, successful native roots, unrelated errors, and ignored arbitrary keys. These are Linux tests, not Windows integration validation. Both local source diffs also pass git diff --check. All existing work was preserved.
What remains: identify the official controller and Windows executor revisions serving the Dot launch path, establish fix inclusion from build provenance, and validate the original route against a supported official runtime without the local workaround confounding attribution. We have not removed/restored the workaround, updated binaries, or changed security settings.
Retain the original incident correction: Dot-delegated with
host=local; routing metadata does not establish the controller path.Authorship checked: my local WSL commit records Brooke Howard as author and committer. GitHub lists
copyberry[bot]as the author account for both merged upstream PRs; that account metadata does not establish individual human authorship or derivation from my patch.brookehoward2008-droid commentedon Oct 15, 2026
Authorship clarification and question about earlier community patch
I checked the public Git metadata behind the bot-published fixes:
My earlier local commit
3e377e5ae58c9f6712dd7040e9e8fb41d3be0488, authored by Brooke Howard, adds SYSTEMDRIVE and LOCALAPPDATA inremote_env_policy()and adds mixed-case preservation assertions to the filtering test. The patch and three passing test results were reported in my earlier comment, before the upstream commits. I recognize that #54069 also adds Windows-aware override handling beyond my change, and #54027 addresses a separate MXC launcher/default-environment layer.In the public PR descriptions, commit messages, discussion and review records inspected, I found no explicit reference to my patch or comments. That does not establish whether the work was independently developed or informed by community reports. Similarity and timing alone do not establish derivation, and I am not alleging copying.
Could the maintainers clarify whether my earlier patch, tests, or comments informed #54069 or the related fix work? If they did, I would appreciate acknowledgment of that contribution in the issue or relevant development record. If the fixes were developed independently or arose from other reports, a clarification would also help keep the provenance accurate.
This is a provenance question only. It does not change the previously stated deployment and verification limits: my successful Dot extension-browser test occurred with a locally modified launcher configured, and does not identify which official fix was deployed or caused that success.
z1197659035-alt commentedon Oct 15, 2026
Update 16 October 2026: actual desktop App restart accepted in the original caller
The user has now normally exited and reopened the desktop App (same Appx 26.1013.3656.0 / App 26.1013.31256). This is a real main-process lifecycle change, not another CUA kernel reset.
Accepted scope: current-version full desktop App restart, canonical configuration regeneration, and original caller's browser startup/full-page capture capability. This does not certify OS reboot, all cloud controllers, business delivery, Library file materialization or universal Chromium background rendering. Original error and intermediate target-mismatch records remain preserved.
Update 16 October 2026: original full-page capture and canonical-config fresh-kernel acceptance passed
This supersedes the unresolved full-page/config-persistence portion of the earlier update, while preserving its historical evidence below.
Scope: this establishes the supported full-page workflow and original task's current fresh-CUA-kernel startup with canonical configuration. It does NOT establish a universal Chromium background-rendering fix, actual environment of every outer MCP controller, future full App/OS restart behavior, or unrelated Dot/cloud execution recovery. Existing connections, network configuration, paused queues and original review packets were untouched.
References:
Update 16 October 2026, 03:35 UTC: original startup and one existing page read recovered on the new version
This adds sanitized evidence for another existing Dot-delegated Windows task that failed on the upgraded desktop. It is not a replacement task, and success was checked in that same originally failing task.
failed to prepare MXC sandbox: MXC requires nonempty Unicode host SystemDrive.cua.getState()succeeded; official browser/tab selection then returned an existing authenticated page's accessibility state. The original task's receipt and official thread readback agree. This establishes startup plus one actual existing-page read, not a complete capture workflow or persistent root-cause repair.CDP operation exceeded its deadline before command dispatchafter about 7.6 seconds. That call combined tab acquisition and a read. The current runtime uses this same error text in both a pre-dispatch deadline check and an asynchronous wait timeout, so neither the exact failing substep nor absence of dispatch can be inferred from the wording alone. No retry or timeout/security modification was made.The remaining request is a supported diagnostic for the actual delegated MCP host/controller environment and build, plus ownership/persistence of generated plugin declarations. The previous version's evidence remains below; its version-specific conclusions should not be applied to the new build.
Update: original delegated task startup recovered; page workflow and persistence remain unverified
Follow-up recorded on 16 October 2026 Asia/Shanghai (15 October UTC). This is sanitized evidence from the same original delegated task, not a replacement task or a different caller's success.
The desktop remains app 26.1007.71326/build 20398, installed package 26.1007.9446.0, bundled CLI 0.162.0-alpha.17.2. The current information-only updater reports unavailable because Windows Store must check eligibility; no update was downloaded or installed. This supersedes the earlier updater observation below and does not establish that an eligible update does or does not exist.
The manifest restoration plus original official reset is correlated with recovery, but without the original effective environment this does not isolate the complete cause. A supported persistent way to preserve these declarations, and the desktop/delegated-controller release carrying both #54027 and #54069, are still relevant. Please retain the earlier failed acceptance below as historical evidence.
Windows Dot-delegated task: compatible environment forwarding installed, original-route acceptance still fails
Additional sanitized evidence from 15 October 2026; no credentials, raw conversation, business content, private task IDs or browser URLs included.
Installed environment
Original failure and supported-manifest compatibility change
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003.mcpServers.cua_repl.env_varsnames were extended fromCODEX_WINDOWS_REGISTERED_COREto additionally includeSystemDriveandLOCALAPPDATA. No variable values were copied. Command, arguments, sandbox permissions, tool settings, transport values and browser connections were unchanged.Original-task acceptance after installation
await cua.getState();; it failed after 8,152 ms.trusted Node process exited unexpectedly; kernel reset, rerun your request.cua_repl status=readybefore/after the failed invocation. Ready is not runtime acceptance; no failed-kernel stderr or its effective environment was exposed in the inspected time window.Controlled mechanism checks and limits
Requested supported repair/diagnostic path
Could maintainers clarify (1) which desktop/delegated-controller release contains both #54069 and #54027, (2) how an existing delegated task can officially refresh its MCP environment without discarding the task or interrupting active browser connections, and (3) the supported way to export the failed trusted-Node kernel's exit code/stderr and environment-name presence? The task remains failed; no end-to-end recovery is claimed.
ToeJamathon commentedon Oct 15, 2026
Another affected Windows installation, reproduced on 15 October 2026 around 18:24–18:42 UTC.
The supported browser inventory call
await cua.getState();exits before returning any browser information:Desktop logs report bundled core
0.162.0-alpha.17.2, browser/CUA component26.1007.71326, and Windows x64 OS release10.0.26300.Resetting the browser helper and fully quitting/reopening the desktop app did not resolve it. A fresh chat also reported failure, although its launch route was not independently verified. The owner checked for updates; none was offered. Ordinary shell commands and a separate JavaScript runtime work.
No environment, sandbox, security or installation settings were changed.
Could maintainers confirm which desktop/controller rollout contains #54069 and #54027, and provide a supported recovery procedure? Fix inclusion and the underlying cause on this installation remain unverified.
Brittymaksic52 commentedon Oct 15, 2026
Additional Windows report from 15 October 2026, around 20:21 UTC:
A dot-created work task was accepted, but browser initialization failed before returning any browser/page inventory:
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
After resetting the browser helper and opening a dedicated Edge tab, the retry failed with:
trusted Node process exited unexpectedly
The user reports that manually started Codex work sessions work on the same PC. That comparison is user-reported; it was not independently retested for this report.
Expected: a dot-delegated task should initialize its supported browser tools and return browser state. Actual: it fails before browser inspection. App/component versions and Windows build were not captured, and no browser state was returned.
Could maintainers provide a supported recovery procedure or identify the desktop/controller release that resolves this? No fix rollout has been verified on this installation.
Zetta-tech commentedon Oct 16, 2026
I'm seeing the same browser-runtime startup failure on Windows, observed on October 16, 2026 (UTC).
Reproduction and errors
A dot-created task on the connected Windows computer attempts the supported browser initialization while Chrome is running. It fails before returning browser inventory:
A supported runtime reset and retry returned:
No browser tab list or page content was returned.
Read-only checks
The exact failing platform-directory lookup and the launcher's effective environment were not captured. These checks do not establish whether a directory is physically missing or its lookup is misconfigured. I cannot confirm that missing SystemDrive or LOCALAPPDATA is the cause on this computer.
The exact desktop version and Windows build were not collected for this report. No runtime patches, reinstalls, registry changes, or sandbox/permission changes were applied during these checks.
Expected behavior and request
The browser runtime should initialize and return the available browser state. If initialization fails, it should identify the failed directory lookup and a supported recovery step.
Could maintainers identify the desktop/delegated-controller rollout containing #54069 and #54027, and the supported way to diagnose this failure in an existing delegated task? Both changes are merged, but their deployment to this installation has not been verified.
No private page content, browsing URLs, usernames, personal paths, credentials, screenshots, or session identifiers are included.
RuntimeHex commentedon Oct 16, 2026
Follow-up to my earlier report: #53188 (comment)
After updating the Windows ChatGPT app, the About dialog confirms ChatGPT 26.1007.71326, released October 13, 2026.
A fresh dot-delegated native Windows CUA test on October 15, 2026, at approximately 21:04 UTC still failed at
await cua.getState();throughmcp__cua_repl.js. The kernel exited with code 1 and the same error:MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
Browser inventory and page reading were never reached. The host is native Windows x64, 10.0.26300.0. No manual patches or environment changes were applied.
Could maintainers confirm which desktop build contains the Windows initialization fixes? This retest establishes reproduction on 26.1007.71326; inclusion of the upstream fixes in this app build has not been verified.
brookehoward2008-droid commentedon Oct 16, 2026
Correction: verified launch context for stock-versus-modified comparison
I read back the original completed task records for the launcher comparison. Both tests were brand-new tasks delegated by the same original Dot conversation. The official task API labels both host=durable and records cloud-controller workspace paths containing a Windows working-directory suffix. This establishes the recorded delegation/routing context; it does not independently establish the executor host, actual launcher file loaded, or effective child environment. These comparison tests must not be described as verified host=local execution. This is separate from my previously reported host=local context for the original incident.
Actual recorded calls:
The delegation instructions document the intended stock substitution and subsequent working-launcher restoration. They are not proof of which bytes the failed process actually loaded. The currently retained launcher was read back and matches the recorded restored working version.
The working version jointly fills missing SYSTEMDRIVE and LOCALAPPDATA, conditionally moves the working directory out of the plugin cache, and imports CUA dynamically afterward. Therefore this is one stock failure followed by one recovery under a combined workaround, not variable-isolation proof or a verified second stock reproduction. Separate browser sessions and warm/cold timing samples are not pooled.
This comparison does not attribute success to an official deployment or validate native Windows MXC end to end. No launcher edits, new tests, installations, or restarts were performed for this verification. Private task IDs, hashes, personal paths and account details are omitted here.
Please correlate the actual delegated controller/executor build and effective environment with this launch route. My separate question about whether the earlier community patch/tests informed the upstream work remains open.
brookehoward2008-droid commentedon Oct 16, 2026
Launcher isolation results and successful recovery — original Dot route
Following my launch-context correction, six valid isolation trials and a final recovery control were completed on October 15, 2026 Pacific (October 16 UTC), through fresh tasks delegated by the same original Dot conversation.
Each task made exactly one first CUA call,
await cua.getState();, then stopped. No retries, runtime resets, tab operations or navigation were performed within the tests. The task API labels all seven recordshost=durable; this is routing metadata, not independent proof of executor platform or actual launcher identity. This comparison remains separate from my previously reported original-incidenthost=localcorrection.The working launcher was restored and its saved hash verified after each valid trial, before applying the next variant. Final launcher and backup verification also passed. No application/browser/service/OS restart or installation was performed.
A preliminary attempt with overlapping restoration is excluded from this table and all causal comparisons because its call/file timing was uncertain.
Interpretation: none of the reduced variants was sufficient in its single trial. SYSTEMDRIVE-only changed the observed error, but did not initialize successfully. The full working configuration succeeded afterward. This supports retaining that configuration; it does not prove which components are necessary, identify the complete cause, capture the effective environment, establish which bytes each process loaded, or demonstrate official desktop/controller deployment. Fresh tasks alone do not prove fresh processes. Failure durations are not successful-startup speed comparisons, and inventory success does not validate page workflows.
Could maintainers correlate this route with the actual controller/executor build and provide a supported way to inspect the failed launcher's effective environment and identity? My separate question about whether my earlier patch/tests informed the upstream fixes, and acknowledgment if applicable, remains open.
Private task/process identifiers, hashes, paths, account details and browsing content are omitted from this public update.
NunoMars commentedon Oct 18, 2026
Another affected user here, with additional diagnostic evidence from Windows on 15–16 October 2026.
Affected setup / symptoms
OpenAI.Codex 26.1013.3656.0(reportedStatus=Ok).MXC requires nonempty Unicode host SystemDriveMXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003failed to launch codex app-server: program not foundIndependent host checks passed
SystemDrive=C:,ProgramData=C:\ProgramData, with the directory accessible.codex.exeCLI sandbox test forcingwindows.sandbox=mxcprintsMXC_OKand exits with code 0.BatchMode=yesSSH in its local user context, while Work-initiated SSH attempts have also failed. This is a separate symptom, not proof of the same root cause.elevatedandunelevatedsandbox settings have not restored Work control.This supports a possible launcher / execution-context difference between direct CLI use and Work, but I cannot establish the actual failing child-process environment from these checks alone. Please do not treat missing host variables or a damaged Windows installation as proven.
I see that #54027 and #54069 were merged on October 14 to address Windows environment handling. Could a maintainer confirm which released Windows desktop/Work builds actually include these changes, and whether they cover this delegated Work/Computer Use launch path? If not, which supported logs or diagnostic procedure would be most useful, and is there a supported fix or recovery procedure?
I have also been trying to obtain technical escalation through OpenAI Support, but instead received repeated guidance about cancelling my subscription and even deleting my account. I do not want to leave OpenAI or cancel ChatGPT. I am exhausted by being directed to departure procedures rather than a fix. I am asking for a working product and an actionable engineering response, not another cancellation link.
No private account details, logs, SSH addresses or credentials are included in this public report.