[Windows][26.820.10647.0] Sandboxed profile-directory reads return EPERM, blocking local esbuild after Desktop update

Codex App version

Current: 26.820.10647.0. Earlier on the same day: 26.820.7780.0.
Versions were identified from the WindowsApps package paths recorded in the local sandbox log, not from the About dialog.

The command-runner is 0.150.0-alpha.8. That same runner version appears in logs from August 26 as well as before and after today's app update, so this report does not establish that the runner version changed today.

Platform / environment

• Windows 10 Home 22H2, build 19045.6466, x64; Japanese locale.
• Windows-native execution, PowerShell; [windows] sandbox = "elevated".
• Desktop permission selection: Ask for approval; no Full Access.
• Node.js 24.19.0, a local TypeScript web application using esbuild/Wrangler.
• Project stored on the local C: drive under C:\Users\<redacted-user>\Documents\Codex\<date>\<project>.
• Subscription details are not included in this public report.

What issue are you seeing?

The Desktop app and its local command execution service start successfully. Commands can read the project and run its pure logic tests. However, enumerating the signed-in user's profile directory, C:\Users\<redacted-user>, fails inside the sandbox with EPERM.

This blocks local startup/bundling when esbuild tries to read an ancestor directory, even though the source file itself is readable. Current sandbox probes return:

workspace-read: OK
parent-directory-read: EPERM

A memory-only esbuild check (bundle: true, write: false, platform: "node", with an existing project TypeScript entry point) failed with:

Cannot read directory "../../../..": Access is denied.
Could not resolve "./lib/constraint-types.ts"

A local-server startup attempt also reported:

Cannot read directory "../../../../../..": Access is denied.

All 16 pure rule-engine tests pass. The server-dependent API/persistence tests cannot be rerun because local startup is blocked; this is not a claim that their assertions fail.

Timeline / evidence limitations

All times below are 2026-08-28, JST (UTC+09:00):

• 08:38: an existing local development verification note records successful build, API tests, HTTP response and persistence across a server restart. This is a saved earlier result, not a fresh replay of the old version or a raw trace attached here.
• 09:03:56: the sandbox log still records app package 26.820.7780.0.
• 09:10:14: the sandbox log records package 26.820.10647.0. The user confirms updating Codex Desktop that morning.
• 09:17: a local revalidation note records the build access-denied failure.
• Subsequent direct filesystem probes reproduce the profile-directory denial; restarting Desktop did not fix it.

This is a suspected update-related regression, not a confirmed causal attribution. We have not performed a rollback/A-B test and cannot assert that the app update was the only environmental change.

Minimal diagnostic reproduction on the affected installation

1. Open the existing local project in Codex Desktop using Windows-native sandboxed execution / Ask for approval.
2. Ask Codex to run the following with the available Node executable. Replace the redacted path with the actual signed-in Windows user's profile path. Do not derive it from the sandbox process's own home directory, which may differ.

node -e 'const fs = require("node:fs"); for (const [label, directory] of [["workspace", process.cwd()], ["parent-directory", "C:/Users/<redacted-user>"]]) { try { fs.readdirSync(directory); console.log(label + "-read: OK"); } catch (e) { console.log(label + "-read: " + e.code); process.exitCode = 1; } }'

3. The workspace read succeeds; the profile-directory read fails. This probe does not print directory contents or write files.
4. Try the existing project's local build/startup. Ancestor-directory reads fail as above.

The normal signed-in user's PowerShell can inspect the profile directory's ACL. The same ACL inspection inside Codex is denied.

Troubleshooting already performed — important qualification

This installation is not an untouched reproduction:

• Additional task permission requests for workspace/temp access and profile/drive read access were attempted during troubleshooting; the directory-read failure persisted.
• After the failure was observed, the user tried a nonrecursive, non-inheriting icacls /grant to add CodexSandboxUsers:(RX) on the profile directory itself only. No /T, (OI), or (CI) was used. The command ran for a prolonged time without completion and was interrupted with Ctrl+C.
• A subsequent normal-PowerShell ACL display for that directory matched the earlier display: SYSTEM, Administrators and the signed-in user had full-control entries, and no CodexSandboxUsers entry appeared. This comparison is only for that directory; it is not a claim that every OS ACL was audited.
• Desktop was restarted; the denial still reproduces.
• No explicit sandbox reset/reinstallation, rollback, WindowsApps ownership/ACL modification, Full Access switch, or disabling of security software was performed. No app-code workaround was applied.

Current dated sandbox logs repeatedly contain:

setup refresh: processed 3 write roots (read roots delegated); errors=[]
read-acl-only mode: applying read ACLs
read ACL run completed

These messages coexist with the actual read denial. They do not establish that the requested directory received effective access.

Expected behavior / diagnostic request

The supported permission flow should provide the intended read access for local development, or identify exactly which policy/ACL prevents it and give a supported recovery path. A read-ACL completion message alone does not explain this failure.

Please advise which sanitized diagnostics would distinguish a Desktop permission-profile regression from pre-existing Windows ACL state. Full logs, private paths, project data and credentials have deliberately not been uploaded.

Related but not identical reports

• #41088: local execution fails during startup/handshake before commands run. In this case commands do run, and the failure is a specific directory read.
• #40867: the bundled Codex binary cannot execute. Here Codex and the command runner execute successfully.

These are context links, not an assertion of a shared root cause.

Start by reproducing the workspace-read and parent-directory-read probes from the issue on the affected Windows installation, then compare the sandbox logs showing read-ACL completion with the actual EPERM result. Check the permission-profile and ACL handling involved in Windows-native sandboxed execution. Done means identifying whether the failure is a permission-profile regression or pre-existing ACL state and documenting a supported recovery path.