Add Windows sandbox provisioning setup command by iceweasel-oai · Pull Request #24831 · openai/codex

iceweasel-oai · 2026-05-27T22:56:17Z

Why

Some Windows users do not have local admin access, so they cannot complete the elevated portion of the Windows sandbox setup when Codex first needs it. This adds an alpha provisioning path that an admin or IT deployment script can run ahead of time for the Codex user.

The intended managed-deployment shape is:

codex sandbox setup --elevated --user "$env:COMPUTERNAME\Alice" --codex-home "C:\Users\Alice\.codex"

--elevated is treated as the requested sandbox setup level, not as proof that the process is elevated. The Windows sandbox setup orchestration still checks that the caller is actually elevated before launching the helper without a UAC prompt.

What changed

Added codex sandbox setup --elevated with explicit user selection via either --current-user or --user ... --codex-home ....
Moved the CLI implementation into cli/src/sandbox_setup.rs instead of growing cli/src/main.rs.
Added a Windows sandbox ProvisionOnly helper mode that runs the elevation-required provisioning work without requiring a workspace cwd or runtime sandbox policy.
Reused the existing elevated helper path for creating/updating sandbox users, configuring firewall/WFP rules, and applying sandbox directory ACLs.
Persisted windows.sandbox = "elevated" into the target CODEX_HOME so the desktop app does not show the initial sandbox setup banner after pre-provisioning succeeds.

Validation

cargo fmt -p codex-windows-sandbox -p codex-core -p codex-cli
cargo test -p codex-cli sandbox_setup --target-dir target\sandbox-setup-check
cargo test -p codex-windows-sandbox payload_accepts_provision_only_mode --target-dir target\sandbox-setup-check
git diff --check
Manual Windows alpha flow with a standard local user (Mandi Lavida): ran the new setup command from an admin shell, verified the target .codex contents, sandbox marker/secrets, ACLs, firewall rules, and desktop startup without the sandbox setup banner once experimental network proxy requirements were disabled.

Notes

This intentionally does not solve later elevated update coordination for IT-managed deployments. The setup command can still apply provisioning updates when run again, but a broader coordination/process story is out of scope for this alpha.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7b76531a2d

ℹ️ 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".

chatgpt-codex-connector · 2026-05-28T17:41:09Z

+        proxy_ports: Vec::new(),
+        allow_local_binding: false,


Preserve proxy settings during provisioning

When the managed setup is run for a user whose later Codex session uses an enforced loopback proxy (for example via HTTP_PROXY/HTTPS_PROXY or CODEX_NETWORK_ALLOW_LOCAL_BINDING), this always writes a marker/firewall setup with no proxy ports and allow_local_binding=false. require_logon_sandbox_creds compares that marker against the user's actual proxy settings and treats the difference as setup drift, so it calls the elevated setup path again; for the non-admin users this command is meant to support, that reintroduces the UAC/elevation requirement on first launch instead of using the pre-provisioned sandbox.

Useful? React with 👍 / 👎.

this is a known limitation of the alpha. proxy changes will require future IT intervention.

chatgpt-codex-connector · 2026-05-28T17:41:09Z

+    ConfigEditsBuilder::new(identity.codex_home.as_path())
+        .set_windows_sandbox_mode("elevated")
+        .apply()


Clear legacy sandbox keys when provisioning

If the target CODEX_HOME already contains any legacy Windows sandbox feature key (for example from a previous opt-in/opt-out), resolve_windows_sandbox_mode gives those keys precedence or ignores [windows].sandbox, while this command only writes the new key. The normal setup path calls clear_legacy_windows_sandbox_keys() before persisting the mode, so managed provisioning can report success but leave the desktop/TUI still seeing the old legacy setting and prompting or running with the wrong sandbox mode.

Useful? React with 👍 / 👎.

these users won't have legacy keys. I decided to skip this for simplicity

iceweasel-oai · 2026-05-28T17:42:08Z

@@ -543,31 +552,178 @@ fn run_read_acl_only(payload: &Payload, log: &mut dyn Write) -> Result<()> {
    Ok(())
 }

-fn run_setup_full(payload: &Payload, log: &mut dyn Write, sbx_dir: &Path) -> Result<()> {
+fn provision_and_hide_sandbox_users(


these next 4 functions are not new. I just moved them out into helpers so that they can easily be called from the new sandbox setup command

canvrno-oai · 2026-05-28T19:49:21Z

I had Codex perform a supervised end-to-end test of this feature on Windows. The clean-home flow worked: both setup forms completed, created the expected sandbox artifacts, and persisted [windows] sandbox = "elevated".

I also tested a target CODEX_HOME that already had an active profile with its own Windows sandbox setting, for example:

profile = "work"

[profiles.work.windows]
sandbox = "unelevated"

In that case, codex sandbox setup --elevated ... still reported success and added the top-level elevated setting, but Codex continued to honor the active profile’s unelevated setting and ran as the real user instead of the elevated sandbox account. The same happened with a legacy sandbox feature key under the active profile.

I'm not sure if this is worth addressing now or in the future, but I wanted to raise this finding.

iceweasel-oai marked this pull request as ready for review May 28, 2026 17:37

iceweasel-oai requested a review from a team as a code owner May 28, 2026 17:37

chatgpt-codex-connector Bot reviewed May 28, 2026

View reviewed changes

iceweasel-oai commented May 28, 2026

View reviewed changes

canvrno-oai approved these changes May 28, 2026

View reviewed changes

Add Windows sandbox provisioning setup command

7e49fc5

iceweasel-oai force-pushed the codex/windows-sandbox-provisioning-setup branch from 7b76531 to 7e49fc5 Compare May 28, 2026 20:26

Fix sandbox setup clippy on non-Windows

fdadb50

iceweasel-oai enabled auto-merge (squash) May 28, 2026 20:50

dylan-hurd-oai approved these changes May 29, 2026

View reviewed changes

iceweasel-oai merged commit cb9178e into main May 29, 2026
31 checks passed

iceweasel-oai deleted the codex/windows-sandbox-provisioning-setup branch May 29, 2026 18:01

github-actions Bot locked and limited conversation to collaborators May 29, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Windows sandbox provisioning setup command#24831

Add Windows sandbox provisioning setup command#24831
iceweasel-oai merged 2 commits into
mainfrom
codex/windows-sandbox-provisioning-setup

iceweasel-oai commented May 27, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 28, 2026

Uh oh!

iceweasel-oai May 28, 2026

Uh oh!

chatgpt-codex-connector Bot May 28, 2026

Uh oh!

iceweasel-oai May 28, 2026

Uh oh!

iceweasel-oai May 28, 2026

Uh oh!

canvrno-oai commented May 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

iceweasel-oai commented May 27, 2026

Why

What changed

Validation

Notes

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 28, 2026

Choose a reason for hiding this comment

Uh oh!

iceweasel-oai May 28, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot May 28, 2026

Choose a reason for hiding this comment

Uh oh!

iceweasel-oai May 28, 2026

Choose a reason for hiding this comment

Uh oh!

iceweasel-oai May 28, 2026

Choose a reason for hiding this comment

Uh oh!

canvrno-oai commented May 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants