Windows: accepted folder read grant leaves existing files unreadable when the folder already permits sandbox access

Expected behavior

A user approves read access to a specific local folder. Subsequent sandboxed commands can read the permitted files inside it, or the app reports a concrete failure to establish access. The user should not need to copy each input into a different workspace or manually repair file permissions.

Environment

• Windows 11, display version 25H2, build 26200.9168.
• Desktop package OpenAI.Codex 26.915.4065.0.
• Installed command runtime 0.155.0-alpha.9.2.
• Native Windows elevated sandbox implementation, workspace-write.
• PowerShell 7.6.5.
• Source folder under OneDrive; two existing files, 61,785 bytes and 9,021 bytes.

Observed locally

1. The restricted sandbox account could enumerate the originals and inspect their attributes, but content reads returned Access denied.
2. request_permissions returned an accepted read grant for the exact containing folder, scope turn.
3. The next read targeted the same folder during that same turn and still failed.
4. Before subsequent diagnostic reads, both originals had attributes 0x80420 (Archive, ReparsePoint, Pinned), without Offline, RecallOnOpen, RecallOnDataAccess, or Encrypted.
5. The containing folder's ACL already allowed the local CodexSandboxUsers group Modify/Synchronize, with ContainerInherit and ObjectInherit.
6. The two files had inheritance enabled but lacked the sandbox entries. Their access lists contained only SYSTEM, Administrators, and the normal user, all marked inherited.
7. The normal user could hash both originals. Workspace copies were byte-identical and readable from the sandbox; those copies contained inherited sandbox-group permissions.
8. Adding only an explicit Read/Synchronize entry for CodexSandboxUsers to each original resolved sandbox reads. Exact security-descriptor comparisons verified that all prior entries, ownership, and inheritance metadata were preserved. Original hashes did not change.
9. A fresh local desktop task then read both originals and both copies successfully as the restricted sandbox account, without escalation or an additional grant.

The local evidence establishes the missing child-file permissions as the immediate read barrier. It does not establish what originally caused those inherited entries to be absent, nor contain a trace proving which exact branch of the grant handler executed.

Matching implementation gap in the installed-version source

Public tag rust-v0.155.0-alpha.9.2 resolves to commit 4607249e430dac1c961df4dc615beae88e33cec8.

In apply_read_acls, the implementation tests each supplied root. If broad built-in principals or the sandbox group already allow the requested access on that root, it continues without walking or validating existing descendants:

• Installed-version setup_provisioning.rs, lines 230–300
• In particular, the sandbox-group root check at lines 259–269 skips work when that root already permits access.
• Installed-version acl.rs, lines 520–589 also avoids a setter when the current path already has the requested allow mask.
• Request permission scope storage records accepted grants for the turn or session; acceptance is not itself proof that Windows child-file access succeeded.

The folder-readable/files-unreadable state observed locally satisfies the problematic root-only condition. This provides a concrete code-level explanation consistent with the accepted-but-ineffective folder grant. The missing historical branch trace should not be represented as independently captured runtime proof.

The current public main branch was checked on September 19, 2026. Its setup_provisioning.rs blob SHA was the same as the installed tag's: 6b003f09d67d9ef45c6f19892a7788cc4d72f7ea.

Related upstream change

PR 46241 — Repair Windows sandbox access to existing runtime children, merged September 17, addresses the same general class of missing child permissions under an already-readable parent. Its stated scope is the app's runtime tree. It also skips reparse points and trees with reparse-point ancestors. It should not be presented as a verified fix for user-selected OneDrive document folders.

Requested product fix / regression coverage

• Verify or safely establish actual descendant read access when an approved folder already has a suitable root permission but existing children lack it.
• Honor existing explicit denials and task scope; do not turn a read grant into write access or blindly follow links outside the authorized folder.
• Handle OneDrive cloud-file reparse points deliberately, distinguishing them from directory links that can escape the selected tree.
• Surface a meaningful failure if the app cannot establish access. Do not return a result that users reasonably interpret as working folder access while leaving the next read blocked.
• Add regression tests for existing files with incomplete inherited entries, newly added files, turn/session grants, and another fresh desktop task.

Separate approval-policy issue

The original turn also rejected require_escalated because its effective granular policy had sandbox_approval=false and request_permissions=true. That was a policy-category rejection, not an automatic safety-review denial. A settings-update event appeared during the turn, but the rejection still cited the prior granular configuration. This is separate from the missing file permissions.

Current user impact

Two affected files have been repaired and tested. General folder-grant behavior for new files is not certified as fixed. Requiring repeated copying or file-specific permission edits is not an acceptable normal workflow for this user.

Official expectation: Windows sandbox read-directory grants.

Start with apply_read_acls in codex-rs/windows-sandbox-rs/src/setup_provisioning.rs and the related access checks in acl.rs, then compare the scope and exclusions in PR 46241. Reproduce the existing-child permission case, including OneDrive reparse points, and add coverage for incomplete inherited entries, new files, turn/session grants, and a fresh desktop task. Done means approved reads work or a concrete failure is reported without broadening access.