Skip to content

Windows browser control fails with MXC platform directory HRESULT 0x80070003 on Desktop 26.1007.2314.0 #52857

Open
Open
Windows browser control fails with MXC platform directory HRESULT 0x80070003 on Desktop 26.1007.2314.0#52857
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@Rebolvsk
Rebolvsk
opened on Oct 10, 2026

Related: #52407. Additional reproduction observed on 10 October 2026 with a newer installed desktop package.

Environment

  • Windows 11 Pro, build 26200, x64.
  • Codex desktop package: 26.1007.2314.0.
  • Authorized connected Windows execution environment.

Reproduction

  1. Start a fresh runtime using the supported CUA tool reset.
  2. Use the supported browser entry point to open a simple official page:
await cua.createBrowserTab("iab", "https://learn.chatgpt.com/", { visible: false });
  1. The runtime exits before the page can be opened:
node_repl kernel exited unexpectedly
MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003
kernel_status: exited(code=1)

An earlier attempt also returned:

trusted Node process exited unexpectedly; kernel reset, rerun your request

The user restarted both Chrome and Codex. The same MXC error persisted in a fresh runtime afterward. PowerShell, read-only file access and ordinary commands work; supported browser control does not initialize.

Read-only checks

The installed package has a valid OpenAI signature, and the Node/node_repl runtime components are present. Program Files, Program Files (x86) and ProgramData resolve successfully in separate PowerShell known-folder tests. Those tests do not establish that the failing MXC launch context can resolve them. Root cause remains unconfirmed.

Request

Please help restore supported browser control and identify the failing directory or launcher context, with a supported recovery path that preserves existing sessions and security boundaries.

