Managed Windows sandbox requirement emits misleading warning on macOS

What version of Codex CLI is running?

codex-cli 0.142.5

What subscription do you have?

ChatGPT Enterprise in an organization-managed workspace.

Which model were you using?

Not applicable. The warning appears during CLI startup/configuration resolution, before model use.

What platform is your computer?

macOS on a MacBook Pro. Exact uname -mprs output is not yet available.

What terminal emulator and version are you using (if applicable)?

Codex CLI is run directly from a terminal on macOS. The exact terminal emulator/version was not provided.

Codex doctor report

Not provided.

What issue are you seeing?

When an enterprise-managed requirements.toml contains a Windows sandbox implementation allowlist, Codex CLI validates that Windows-only requirement on macOS and emits a misleading startup warning:

Configured value for `windows.sandbox` is disallowed by requirements; falling back to required value Some(Unelevated). Details: invalid value for `windows.sandbox`: `None` is not in the allowed set [Unelevated] (set by enterprise-managed requirements)

There is no local [windows] configuration on the Mac. None is the natural configured value because the host is macOS.

The warning does not appear to change the sandbox used for command execution: get_platform_sandbox() still selects MacosSeatbelt on macOS. The problem is the cross-platform validation and misleading Windows fallback warning.

This causes users and administrators to think that a Windows sandbox is being applied on macOS, or that the macOS sandbox is misconfigured.

What steps can reproduce the bug?

1. Use Codex CLI 0.142.5 on macOS.
2. Do not configure a local [windows] section, so the configured Windows sandbox mode is None.
3. Apply an enterprise-managed requirements policy containing:

``toml
[windows]
allowed_sandbox_implementations = ["unelevated"]
``

1. Start Codex CLI.
2. Observe the windows.sandbox warning shown above.

Source review shows the deterministic path:

• ConfigRequirements converts the Windows allowlist into a constraint that rejects None:

codex-rs/config/src/config_requirements.rs (windows_sandbox_mode, around lines 1399-1430 on current main).

• Core config resolution calls apply_requirement_constrained_value("windows.sandbox", ...) without a target_os = "windows" guard:

codex-rs/core/src/config/mod.rs (around lines 3063-3078 on current main).

• Actual sandbox selection is platform-aware and returns MacosSeatbelt on macOS:

codex-rs/sandboxing/src/manager.rs (get_platform_sandbox).

The behavior was introduced by commit a5a94ee5a7447d2c0a846dbc97c2a469c115a598 / PR #23766, whose stated purpose and setup flows are Windows-specific.

What is the expected behavior?

On non-Windows hosts, [windows].allowed_sandbox_implementations should not produce a configured-value fallback warning.

Codex should either:

1. skip applying the Windows sandbox constraint when target_os != "windows"; or
2. keep the Windows requirement available for policy/readout purposes but suppress fallback selection and warnings on non-Windows hosts.

The existing Windows behavior should remain unchanged, and macOS command execution should continue to use Seatbelt.

Additional information

This appears to be a warning/config-resolution bug rather than a sandbox escape or sandbox enforcement failure.

Existing tests confirm that the Windows constraint rejects None, but there does not appear to be coverage for a non-Windows host receiving a managed policy with a [windows] section.

Current workarounds are:

• assign separate managed policies to Windows and macOS groups, omitting [windows] from the macOS policy; or
• temporarily configure [windows] sandbox = "unelevated" on the Mac to satisfy the allowlist, even though that setting is irrelevant to macOS execution.

The second workaround suppresses the warning but is confusing and should not be necessary.