Constrain Windows sandbox requirements

[abhinav-oai]

Why

Managed requirements can already constrain sandbox policy choices, but Windows sandbox implementation selection was still resolved independently from those requirements. That left the TUI able to continue through the unelevated fallback even when an organization wants to require the elevated Windows sandbox implementation.

What

• Add [windows].allowed_sandbox_implementations requirements support for the Windows elevated and unelevated implementations.
• Apply that allowlist during core config resolution so disallowed configured or feature-selected Windows sandbox implementations fall back to an allowed implementation with the existing requirements warning path.
• Reuse the existing TUI Windows setup prompts to block disallowed unelevated continuation, keep required elevated setup in front of the user, and refuse to persist a TUI-selected Windows sandbox mode that requirements disallow.

Semantics

Allowed	Selected	Effective
["elevated"]	unelevated / unset	elevated
["unelevated"]	elevated / unset	unelevated
["elevated", "unelevated"]	elevated	elevated
["elevated", "unelevated"]	unelevated	unelevated
["elevated", "unelevated"]	unset	elevated

Availability is handled by interactive setup surfaces after allowlist resolution. If the effective elevated implementation is not ready, elevated-only requirements block on setup. When unelevated is also allowed, the UI may offer the existing unelevated fallback.

TUI Screens

If elevated setup is not already complete:

  Your organization requires the default Codex agent sandbox to continue. Set it up to protect your files and control
  network access.
  Learn more <https://developers.openai.com/codex/windows>

› 1. Set up default sandbox (requires Administrator permissions)
  2. Quit

If admin setup fails under ["elevated"]:

  Couldn't set up your sandbox with Administrator permissions

  Your organization requires the default sandbox before Codex can continue.
  Learn more <https://developers.openai.com/codex/windows>

› 1. Try setting up admin sandbox again
  2. Quit

Next Steps

• extend the requirements/readout surface, such as configRequirements/read, so clients can inspect the loaded [windows].allowed_sandbox_implementations requirement instead of inferring it from Windows setup state
• consider extending windowsSandbox/readiness as well
• update the App startup guide, setup flow, and banner surfaces so an elevated-only requirement omits any continue-unelevated escape hatch and blocks startup until a permitted implementation is ready;
• preserve the existing unelevated fallback path when requirements allow it, including the ["unelevated"] case where elevated is disallowed

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0e6ca07486

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[iceweasel-oai]

nit, this looks like mode = current and requested_mode = new mode, but they are both the requested mode. maybe rename mode to something else

[iceweasel-oai]

lots of setup for this test. non-blocking but maybe consider more of a unit test that just tests the logic, without requiring tokio channels, an analyticseventsclient etc.