Windows elevated sandbox re-provisioning fails on previously locked .sandbox-bin ACL after upgrade

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

26.915.3509.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Feedback Session ID: 01a0b2b4-8970-7c40-9bce-1afa23215a09

Summary

Codex Windows elevated sandbox setup failed after an application upgrade because re-provisioning attempted to modify an existing .sandbox-bin directory whose ACL had previously been locked by Codex itself.

The failure was:

helper_sandbox_lock_failed

SetNamedSecurityInfoW sandbox dir failed: 5

Windows error 5 = Access Denied.

After investigation and remediation, I confirmed that this is not a general failure of using Codex from a standard Windows user account with UAC elevation through a separate Administrator account.

The same standard-user / separate-administrator security model works correctly when the sandbox generated state starts clean.

The issue appears to be an upgrade/reconfiguration idempotency problem against previously locked generated sandbox ACL state.

---

Environment

• Codex App version: 26.915.3509.0
• Windows 11 x64
• Windows build: 26200
• Interactive Windows account: standard user
• Separate local Administrator account used for UAC credential elevation
• Codex configuration:

[windows] sandbox = "elevated"

The interactive user remains a standard user and is not a member of BUILTIN\Administrators.

---

Initial failure

After the Codex upgrade, sandbox setup was triggered again because the previous setup marker was reported as missing or incompatible.

The elevated setup proceeded partially successfully:

• sandbox accounts were created;
• WFP / firewall setup succeeded;
• approximately 12 filters were created;
• UAC administrative elevation therefore completed successfully.

Setup then failed while attempting to secure the existing .sandbox-bin directory:

helper_sandbox_lock_failed

SetNamedSecurityInfoW sandbox dir failed: 5

The affected generated directory was:

C:\Users\<USER>\.codex\.sandbox-bin

At the time of failure, its relevant security state was:

• owner: interactive standard user;
• inheritance: disabled / protected;
• interactive standard user could modify the ACL;
• BUILTIN\Administrators had Modify, Synchronize;
• BUILTIN\Administrators did not have ChangePermissions / WRITE_DAC.

Because UAC elevation was performed using a separate Administrator account, the elevated helper did not have sufficient permission to rewrite the DACL of this already-locked directory.

No Windows error 1385 was observed, so this did not appear to be a sandbox-account logon-right issue.

---

Investigation result

The original hypothesis was that Windows standard-user → separate-administrator credential elevation itself might be incompatible with the elevated sandbox setup.

That hypothesis was disproved.

I performed a clean-state remediation without changing the long-term Windows account security model and without manually patching the sandbox ACL.

Remediation procedure

1. Fully stopped Codex.
2. Preserved the existing sandbox evidence.
3. Renamed the existing generated directory to:

.sandbox-bin.pre-20260918

4. Did not perform a broad ACL reset.
5. Did not change directory ownership.
6. Did not grant Full Control.
7. Did not add the standard user to Administrators.
8. Did not access or modify .sandbox-secrets.
9. Created a fresh empty .sandbox-bin directory with normal initial ACL inheritance.
10. Reran elevated sandbox setup using the same:

• standard interactive user;
• separate Administrator account for UAC elevation.

The setup then completed successfully.

---

Successful post-remediation state

The repaired environment now passes elevated sandbox setup.

Observed result:

• setup marker v5 created successfully;
• provisioning binary completed;
• WFP setup completed successfully;
• final WFP state contains 12 filters;
• subsequent setup refreshes report errors=[];
• no new SetNamedSecurityInfoW ... error 5;
• no new helper_sandbox_lock_failed;
• sandbox service runs normally;
• one Offline and one Online sandbox account are present;
• temporary setup scheduled tasks cleaned themselves up successfully;
• Codex App works normally after restart;
• sandbox commands run successfully as CodexSandboxOffline;
• workspace reading works;
• workspace ACL grants CodexSandboxUsers Modify.

The interactive user still remains a standard Windows user.

No manual ACL patch was required.

---

Key root-cause observation

After successful clean provisioning, Codex once again locks the newly generated .sandbox-bin directory into essentially the same ACL state:

• owner: interactive standard user;
• inheritance: disabled / protected;
• BUILTIN\Administrators: Modify, Synchronize;
• no ChangePermissions / WRITE_DAC.

This means a successful setup recreates the ACL condition that caused the next upgrade-time re-provisioning to fail.

This strongly suggests the underlying problem is:

Codex Windows sandbox upgrade/re-provisioning is not idempotent against generated sandbox state previously locked by Codex itself.

A later version or setup-marker migration may attempt to provision the existing directory again, but the elevated helper running under a separate Administrator account can no longer rewrite its security descriptor because WRITE_DAC is absent.

The resulting failure is then:

helper_sandbox_lock_failed

SetNamedSecurityInfoW sandbox dir failed: 5

---

Additional recovery behavior observed

There was another relevant behavior during remediation.

Renaming the old .sandbox-bin was not sufficient by itself.

When .sandbox-bin was completely absent, the current Codex version first failed while attempting to open the missing directory.

Codex did not automatically recreate it.

Creating a new empty .sandbox-bin directory allowed provisioning to proceed successfully.

So the recovery/re-provisioning path appears to make two conflicting assumptions:

1. .sandbox-bin already exists;
2. the elevated helper can modify its security descriptor.

This makes recovery from stale or incompatible generated sandbox state fragile.

---

Expected behavior

