deny-read permission profile silently ineffective on native Windows (ACL state empty) — 0.142.5

Summary

On native Windows, a permission profile with a valid deny filesystem rule does not
apply read denial. write denial works; read denial does not. Sandboxed commands can
still read files that a deny rule should block (e.g. ~/.codex/config.toml).

Environment

• codex-cli 0.142.5 (latest stable)
• Windows 11 Home, build 26200
• Native Windows sandbox, [windows] sandbox = "elevated" (elevated backend set up)

Config (corrected to documented syntax)

default_permissions = "review-egress"

[permissions.review-egress.filesystem]
"~/.ssh" = "deny"

[permissions.review-egress.filesystem.":workspace_roots"]
"." = "read"

Steps to reproduce

1. Apply the config above with the elevated Windows sandbox backend.
2. Run a sandboxed command that reads an absolute path under a deny rule.
3. Observed: the file is read successfully; deny_read_acl_state.json remains empty ({"principals": {}}).
4. Expected: read is blocked by policy (parity with write-deny, and with macOS/Linux).

Notes

• write-deny behaves correctly; only read-deny is ineffective.
• Non-elevated returns an "elevated backend required" error (i.e. the rule is now

recognized, unlike undocumented keys which were silently ignored).

• Sandbox log shows "read-acl-only mode: applying read ACLs" completing in ~1ms with no deny ACEs applied.
• Possibly related: #28566, #30758.

Impact

Any workflow relying on read-deny for secret isolation on native Windows is silently
unprotected, with no error surfaced when the elevated backend is present.