[Windows] Browser/Chrome plugin fails trusted RPC dependency path validation

Summary

On Codex for Windows, the Browser/Chrome runtime fails before it can connect to the Chrome extension with:

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

Environment

• Windows 11 Professional 10.0.26200, x64
• Codex desktop app: 26.814.5167.0
• Codex CLI: 0.148.0-alpha.15
• Browser/Chrome bundled plugins: 26.814.41407
• Chrome extension updated/reinstalled

Impact

Codex cannot initialize the Browser or Chrome browser runtime. The failure occurs before the Chrome extension handshake, so browser control is unavailable.

Reproduction

1. Enable the bundled Browser and Chrome plugins in Codex on Windows.
2. Install/update the Chrome extension through Settings → Computer use.
3. Attempt to connect to Chrome.
4. Browser runtime initialization immediately fails with the trusted RPC dependency error above.

Troubleshooting already attempted

• Updated, removed, and reinstalled the Chrome extension
• Fully restarted Chrome and Codex
• Reset the Windows Codex app data
• Removed and regenerated Browser/Chrome plugin caches
• Verified directory junctions and file hashes
• Confirmed no Zone.Identifier/Mark-of-the-Web stream on the service files
• Regenerated the node_repl configuration in config.toml
• Set exact NODE_REPL_TRUSTED_CODE_PATHS
• Tested both elevated and unelevated Windows sandbox modes
• Tested node_repl with --disable-sandbox

Additional diagnostics

• NODE_REPL_TRUSTED_CODE_PATHS includes C:\Users\xiaoyu\.codex.
• NODE_REPL_TRUSTED_SERVICES points to the existing browser-service.mjs beneath that directory.
• The referenced file exists and is readable.
• Reproducing the exact path-containment implementation from the installed node_repl.exe with the configured roots returns true.
• Starting the same node_repl.exe independently with the same trusted-path variables, but without the Codex sandbox-launch environment, successfully imports browser-client.mjs and initializes setupBrowserRuntime(). This indicates that the trusted roots are lost or inaccessible specifically in the trusted-service subprocess launched by Codex.
• Browser diagnostics found an additional native-host installation failure:
  • Manifest exists: C:\Users\xiaoyu\AppData\Local\OpenAI\extension\com.openai.codexextension.json
  • Missing registry key: HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
  • check-native-host-manifest.js --browser chrome --json reports correct: false
• Chrome is installed at C:\Program Files\Google\Chrome\Application\chrome.exe.
• check-extension-installed.js reports that the expected Chrome user-data directory is unavailable.
• The same Codex version may work on other Windows machines, suggesting installation/registration and trusted-service environment edge cases rather than a simple version mismatch.

Request

Please investigate:

1. Windows path canonicalization/containment and environment propagation for trusted RPC service subprocesses in node_repl.
2. Why the Browser plugin installation can leave the native-host manifest file present but omit the required HKCU NativeMessagingHosts registry key.
3. A supported repair/re-registration flow when the bundled Browser plugin cannot be uninstalled from the plugin UI.

Start with the trusted-service subprocess around node_repl.exe, NODE_REPL_TRUSTED_CODE_PATHS, and the browser-service.mjs/browser-client.mjs entry points; compare it with the independently working launch. Then inspect check-native-host-manifest.js, check-extension-installed.js, and the plugin installation flow. Done means the Windows environment and missing HKCU registry registration have a reproducible diagnosis and a supported repair or re-registration path.