[Windows][26.1002] Browser bootstrap fails with EPERM realpath; sandbox provisioning locks its own runtime #51972

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

The app's update-check tool reports 26.1002.52244, build 13536, release channel prod, status up_to_date.
Windows AppX package / codex doctor reports 26.1002.7124.0.
These are observed version sources; About dialog was not inspected.
Bundled Codex CLI: 0.162.0-alpha.2.

What subscription do you have?

ChatGPT authentication is configured. Exact subscription tier was not collected.

What platform is your computer?

Windows 11 Professional, Microsoft Windows NT 10.0.26200, x64.
Observed on October 8, 2026.

What issue are you seeing?

Browser control fails before it can connect to a browser or read any tab. The documented absolute-path import of the bundled browser client fails in the app-provided Node REPL:

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

Opening a browser tab, resetting the JavaScript kernel, and fully restarting Codex did not resolve this.

A separate, reproducible Windows sandbox provisioning failure appears in logs while Codex runtime processes are running:

runtime read/execute validation failed:
validate runtime read/execute access on <runtime>/bin/node_repl.exe:
open ACL target for root-only update:
The process cannot access the file because it is being used by another process. (os error 32)
setup error: setup refresh had errors

After stopping the browser service, the same provisioning failure targeted:
<runtime>/bin/node_modules/@oai/sky/bin/windows/swift/x64/VCRUNTIME140_1.dll.
The app automatically restarted codex-computer-use-swift.exe, which held that DLL.

What steps can reproduce the bug?

1. In the affected Windows desktop app, ask Codex to control the built-in browser.
2. In the app-provided Node REPL, follow the bundled Browser skill bootstrap:

const { setupBrowserRuntime } = await import(
  "C:/Users/<redacted>/.codex/plugins/cache/openai-bundled/browser/26.1002.52244/scripts/browser-client.mjs"
);
const agent = await setupBrowserRuntime();
const browser = await agent.browsers.getDefault();
nodeRepl.write(await browser.documentation());

The first import fails with the EPERM error above.

Diagnostic comparison in that same REPL:

const fs = await import("node:fs");
const p = "C:/Users/<redacted>/.codex/plugins/cache/openai-bundled/browser/26.1002.52244/scripts/browser-client.mjs";
await new Promise(resolve => fs.realpath(p, (error, value) => {
  nodeRepl.write({ standardRealpath: value, error: error?.code });
  resolve();
}));
try {
  nodeRepl.write({ nativeRealpath: fs.realpathSync.native(p) });
} catch (error) {
  nodeRepl.write({ nativeError: error.code, message: error.message });
}

Observed: callback-based fs.realpath succeeds with the canonical existing path; fs.realpathSync.native returns EPERM. File stat/lstat and reading the file from PowerShell succeed.

Separately, the bundled CLI command codex -s workspace-write sandbox C:\Windows\System32\whoami.exe fails with helper_unknown_error: setup refresh had errors while the app runtime files are in use.

What is the expected behavior?

The bundled browser-client module should import successfully under the normal sandbox, browser setup should connect, and Codex should be able to read a tab's state with normal browser permissions.

Windows sandbox provisioning should not fail because the app has already started its own runtime executables or DLLs.

Additional information

Troubleshooting actually performed:

• Verified browser-client exists, is a regular file, and is readable.
• Verified the runtime executable's SHA-256 matches the corresponding executable in the installed Windows AppX package.
• Observed CodexSandboxUsers ReadAndExecute ACLs on runtime node_repl.exe and node.exe.
• Reset the Node REPL kernel and retested.
• Checked app updates: up_to_date.
• Ran codex doctor --json: sandbox provisioning recorded helper_unknown_error.
• Fully closed Codex and the confirmed browser helper processes, then ran the sandbox command independently. It succeeded with exit code 0 and executed as the restricted sandbox account.
• Relaunched Codex. Browser-client import still failed with EPERM. The next app-triggered sandbox refresh again logged the in-use node_repl.exe failure.
• No sandbox disabling, trust-validation patching, or broad ACL changes were applied.

Runtime manifest:

• Node 24.21.0-cua.1
• Runtime archive cua-node-0.0.29-20261003001300-807782c586fc-windows-x64.zip

Related but not identical reports: #37029 (earlier Computer Use lstat failure), #39399 (trusted RPC path validation failure). This report adds the callback/native realpath comparison and the reproducible runtime-file locking during provisioning on the October build.

The two failures may be related, but their causal relationship has not been established. Please investigate Windows native path canonicalization in the sandboxed module loader and provisioning/startup ordering for runtime ACL validation.

Usernames, workstation names, private project paths, session transcripts, credentials, and unrelated logs are omitted.