Windows: Browser tool fails to load in MXC (realpath EPERM), neither Chrome nor Edge works #53045

Activity

1. lovemilliejiang-bot

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Oct 11, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   browser

   on Oct 11, 2026
3. github-actions

   changed the title [-]Windows：浏览器工具在 MXC 中加载失败（realpath EPERM），Chrome / Edge 均无法使用[/-] [+]Windows: Browser tool fails to load in MXC (realpath EPERM), neither Chrome nor Edge works[/+] on Oct 11, 2026
4. github-actions commented on Oct 11, 2026

   

   github-actionsbot

   on Oct 11, 2026 – with GitHub Actions

   Contributor

   More actions

   English translation:

   What version of the Codex App are you using (From “About Codex” dialog)?

   26.1007.21434 (Build 13901, prod)

   What subscription do you have?

   ChatGPT Plus

   What platform is your computer?

   Microsoft Windows NT 10.0.26200.0 x64 System version: 25H2 OS Build: 26200.9457

   What issue are you seeing?

   The Windows desktop app cannot control Chrome or Edge. The failure directly verified so far occurs during browser component loading, before browser selection or tab operations begin.

   The module loading error is as follows (username redacted):

   Failed to resolve module "C:/Users//.codex/plugins/cache/openai-bundled/chrome/26.928.21956/scripts/browser-client.mjs": EPERM: operation not permitted, realpath 'C:\Users<user>.codex\plugins\cache\openai-bundled\chrome\26.928.21956\scripts\browser-client.mjs'

   Diagnostic findings:

   • The target file exists, and stat and opening it read-only succeed.
   • fs.realpathSync succeeds, but fs.realpathSync.native returns EPERM, with errno -4048.
   • The actual tool launcher explicitly passes windows.sandbox="mxc".
   • Even when the user configuration sets windows.sandbox="elevated" and features.prefer_mxc=false, the actual browser tool still uses MXC and reports the error.

   The issue persists, and browser control has not been restored.

   What steps can reproduce the bug?

   Feedback ID: 01a12927-2c96-7230-a8b9-2a1493fe96cd
   Chat ID: 01a12927-2c96-7230-a8b9-2a1493fe96cd

   User actions:

   1. Start a Chrome browser task in the Windows Codex desktop app, for example: “Use Chrome to open https://example.com, then tell me the page title.”
   2. The tool attempts to load the Chrome plugin's browser-client.mjs.
   3. Module loading immediately returns realpath EPERM, and the task cannot continue.

   Tool-level reproduction code (replace with the local username):
   await import("C:/Users//.codex/plugins/cache/openai-bundled/chrome/26.928.21956/scripts/browser-client.mjs");

   Comparative verification:

   1. In the MXC read-only sandbox, call fs.realpathSync and fs.realpathSync.native on the same file.
   2. JavaScript realpath succeeds, while native realpath returns EPERM.
   3. In the legacy elevated read-only sandbox, both native realpath and module import succeed.
   4. Retesting the actual browser tool still fails, including after resetting the tool execution session.

   What is the expected behavior?

   The browser tool should load its components normally while retaining sandbox isolation and path safety checks, and connect to Chrome and Edge respectively.

   Chrome should be able to open https://example.com and read the actual page title; Edge should be able to read the tab list normally.

   If there is a compatibility issue under MXC, please provide a supported way to switch to legacy elevated, or fix native path resolution compatibility.

   Additional information

   Further local comparison results:

   • In MXC, GetFinalPathNameByHandleW succeeds when returning an NT device path or a path without a volume name; requesting a path with a drive letter fails with Windows error 5 (ERROR_ACCESS_DENIED).
   • In MXC, QueryDosDeviceW(C:/E:), GetVolumeNameForVolumeMountPointW, and opening MountPointManager read-only also return error 5.
   • Outside the sandbox and in the legacy elevated comparison environment, these queries succeed.
   • TokenIsAppContainer=1 inside MXC; it is 0 inside legacy elevated. Neither comparison process used an administrator-elevated token.
   • Two official Node versions (v24.19.0 and v24.21.0, both using libuv 1.52.1) exhibit the same native realpath error in MXC.
   • resolvePathSpecifier in the local tool's kernel.js calls fs.realpathSync.native(candidate) at line 523 and throws a module resolution error when it fails.
   • The desktop app's update check returns up_to_date.

   These results locate the issue in shared module loading and sandbox path resolution. They do not yet establish whether the individual Chrome / Edge extensions or native hosts are working normally. The specific component responsible or a version that fixes this issue has also not yet been confirmed.

   Please help investigate the tool launcher's forced use of MXC and the native path resolution failure inside MXC.
5. github-actions commented on Oct 11, 2026

   

   github-actionsbot

   on Oct 11, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows][26.1002] Browser bootstrap fails with EPERM realpath; sandbox provisioning locks its own runtime #51972
   • Chrome automation fails on Windows before connecting to a healthy extension #52626
   • Windows sandbox: native realpath returns EPERM inside writable workspace #52593
   • Windows desktop: Python Path.resolve(strict=True) fails with WinError 5 despite successful file reads #52639

   Powered by Codex Action