Windows Codex App: in-app Browser trusted RPC rejects a physical non-system CODEX_HOME even when realpath, ACLs, ownership, and service paths are valid

Codex App version

26.814.5167.0

Environment

• Windows 11 x64 (Microsoft Windows NT 10.0.26200.0)
• Codex App installed from the Microsoft Store
• Browser plugin: openai-bundled/browser/26.814.41407
• Physical (non-junction) CODEX_HOME: D:\CodexHome
• User and process environment both resolve CODEX_HOME to D:\CodexHome

Relevant generated configuration (username and unrelated paths redacted):

CODEX_HOME = 'D:\CodexHome'
NODE_REPL_TRUSTED_CODE_PATHS = 'D:\CodexHome;C:\Users\<user>\AppData\Local\OpenAI\Codex\runtimes\cua_node\<runtime>\bin\node_modules'
NODE_REPL_TRUSTED_SERVICES = '{"browser":"D:/CodexHome/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs","sky":"@oai/sky/service"}'

Problem

The in-app Browser cannot initialize in a fresh Codex thread. The failure occurs before Codex can read the selected tab's title, URL, or DOM, so it is independent of the target webpage.

With the secure post-migration ACLs, importing the packaged Browser client fails with:

Failed to resolve module "D:/CodexHome/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-client.mjs":
EPERM: operation not permitted, realpath 'D:\CodexHome\plugins\cache\openai-bundled\browser\26.814.41407\scripts\browser-client.mjs'

After temporarily granting the Codex sandbox identities the minimum read/execute permission on the Browser plugin directory and traverse/read-attributes permission on its parent directories, Node REPL lstat() and realpath() both succeeded for:

D:\CodexHome
D:\CodexHome\plugins
D:\CodexHome\plugins\cache\openai-bundled\browser\26.814.41407\scripts\browser-client.mjs
D:\CodexHome\plugins\cache\openai-bundled\browser\26.814.41407\scripts\browser-service.mjs

However, setupBrowserRuntime() still failed with:

Trusted RPC dependency must resolve within a configured trusted code path:
file:///D:/CodexHome/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

The service path shown in the error is already inside the configured trusted root.

Reproduction

1. On Windows, set CODEX_HOME to a real physical directory on a non-system drive, such as D:\CodexHome.
2. Fully restart the Codex App and confirm the generated Browser service path and trusted code root both use D:\CodexHome.
3. Open an in-app Browser tab.
4. Start a new Codex thread and ask it to read the current tab title and URL.
5. Initialize the packaged Browser runtime using the absolute client path required by the Browser skill:

const { setupBrowserRuntime } = await import(
  "D:/CodexHome/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-client.mjs"
);
globalThis.agent = await setupBrowserRuntime();

1. Observe either the EPERM realpath import failure or, after granting minimum diagnostic read/traverse access, the trusted RPC rejection above.

Expected behavior

The packaged Browser service should be accepted because its canonical path is inside NODE_REPL_TRUSTED_CODE_PATHS, allowing Codex to select and inspect the in-app Browser tab.

Troubleshooting already performed

• Replaced the original Unicode-profile CODEX_HOME with a physical ASCII-only directory.
• Verified the new directory is physical, not a junction or symlink.
• Verified user-level and process-level CODEX_HOME values.
• Verified generated trusted code paths and Browser service mapping.
• Verified lstat() and realpath() from Node REPL for the trusted root, client, and service.
• Tested minimum sandbox read/execute and parent-directory traversal permissions.
• Changed the relevant Browser directory/file ownership from Administrators back to the desktop user.
• Reset the Node REPL session after permission changes.
• Fully restarted Codex and reproduced in a brand-new thread, ruling out an old per-thread trust snapshot.
• Rolled back temporary sandbox ACL rules after diagnosis.

None of these changed the trusted RPC failure.

Suspected root cause

The Browser trusted-service validator may be comparing the service's canonical path against a stale/different trusted-root snapshot, or may mishandle a physical CODEX_HOME on a non-system drive. The Node REPL filesystem APIs can resolve the exact same root and service path successfully.

Why this appears distinct from related reports

• #19271 primarily reports bundled node.exe execution failing from WindowsApps; Node REPL runs here.
• #21470 covers broader Windows sandbox restrictions; this report reaches the Browser trusted-service validation layer.
• #28005 reports CreateProcessAsUserW failed: 5; that is not the observed final error here.

This report may share an underlying Windows sandbox/runtime-path cause with those issues, but the reproducible symptom and validation boundary are different.