No user files, personal screenshots, account identifiers, secrets or broad automatic logs are attached.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    browser
    on Oct 10, 2026

  2. github-actions commented on Oct 10, 2026

    @github-actions
    github-actionsBot
    on Oct 10, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. Phoen1x1996 commented on Oct 12, 2026

    @Phoen1x1996
    Phoen1x1996
    on Oct 12, 2026

    Correction (Oct 13): windows.allow_mxc is ignored by this build, so the workaround at the end of this comment is wrong. What actually fixed it was completing the elevated sandbox setup; see my follow-up: #52857 (comment)

    Same error here, plus a workaround that restored local Chrome/Edge control for me.

    Environment: Windows 11 25H2 (build 26200.9457, x64), Codex desktop 26.1007.2314.0, bundled CLI 0.162.0-alpha.17.2. config.toml had [windows] sandbox = "elevated" (elevated sandbox already set up) and no MXC settings; the app starts app-server and the Work executor with -c features.prefer_mxc=true.

    Symptom: in Work Mode, cua.getTab(..., { browser: "chrome" }) and cua.createBrowserTab("edge", ...) both fail in ~0.7 s with MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003 (kernel exited with code 1).

    What I ruled out locally:

    • The message comes from platform_read_roots() in codex-rs/mxc-sandbox/src/windows.rs (SHGetKnownFolderPath for ProgramFiles / ProgramFilesX86 / ProgramData). Calling the same API with the same flags succeeds for all three folders in: my normal session, the Codex core env, the reduced env node_repl passes to its kernel, the exact env of the running exec-server, the OpenAI.Codex package context, inside MXC, and inside the legacy unelevated/elevated sandboxes.
    • codex -c windows.sandbox=mxc sandbox --permission-profile :workspace -- cmd /c echo MXC_OK succeeds in every context where MXC is available.
    • The folders exist (no junctions), registry/env values are standard, no known-folder redirection.
    • MXC nested inside MXC fails with a different error ("native MXC is unavailable on this executor"), not 0x80070003.
      So I could not reproduce the failing launch context outside Work Mode.

    Workaround: add allow_mxc = false under [windows] in %USERPROFILE%\.codex\config.toml (keep sandbox = "elevated"), then fully quit and restart the app. After that, both Chrome and Edge browser control work in Work Mode. This falls back to the legacy elevated sandbox, so it assumes that sandbox is already set up; remove the line once this is fixed.

  4. flawlessweb commented on Oct 12, 2026

    @flawlessweb
    flawlessweb
    on Oct 12, 2026

    Workaround that fully restored browser control for me. Same package as this report: OpenAI.Codex 26.1007.2314.0, bundled CLI 0.162.0-alpha.17.2, cua_node runtime 0.0.29, Windows 11 Pro 26H2 build 26300.9457.

    Add this to config.toml in your Codex home folder, then fully quit and restart Codex:

    [windows]
    allow_mxc = false

    If the file already has a [windows] section, add the allow_mxc line under it instead of creating a second section.

    This is the opt-out added in #51547. It stops Codex from selecting the MXC sandbox, so the browser kernel launches through the legacy Windows sandbox and never reaches the failing platform_read_roots() lookup. Delete the line to undo it.

    This is a temporary workaround, not a fix:

    • It gives up the MXC backend until the line is removed.
    • The legacy sandbox may run its own setup step.
    • If config.toml sets windows.sandbox = "mxc" explicitly, Codex rejects the combination.

    Possible cause for maintainers (not confirmed on my machine): the MXC launcher does its known-folder lookup in the already-filtered child environment (codex-rs/mxc-sandbox/src/windows.rs, run() -> platform_read_roots()). #47108 fixed this same error for the filesystem helper by preserving SystemDrive with case-insensitive matching. node_repl.exe launches the kernel through codex sandbox with windows.sandbox="mxc" and a filtered environment, so that launch path may have the same gap. The documented MXC probe (cmd.exe /d /c echo MXC_OK) passes from a normal shell, and SHGetKnownFolderPath succeeds there for ProgramFiles, ProgramFilesX86 and ProgramData, which fits an environment difference rather than missing folders.

    Also seen in #52407, #52858 and #52569. It would help if the error included the failing folder ID.

  5. MaGioMusic commented on Oct 12, 2026

    @MaGioMusic
    MaGioMusic
    on Oct 12, 2026

    I’m also affected on Codex desktop 26.1007.2314.0 on Windows. Computer Use in a dot-delegated local task fails before taking a screenshot or listing browser tabs:

    MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003

    Local file access, code edits and tests still work. A fresh Computer Use attempt on October 12 reproduced the same error. I haven’t verified whether a directly opened local Codex chat avoids it.

    Is this a known issue with the delegated Windows execution context? Please provide a supported recovery path and specify which diagnostic logs would help. I’d prefer not to change sandbox security settings based on an unverified workaround.

  6. Ismaelmunozcubero commented on Oct 13, 2026

    @Ismaelmunozcubero
    Ismaelmunozcubero
    on Oct 13, 2026

    Same symptom on Windows 11 Home 25H2, build 26200.9457, ChatGPT desktop 26.1007.21434.

    Error: MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003, followed by node_repl kernel exited unexpectedly.

    From PowerShell, Program Files, Program Files (x86) and ProgramData all resolve correctly through SHGetKnownFolderPath (HRESULT 0x00000000), so the folders exist and are readable in an interactive session.

    Built-in browser and image analysis fail in Work. Chat mode works. The same account works on another PC.

    Reinstall and repair did not help.

    Feedback sent in-app: no-active-thread-01a131c9-6f4a-7833-b4b0-297c40602cbb

    Happy to test a fix or provide more diagnostics.

  7. Ismaelmunozcubero commented on Oct 13, 2026

    @Ismaelmunozcubero
    Ismaelmunozcubero
    on Oct 13, 2026

    Follow-up test with allow_mxc = false:

    I added allow_mxc = false directly under sandbox = "elevated" in the [windows] section of ~/.codex/config.toml, then fully closed and reopened the Work desktop app from the system tray.

    Result: the browser still fails, with a different error.

    • Before the change: cannot locate required Windows platform directory: HRESULT 0x80070003
    • After the change, first attempt: trusted Node process exited unexpectedly; kernel reset, rerun your request
    • After the change, after a full restart:
    node_repl kernel exited unexpectedly
