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

Finding: On Windows 11 x64, reporters of openai/codex#51972 say the Codex desktop app's bundled Browser (and Computer Use) module import fails in the app Node REPL with EPERM on realpath, before any browser action. This was reported on app 26.1002.52244 (AppX 26.1002.7124.0) and again on 26.1007.21434 (AppX 26.1007.2314.0). Limitation: these are external reports; KFA did not reproduce them, and no maintainer-confirmed cause or fix appears in the supplied sources. Reported evidence: the original reporter says importing the bundled browser-client.mjs by absolute path fails with 'EPERM: operation not permitted, realpath'. Callback fs.realpath reportedly succeeds on the same file, while fs.realpathSync.native returns EPERM; stat and PowerShell reads work (https://github.com/openai/codex/issues/51972). Other commenters report the same pattern for the Computer Use client module (https://github.com/openai/codex/issues/51972#issuecomment-6064269552). Another reports that importing local project modules is also blocked in the same runtime (https://github.com/openai/codex/issues/51972#issuecomment-6072994309). A newer-build reproduction on 26.1007.21434 reports the same failure and says the native-vs-callback difference persists (https://github.com/openai/codex/issues/51972#issuecomment-6086936491). Separate symptom: the original reporter also logged a Windows sandbox provisioning failure ('setup refresh had errors', os error 32) while the app's own runtime files such as node_repl.exe were in use. Closing Codex let a standalone sandbox command succeed, but the browser import still failed after relaunch (https://github.com/openai/codex/issues/51972). One commenter found no such file-lock log events on their machine (https://github.com/openai/codex/issues/51972#issuecomment-6081288760), and the latest commenter says the file-lock repair and the loader failure should not be treated as one fix (https://github.com/openai/codex/issues/51972#issuecomment-6086936491). The causal link is unestablished. Hypotheses, not confirmed: one commenter observed that the kernel and Browser worker run in low-integrity AppContainers, and that NODE_REPL_TRUSTED_CODE_PATHS reaches the supervisor and worker but not the kernel. They suggest a realpath fallback whose trusted roots are too narrow, and they state the denied Windows right is unconfirmed (https://github.com/openai/codex/issues/51972#issuecomment-6081288760). Another commenter's observations favor a restricted-context compatibility issue but do not prove the mechanism (https://github.com/openai/codex/issues/51972#issuecomment-6055772294). Status: no working workaround is reported. Kernel reset, restarts, app update, repair, restoring plugin files, and a newer signed CLI did not help. The thread shows only an automated duplicate notice (https://github.com/openai/codex/issues/51972#issuecomment-6053611082) and no fix commit or release. Useful diagnosis for others: record the app and AppX versions and compare callback fs.realpath with fs.realpathSync.native on the failing file, without disabling the sandbox or changing broad ACLs.