When an upgrade or setup-marker migration requires Windows sandbox re-provisioning, Codex should safely handle generated state created by an older Codex version.

Ideally the setup process should be idempotent and support at least one of the following:

• detect that the existing generated ACL is incompatible and safely recreate the generated directory;
• temporarily obtain or arrange the ACL rights required for re-provisioning;
• recreate generated sandbox state rather than attempting to mutate an ACL it previously locked;
• automatically create .sandbox-bin when it is missing;
• provide an explicit recovery action instead of leaving setup partially provisioned.

A standard Windows configuration where:

• the developer uses a standard account; and
• administrative operations are approved using a separate Administrator account

should remain supported across Codex upgrades.

This account model works correctly after clean provisioning.

---

Actual behavior

Upgrade-triggered re-provisioning against the existing Codex-generated sandbox state failed with Access Denied.

The setup had already created privileged sandbox resources and WFP rules before failing at the directory security stage.

A manual clean generated-state rebuild was required to recover.

---

Current assessment

Root cause classification:

Upgrade stale / non-idempotent generated ACL state

Not:

General incompatibility with standard-user → separate-administrator UAC elevation

The relevant sequence appears to be:

successful Codex sandbox setup
→ Codex locks .sandbox-bin
→ Administrators no longer have WRITE_DAC
→ later Codex upgrade requires re-provisioning
→ elevated helper attempts to modify the existing DACL
→ SetNamedSecurityInfoW returns error 5
→ elevated sandbox setup fails.

---

Remaining risk

The environment is currently fully operational, but the final successful setup has again removed WRITE_DAC from BUILTIN\Administrators.

Therefore a future Codex upgrade that requires another provisioning pass against the existing locked .sandbox-bin may reproduce the same failure.

No further local workaround is currently required, but the generated-state lifecycle appears capable of recreating the precondition for this bug.

---

Diagnostic evidence

I am attaching a sanitized sandbox log corresponding to the failed setup attempt.

The attachment has been sanitized as follows:

• Windows username redacted;
• machine name redacted;
• local user paths redacted;
• sandbox/local SID redacted;
• diagnostic event ordering preserved;
• sandbox setup events preserved.

The available sanitized log did not itself contain the Codex version or Windows build, so those values are provided explicitly in this report.

setup_error.json was observed during the failure but is transient and was removed by the Codex sandbox setup lifecycle before the sanitized submission package was generated.

The historical error recorded in that file was:

helper_sandbox_lock_failed

SetNamedSecurityInfoW sandbox dir failed: 5

I did not recreate or fabricate the missing file.

.sandbox-secrets was not accessed, read, modified, or attached.

---

Attached file

sandbox-36f753f1b0bc1d09.sanitized.log

Additional remediation evidence has been preserved locally and can be provided if required.

What steps can reproduce the bug?

1. Use Codex App on Windows from a standard Windows user account.

2. Configure:
   [windows] sandbox = "elevated"

3. Approve UAC elevation using credentials for a separate local Administrator account.

4. Successfully complete elevated sandbox provisioning once.

5. After provisioning, .sandbox-bin is left with:

   • owner = standard interactive user
   • inheritance disabled/protected
   • BUILTIN\Administrators = Modify, Synchronize
   • no WRITE_DAC / Change permissions

6. Upgrade Codex, or otherwise trigger sandbox re-provisioning because the setup marker is missing/incompatible.

7. Allow elevated setup to run again using the same Administrator account.

8. Sandbox account / WFP setup proceeds, but setup fails while securing the existing .sandbox-bin with:

   helper_sandbox_lock_failed
SetNamedSecurityInfoW sandbox dir failed: 5

Recovery observation:

• Renaming the old .sandbox-bin and creating a fresh empty .sandbox-bin allows provisioning to succeed.
• No manual ACL patch, ownership change, or administrator-membership change is required.

What is the expected behavior?

Sandbox re-provisioning after a Codex upgrade should be idempotent against sandbox state created and locked by a previous successful Codex setup.

If the existing generated .sandbox-bin ACL is incompatible with re-provisioning, Codex should safely recreate or migrate that generated state rather than failing with Access Denied.

The setup path should also recreate .sandbox-bin automatically if the generated directory is missing.

Additional information

Codex Feedback Session ID:
01a0b2b4-8970-7c40-9bce-1afa23215a09

Clean-state remediation result:

• PASS
• interactive account remained a standard user
• sandbox mode remained elevated
• no broad ACL reset
• no ownership change
• no manual ACL patch
• no addition of the user to Administrators

After clean provisioning, Codex again leaves .sandbox-bin protected with BUILTIN\Administrators lacking WRITE_DAC, so a future upgrade requiring re-provisioning may recreate the same failure condition.

I have a sanitized failure log:
sandbox-36f753f1b0bc1d09.sanitized.log

The log has Windows username, machine name, local paths, and SID values redacted. .sandbox-secrets was not accessed or included.

setup_error.json was transient and disappeared before the sanitized submission package was generated.

sandbox-36f753f1b0bc1d09.sanitized.log

Start with the attached sandbox-36f753f1b0bc1d09.sanitized.log and trace the elevated sandbox provisioning path around helper_sandbox_lock_failed and SetNamedSecurityInfoW. Compare clean provisioning with upgrade re-provisioning; done means existing locked .sandbox-bin state can be handled idempotently and a missing generated directory is recreated without Access Denied.