kernel_status: exited(code=1)
creation_flags=134743040 (Windows error 5)
reason: stdout_eof
stream_error: null

    Wikipedia never loaded in either attempt. I have not tested image upload with this setting.

    The web version of Work works in Chrome and Edge, so the failure seems specific to the desktop app's local node_repl process on Windows.

    I have reverted the change; the config is back to its original state.

    Feedback ID from earlier: no-active-thread-01a131c9-6f4a-7833-b4b0-297c40602cbb

  8. Ismaelmunozcubero commented on Oct 13, 2026

    @Ismaelmunozcubero
    Ismaelmunozcubero
    on Oct 13, 2026

    Correction to my previous comment, plus what I think is the root cause.

    1. windows.allow_mxc is not recognized by this build (Codex Desktop 26.1007.21434). The app-server log says: Codex is ignoring 2 unrecognized configuration settings ... windows.allow_mxc is ignored. So my previous test did not disable MXC, and the different error I reported was not caused by that setting.

    2. [features] prefer_mxc = false in config.toml is accepted (no warning), but it has no effect. With it set, the browser fails again with MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003.

    3. The reason seems to be that the desktop app launches its processes with -c features.prefer_mxc=true, which overrides the user's config.toml:

    • codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled -c features.prefer_mxc=true ...
    • codex.exe -c features.prefer_mxc=true -c forced_login_method="chatgpt" exec-server --remote ...

    Logs also show windows_sandbox_type: WindowsMxc, windows_sandbox_level: Elevated.

    So affected users currently have no way to opt out of MXC. Could the desktop app respect features.prefer_mxc = false from the user config, or fall back to the elevated sandbox when the MXC launcher fails?

    Windows 11, Codex Desktop 26.1007.21434. Config reverted to original.

  9. Phoen1x1996 commented on Oct 13, 2026

    @Phoen1x1996
    Phoen1x1996
    on Oct 13, 2026

    Correction to my comment above, plus what actually fixed it on my machine.

    @Ismaelmunozcubero is right: this build ignores windows.allow_mxc. My app-server log shows the same "windows.allow_mxc is ignored" warning on every start since I added it, so that line was not what restored browser control. Sorry for the misleading workaround.

    What did change: %USERPROFILE%\.codex\.sandbox\setup_marker.json did not exist, even though config.toml had [windows] sandbox = "elevated". While testing I ran

    codex.exe -c windows.sandbox=elevated sandbox --permission-profile :workspace -- cmd.exe /d /c whoami

    The sandbox log recorded "sandbox setup required: sandbox setup marker missing or incompatible", then ran the elevated sandbox setup (ensured the CodexSandboxOffline/CodexSandboxOnline accounts, added firewall rules, created .sandbox-bin and setup_marker.json). After the next full app restart, .codex\.sandbox\sandbox.<date>.log shows the Work Mode browser kernel (node.exe --experimental-vm-modules --eval ...) starting through codex-command-runner (the elevated sandbox) instead of the MXC launcher. Chrome/Edge control has worked since, across several restarts.

    My guess is that Work Mode falls back to MXC for the browser kernel when the elevated sandbox has not been set up, and that MXC path is what fails with 0x80070003. Not confirmed beyond my machine.

    If you are affected, check whether %USERPROFILE%\.codex\.sandbox\setup_marker.json exists. If it doesn't, running the command above once from a normal PowerShell (with the codex.exe under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\), approving the Windows admin prompt if one appears, and then fully restarting the app is what worked for me. Note that this setup creates local Windows accounts and firewall rules for the Codex sandbox.

  10. Ismaelmunozcubero commented on Oct 13, 2026

    @Ismaelmunozcubero
    Ismaelmunozcubero
    on Oct 13, 2026

    More data from further testing (Codex Desktop 26.1007.21434, Windows 11):

    1. Timeline from my local logs (logs_2.sqlite): until 2026-10-07 the sandbox was windows_sandbox_type: WindowsRestrictedToken and feature.prefer_mxc was false. On 2026-10-07 at 18:21 UTC (CLI 0.160.1) prefer_mxc switched to true, and from 18:53 UTC the sandbox became WindowsMxc. The browser failures started with that change.

    2. The desktop app stores "electron-prefer-mxc-enabled": true in ~/.codex/.codex-global-state.json. With the app closed, I set it to false. After restarting, the app-server process was no longer launched with -c features.prefer_mxc=true (the exec-server --remote process still was).

    3. Even so, the browser still failed with the same error: node_repl kernel exited unexpectedly / MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003. So node_repl seems to start its kernel inside MXC independently of features.prefer_mxc.

    4. After closing the app, electron-prefer-mxc-enabled was back to true on its own, so it looks like it is set remotely.

    Conclusion: affected users have no way to opt out of MXC for the browser/node_repl, neither via config.toml nor via app state. Could you add a fallback to the previous sandbox when the MXC launcher fails, or a supported opt-out?

    All changes reverted; everything is back to its original state.

  11. Ismaelmunozcubero commented on Oct 13, 2026

    @Ismaelmunozcubero
    Ismaelmunozcubero
    on Oct 13, 2026

    Additional data point: inside the app's own sandboxed shell (exec_command, LOCALAPPDATA = ...\AppData\Local\Packages\sandbox.{GUID}\AC, i.e. an AppContainer), platform folders resolve fine:

    • $env:SystemDrive = C:, $env:ProgramFiles = C:\Program Files, $env:ProgramData = C:\ProgramData
    • [Environment]::GetFolderPath('ProgramFiles') = C:\Program Files
    • [Environment]::GetFolderPath('CommonApplicationData') = C:\ProgramData
    • Test-Path on both = True

    So the sandbox itself can resolve these folders on this machine. The HRESULT 0x80070003 seems specific to the path node_repl uses to launch its kernel through the MXC launcher.

  12. sywu0820-max commented on Oct 13, 2026

    @sywu0820-max
    sywu0820-max
    on Oct 13, 2026 – with ChatGPT Codex Connector

    Additional reproduction on Codex Desktop 26.1007.2314.0, checked on 2026-10-13 (UTC).

    After reopening the desktop app, one supported local IAB read still failed before navigation:

    MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003

    The node_repl kernel exited with code 1. An earlier attempt reported trusted Node process exited unexpectedly; kernel reset.

    A limited read-only diagnostic found:

    • Selected cua_node runtime: 0.0.29/20261005054403-144090e2ddcb.
    • Node: 24.21.0-cua.1.
    • node.exe, node_repl.exe and node_modules are present and readable.
    • Both executable SHA-256 values match their corresponding files in the installed package.
    • The inspected error-related logs did not identify the exact Windows platform directory that failed resolution.

    No sandbox settings, accounts, firewall rules or runtime cache were changed. Reopening the app did not resolve this reproduction; the evidence does not establish missing files as the cause.

    Could maintainers identify the failing directory/launcher context and provide a supported recovery procedure that preserves existing sessions and security settings? This summary omits account identifiers, local user paths, conversation content, project source, credentials and raw logs.

  13. Ismaelmunozcubero commented on Oct 15, 2026

    @Ismaelmunozcubero
    Ismaelmunozcubero
    on Oct 15, 2026

    Update: still broken after updating to 26.1007.71326 (Windows 11, bundled CLI 0.162.0).

    What changed:

    • Before (26.1007.21434): "node_repl kernel exited unexpectedly / MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003"
    • Now (26.1007.71326): on first launch the logs show "node_repl MCP server startup failed ... (os error 3)". After restarting the app, node_repl initializes, but opening the in-app browser fails with:
      "trusted Node process exited unexpectedly; kernel reset, rerun your request"

    Other details:

    • Sandbox is still WindowsMxc (feature prefer_mxc=true, enabled remotely since Oct 7).
    • I tested [windows] allow_mxc = false again on 26.1007.71326: the app logs still report "windows.allow_mxc is ignored", so there is no way to opt out of MXC for node_repl. Reverted.
    • Terminal commands inside Work run fine under MXC; only node_repl (in-app browser and image reading) is affected.
    • The same account works fine in Work on the web (Chrome/Edge).

    Could someone from the team confirm whether a fix for node_repl under MXC is planned, or provide a supported way to fall back to the previous sandbox (WindowsRestrictedToken) in the meantime? Happy to share logs if needed.

  14. gagetc-rgb commented on Oct 16, 2026

    @gagetc-rgb
    gagetc-rgb
    on Oct 16, 2026

    Additional reproduction on 17 October 2026. This case has a useful difference between execution contexts: browser control works in a local Codex chat but fails in ChatGPT Work on the same computer.

    Environment:

    • Windows x64, 25H2, build 26200.9711.
    • Desktop app version reported by the app: 26.1007.21434, build 13901, prod channel.
    • Installed Windows package: OpenAI.Codex 26.1007.2314.0.
    • Bundled CLI: 0.162.0-alpha.17.2.

    Reproduction in ChatGPT Work:

    1. Reset cua_repl successfully.
    2. Run await cua.getState();.
    3. The kernel exits before inventory or browser connection:
    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: null

    The same failure occurs when attempting to create a Chrome tab. Restarting only the local Work exec-server reconnects it successfully but does not fix the failure. A subsequent user retry also reproduces the same launcher error.

    Comparison and checks:

    • In a separate local Codex chat on the same machine, both the in-app browser and connected Chrome can create tabs, read page content, click links and navigate. Google Flights opens and accepts destination input there.
    • SHGetKnownFolderPath succeeds for ProgramFiles, ProgramFilesX86 and ProgramData, and all three directories exist, both from the local Codex shell and from the affected Work shell. This does not prove they are visible inside the failing kernel launch context.
    • The documented host-side MXC test succeeds with exit code 0 and MXC_OK:
      codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
    • Desktop logs show repeated codex.exec_server.process_spawn_failed during Work attempts.
    • A separate legacy elevated-sandbox probe fails with CryptUnprotectData failed: 2148073483; no fallback configuration was applied.

    Please investigate the difference between Work and local Codex kernel-launch contexts and include the actual missing known-folder identity/path in launcher diagnostics. Root cause is not established. No credentials, account/chat identifiers, personal files, travel details or raw automatic logs are attached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions