Codex 0.155.0 Windows sandbox: explicit read-only profile with legacy sandbox_mode

This is a contract clarification question, not a demonstrated defect or a request to relax protections.

Environment and observed behavior

• Official native Codex CLI 0.155.0 on Windows; elevated sandbox configured.
• Existing relevant user configuration:

sandbox_mode = "read-only"
approval_policy = "on-request"
[windows]
sandbox = "elevated"

• No user-defined permission profiles or default_permissions were found in the inspected configuration. This does not establish absence of built-in profiles or requirements from other configuration layers.
• An earlier invocation without --permission-profile exited 2 with a parser error requiring that argument. The intended whoami command was not verified as executed.
• Installed help describes -P as selecting a named permission profile and --include-managed-config as retaining managed requirements during resolution.

The following is a proposed, unexecuted invocation, with the staging path redacted. It is not a successful reproducer:

codex.exe sandbox -P :read-only --include-managed-config -C "<isolated staging>" -- C:\Windows\System32\whoami.exe /user /fo csv /nh

No model session, build, application runtime, manual firewall change, or protection bypass is intended. The existing configuration has not been edited to try this combination.

Exact clarification requested

1. In 0.155.0, is explicit CLI selection of :read-only accepted when the existing user configuration contains sandbox_mode = "read-only"? What is the exact conflict or precedence rule, including managed requirements and any strict-validation mode applicable to this command?
2. If that configuration is accepted, what filesystem and network permissions result from the built-in profile, after resolution of the specified working directory and managed requirements? Please distinguish command permissions from privileged infrastructure effects.
3. Does the supported sandbox path perform any ACL/account/desktop/provisioning work before command execution in this situation, and what documented conditions trigger it? We need to bound those effects separately from read-only command behavior.
4. Is there a supported way in this version to inspect the effective permissions without dispatching a sandbox command or triggering provisioning? If not, please state that rather than suggesting an undocumented interface.

Version-applicable documentation or a maintainer explanation of the public contract would be sufficient to advance our review. We are not requesting private files, credentials, protection changes, or retrieval through a restricted access route.

Why clarification is needed

The current configuration reference lists built-in permission profiles but warns against combining default_permissions with sandbox_mode. It does not establish how this exact 0.155.0 CLI invocation resolves the existing legacy configuration.

Previously retrieved release-bound debug.rs shows that the explicit profile is added as a default_permissions CLI override before configuration construction. The legacy read-only fallback occurs after that first construction, so it does not by itself establish acceptance or effective permissions. A cached Windows token test verifies an already-constructed read-only profile; it does not test this configuration combination.

The official changelog describes the 0.155.1 change as a local TUI reasoning-summary default fix. We found no documented permission-resolution fix there and are not assuming an upgrade resolves this question.

No project-specific paths, account identities, logs, credentials, or project-internal orchestration records are attached to this request.

Start with the release-bound debug.rs behavior described in the issue, then compare it with the configuration reference and 0.155.0 changelog. Determine whether those sources document the requested precedence, effective permissions, provisioning conditions, and inspection path; done means a version-specific documentation update or maintainer clarification.