Windows sandbox: nested read-only Temp rule selected, but enforcement unverified (CLI 0.153.4)

What version of the Codex App are you using (From “About Codex” dialog)?

Codex & OWL Version 26.901.512311231

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Protection of an explicitly read-only directory nested inside Windows user Temp cannot be established.

The authenticated CLI/backend version is 0.153.4. Elevated Windows sandboxing is configured. A resumed CLI session explicitly selected a named profile extending :workspace, with network disabled and the exact protected Temp subtree set to read. The merged policy retained this rule alongside inherited Temp write permissions.

The observed shell used a restricted, medium-integrity offline sandbox token. Read-only token/DACL analysis found applicable inherited Modify grants (0x1301bf) on the protected subtree.

No protected write probe was performed, so this does NOT demonstrate that a write would succeed or establish a sandbox bypass.

Existing setup logs report successful processing of three write roots, but do not expose the serialized exclusion or its path-specific enforcement result. An error 5 for C:/Users/Default concerns a different path and has not been attributed to this issue.

Project execution remains paused pending clarification of the effective protection.

What steps can reproduce the bug?

Feedback ID: 01a0723c-2237-74d1-b05a-c86ab262d45d
Observed sequence; a fresh minimal reproduction has not been independently validated:

1. Use native Windows with the elevated Codex sandbox configured.
2. Define a named profile extending :workspace, disable network, and mark an existing directory beneath the host user's Temp directory read-only.
3. Resume the task through CLI 0.153.4 with explicit profile overrides.
4. Confirm that the selected and merged policy retains the exact read rule.
5. Inspect the sandbox token and relevant directory DACLs read-only.
6. Observe applicable inherited Modify grants on the protected subtree, while existing setup logs provide no path-specific exclusion result.

Illustrative redacted configuration, not an executable replacement:

default_permissions = "aaos008-working-readonly"

[permissions.aaos008-working-readonly]
extends = ":workspace"

[permissions.aaos008-working-readonly.filesystem]
'<USERPROFILE>/AppData/Local/Temp/<PROTECTED_WORKING>' = "read"

[permissions.aaos008-working-readonly.network]
enabled = false

No write probe or proposed project child was launched.

What is the expected behavior?

The exact nested read rule should be enforced despite broader Temp write permissions, while preserving authorized workspace writes and disabled network.

Please clarify whether another enforcement layer makes the observed Modify grants insufficient for writing, which supported diagnostic establishes this rule's application, and the appropriate task-scoped remedy if it was not applied.

Additional information

Feedback submitted through Codex.

Feedback ID: 01a0723c-2237-74d1-b05a-c86ab262d45d

A redacted technical report with backend executable hashes and timestamped sandbox-log excerpts is available. The selected-profile observations were collected in the CLI-resumed session.

No backend cause or sandbox bypass has been established. Private project contents, credentials and raw diagnostic logs are not attached.

Start with the native Windows reproduction using CLI 0.153.4 and the named profile configuration described in the report. Compare the merged read-only rule with the sandbox diagnostics and inherited DACLs; done means establishing whether the nested Temp rule is enforced, identifying a supported diagnostic for its application, and documenting the task-scoped remedy if it is not.