Windows Codex app: elevated sandbox cannot recover orphaned SYSTEM-DPAPI credentials (CryptUnprotectData 0x8009000B)

Open 💬 5 comments Opened Jul 28, 2026 by ColeRunsDiagnostics

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

ChatGPT Windows app: 26.721.41059

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 OS revision 26100.8875

What issue are you seeing?

Every Codex task fails before any command process initializes:

execution error: Io(Custom {
  kind: Other,
  error: "windows sandbox: CryptUnprotectData failed: 2148073483"
})
Decimal 2148073483 equals 0x8009000B.
No shell, Git, or filesystem command executes. Even Get-Location,
Get-Date, whoami, and git --version remain unexecuted.



### What steps can reproduce the bug?

Minimal reproduction
1.	Open the Codex Windows app using native Windows sandbox mode.
2.	Use a disposable Git repository:
C:\Temp\CodexTest
3.	Ask Codex to run Get-Location or git --version.
4.	Sandbox initialization fails before process creation with the error above.
The failure reproduces:
•	after multiple Windows restarts;
•	after app reset and reinstall;
•	when launching the app as Administrator;
•	in a disposable repository;
•	under a separate newly created local administrator account;
•	after the unrelated platform outage was resolved;
•	across recent app builds.

<img width="952" height="740" alt="Image" src="https://github.com/user-attachments/assets/d2ca938e-53ec-4bbb-9a1c-d7e11b0a29c5" />
<img width="607" height="572" alt="Image" src="https://github.com/user-attachments/assets/ec2bcbae-b13d-45c4-b6c9-308ae8d09ad3" />

### What is the expected behavior?

Expected behavior
When Codex-specific DPAPI-protected sandbox credentials cannot be decrypted
because their original SYSTEM master key is unavailable, setup should safely
regenerate the Codex-created users and their credential state.
Actual behavior
Sandbox initialization aborts permanently, and app reset, reinstall, elevated
launch, restarts, and a separate Windows account do not recover it.

### Additional information

Correlated Windows DPAPI evidence
Immediately after reproducing the failure, the enabled
Microsoft-Windows-Crypto-DPAPI/Operational log records:
Event 8198
DPAPI Unprotect failed
Status: 0x8009000B
ReasonForFailure: Could not get the master key
Related events at the identical timestamp and ActivityID show:
Security UserID: S-1-5-18
ProcessID: 1224
Process: lsass.exe
MasterKeyGUID: {REDACTED}
A read-only search of:
C:\Windows\System32\Microsoft\Protect\S-1-5-18
shows that the referenced master-key GUID is absent.
The SYSTEM DPAPI store itself is populated with multiple non-zero master-key
files and valid Preferred records, so this does not appear to be a generally
empty or destroyed SYSTEM DPAPI store.
Sandbox-account state
Both documented sandbox users exist and are enabled:
CodexSandboxOffline
PasswordLastSet: 7/25/2026 1:33:47 AM
LastLogon:       7/25/2026 1:38:40 AM

CodexSandboxOnline
PasswordLastSet: 7/25/2026 1:33:47 AM
LastLogon:       none
This indicates setup provisioned both accounts and successfully logged on with
the Offline account once.
Documented log behavior
The documented log:
%USERPROFILE%\.codex\.sandbox\sandbox.log
has not updated since May 15, 2026. Current initialization failures occur before
that log records anything.
Architectural connection
OpenAI’s “Building the Codex Windows Sandbox” article explains that the elevated
sandbox creates CodexSandboxOffline and CodexSandboxOnline, stores their
credentials encrypted with DPAPI, and later decrypts those credentials before
launching codex-command-runner.exe through CreateProcessWithLogonW.
The observed failure appears to occur at that exact boundary:
stored sandbox-user credential
→ SYSTEM CryptUnprotectData
→ referenced master key unavailable
→ command runner never launches
→ sandbox initialization aborts

<img width="713" height="315" alt="Image" src="https://github.com/user-attachments/assets/0c378379-99db-4828-8ce3-696e3477cd24" />
<img width="377" height="217" alt="Image" src="https://github.com/user-attachments/assets/8348d389-266b-4e91-a579-cb1790a38543" />

View original on GitHub ↗

5 Comments

glook9001 · 1 month ago

they are going to their methyos soyboy moment of their own with this snadboxing shit

ColeRunsDiagnostics · 22 days ago

Update (Aug. 5, 2026)

<html>
<body>
<html><head></head><body><h2>Investigation update — two distinct sandbox state failures identified and locally resolved</h2>I have now restored full Windows sandbox operation and can separate this incident into two distinct, sequential failures:<ol start="1"><li>An existing <code>sandbox_users.json</code> contained DPAPI-protected sandbox credentials that could no longer be decrypted.</li><li>After those credentials were deliberately regenerated, sandbox setup progressed further but failed because <code>setup_marker.json</code> was unreadable by the normal invoking Windows user.</li></ol>These were sequential blockers. The marker failure was hidden until the credential-store failure was removed.<h3>Executive assessment</h3>The original <code>CryptUnprotectData failed: 2148073483</code> condition did not disappear merely because an application update was installed.It persisted until I deliberately moved the existing:<pre><code>%USERPROFILE%\.codex\.sandbox-secrets\sandbox_users.json</code></pre>aside and allowed Codex to create a new credential store.Immediately after that regeneration:<ul><li>both offline and online sandbox credential entries existed;</li><li>each password field decoded to a 246-byte DPAPI-protected blob;</li><li>both blobs decrypted successfully under the current Windows user;</li><li>each produced a 24-byte plaintext password;</li><li>the next sandbox attempt no longer failed at <code>CryptUnprotectData</code>;</li><li>execution advanced to a later <code>orchestrator_helper_incomplete</code> / setup-marker failure.</li></ul>The second failure was then isolated to:<pre><code>%USERPROFILE%\.codex\.sandbox\setup_marker.json</code></pre>The current setup helper created this marker and reported successful completion, but the normal Codex process could not read the resulting file. Restoring access for the invoking Windows account made the marker immediately readable and restored sandbox operation.The final recovery was verified through sandbox initialization, a disposable filesystem lifecycle, an application restart, and a real repository write lifecycle with no residual changes.<div><hr></div><h2>Phase 1: isolating the DPAPI credential failure</h2>The original failure occurred before any command process initialized:<pre><code>windows sandbox: CryptUnprotectData failed: 2148073483</code></pre>Decimal <code>2148073483</code> is <code>0x8009000B</code>, <code>NTE_BAD_KEY_STATE</code>.The original issue also documented correlated Windows DPAPI telemetry:<pre><code>Event 8198
DPAPI Unprotect failed
Status: 0x8009000B
ReasonForFailure: Could not get the master key
Security UserID: S-1-5-18
Process: lsass.exe</code></pre>The referenced master-key GUID was absent from:<pre><code>C:\Windows\System32\Microsoft\Protect\S-1-5-18</code></pre>The broader SYSTEM DPAPI store was populated, so the evidence did not indicate a completely empty or destroyed DPAPI store. It instead suggested that the specific protected data referenced a key that was no longer available.<h3>Credential-scope comparison</h3>The two Codex credential systems were tested separately:<pre><code>%USERPROFILE%\.codex\auth.json
%USERPROFILE%\.codex\.sandbox-secrets\sandbox_users.json</code></pre><code>auth.json</code> was readable and was not the failing credential system.The existing <code>sandbox_users.json</code> contained entries for:<pre><code>CodexSandboxOffline
CodexSandboxOnline</code></pre>Both stored password blobs failed DPAPI decryption with “Key not valid for use in specified state.”As a control, an unrelated Chromium DPAPI-protected key belonging to the Codex application profile decrypted successfully under the same Windows account. That was important evidence: DPAPI was not generally nonfunctional for this Windows profile. The failure was isolated to the stored sandbox-password blobs.<h3>Working theory and targeted intervention</h3>The working theory was that the existing sandbox-password blobs had become stale, orphaned, corrupted, or incompatible with the security context in which Codex now attempted to decrypt them.Possible upstream explanations remain:<ul><li>the credentials were protected under a different Windows security context;</li><li>a prior Codex build wrote them using a different DPAPI context or lifecycle;</li><li>a migration retained blobs after the corresponding DPAPI master key became unavailable;</li><li>reinstall/update behavior preserved credentials that should have been invalidated;</li><li>the application lacked an automatic recovery path when <code>CryptUnprotectData</code> returned <code>NTE_BAD_KEY_STATE</code>.</li></ul>Rather than modify DPAPI master keys, local-account password data, the SAM, or <code>auth.json</code>, I performed a narrow and reversible test:<ol start="1"><li>Fully stopped ChatGPT/Codex.</li><li>Moved—not deleted—the existing <code>sandbox_users.json</code> to a timestamped backup.</li><li>Restarted the application.</li><li>Reran elevated Windows sandbox setup.</li><li>Verified that Codex created a new <code>sandbox_users.json</code>.</li><li>Independently tested the new blobs without displaying their protected or plaintext values.</li></ol>The replacement file was created on August 5, 2026 at approximately 12:07 PM:<pre><code>Length: 828 bytes
CreationTime: 8/5/2026 12:07:01 PM
LastWriteTime: 8/5/2026 12:07:01 PM</code></pre>Both new credential entries passed DPAPI decryption:<pre><code>Mode: offline
ProtectedBytes: 246
Result: Decryptable
PlaintextLength: 24

Mode: online
ProtectedBytes: 246
Result: Decryptable
PlaintextLength: 24</code></pre>The very next smoke test advanced past DPAPI and failed later with:<pre><code>windows sandbox: orchestrator_helper_incomplete:
setup helper exited successfully before setup completed</code></pre>It also began reporting:<pre><code>sandbox setup required:
sandbox setup marker missing or incompatible</code></pre>This establishes the observed causal transition:<pre><code>Old sandbox_users.json present
↓
Both protected sandbox-password blobs fail DPAPI decryption
↓
Every sandbox attempt stops at CryptUnprotectData
↓
Old credential file moved aside
↓
Codex generates new offline and online credentials
↓
Both new blobs decrypt successfully
↓
CryptUnprotectData error disappears
↓
Sandbox reaches the subsequent setup-marker failure</code></pre><h3>Release-timeline qualification for the DPAPI finding</h3>The update history matters:<ul><li>The failure was present on the original reported 26.721 application line. The About dialog reported <code>26.721.41059</code>; the installed MSIX package observed during diagnostics was <code>26.721.4979.0</code>.</li><li>The Microsoft Store subsequently delivered <code>26.727.6591.0</code>.</li><li>The old <code>sandbox_users.json</code> still contained two undecryptable blobs after that update. Therefore, <code>26.727.6591.0</code> did not automatically recover the existing broken credential state.</li><li>The credential store was deliberately moved and regenerated while investigating that state.</li><li><code>26.730.8199.0</code> was installed later, after the broken credential file had already been replaced.</li></ul>Accordingly:<ul><li>The evidence supports that deliberate credential regeneration resolved the local DPAPI failure.</li><li>The evidence does not support attributing that recovery to <code>26.727</code>.</li><li>Because <code>26.730</code> was installed after regeneration, this machine cannot determine whether <code>26.730</code> contains code capable of recovering the old blobs; the old broken store was no longer active when that build ran.</li><li>It remains possible that Codex changed credential-generation or migration behavior during this release window. If so, the release still did not provide automatic recovery from an already-present undecryptable <code>sandbox_users.json</code> in the state actually observed.</li></ul>This is the product behavior I believe engineering should investigate: <code>NTE_BAD_KEY_STATE</code> on Codex-owned sandbox credentials currently appears capable of creating a permanent startup failure instead of triggering a safe, narrowly scoped credential regeneration path.<div><hr></div><h2>Phase 2: setup completed, but its marker was unreadable</h2>Once the credential store was regenerated, Codex consistently progressed into elevated sandbox setup.The current helper successfully performed or reported:<ul><li>sandbox-user provisioning;</li><li>WFP configuration;</li><li>installation of 12 WFP filters;</li><li>write-root ACL processing;</li><li>read-ACL processing;</li><li>creation of a version-5 <code>setup_marker.json</code>;</li><li><code>setup binary completed</code>;</li><li>successful helper exit.</li></ul>However, the normal command runner never launched. The next command again reported:<pre><code>sandbox setup marker missing or incompatible</code></pre>followed by:<pre><code>orchestrator_helper_incomplete:
setup helper exited successfully before setup completed</code></pre><h3>Build-integrity verification</h3>At this stage, the installed and active package was:<pre><code>OpenAI.Codex_26.730.8199.0_x64__2p2nqsd0c76g0
Status: Ok</code></pre>Every active ChatGPT/Codex process used the <code>26.730.8199.0</code> package path.The current cached executables matched their package copies by size and SHA-256:
Binary | Size | SHA-256
-- | -- | --
codex.exe | 363,706,672 | FA960EC081BEC3629F40C63ED610EBC49C7E5E077DFB42322B08CB6D460F0B8A
codex-code-mode-host.exe | 56,721,712 | 910159E6F9460103C846D7723A2EF82BED90DE45C582E0E004DC2CE7D10A3C3F
codex-command-runner.exe | 1,302,320 | D2C2E8332EC93CEB048E924A4C728932B3D5AF247B98FE7C9C2DDFC2ADFA33F7
codex-windows-sandbox-setup.exe | 8,808,240 | 43B2658B5AB5D0A886E78CEE0510E605361EB33FBAC7D1F1DC7A195E58E6A944

The older runtime-cache directory contained only <code>rg.exe</code>, not an older <code>codex.exe</code>, command runner, code-mode host, or setup helper.This evidence rules out a mixed package/current-cache explanation for the behavior observed under <code>26.730.8199.0</code>.<h3>File-specific ACL evidence</h3>During a controlled setup attempt at approximately 12:49 PM, the log sequence was:<pre><code>12:49:08.382 codex.exe:
sandbox setup required: sandbox setup marker missing or incompatible

12:49:11.140:
ensuring sandbox users offline=CodexSandboxOffline online=CodexSandboxOnline

12:49:12.007:
WFP setup succeeded for CodexSandboxOffline with 12 installed filters

12:49:12.269:
read-acl-only mode: applying read ACLs

12:49:12.271 codex-windows-sandbox-setup.exe:
setup binary completed

12:49:12.279:
read ACL run completed</code></pre>The helper freshly recreated:<pre><code>%USERPROFILE%\.codex\.sandbox\setup_marker.json</code></pre>Immediately afterward:<ul><li>the file existed;</li><li>its timestamp showed that it had just been rewritten;</li><li><code>Get-Content</code> failed with Access Denied;</li><li><code>Get-Acl</code> failed with <code>UnauthorizedAccessException</code>;</li><li><code>icacls</code> reported Access Denied and processed zero files;</li><li>the normal Codex process classified the marker as “missing or incompatible”;</li><li>no <code>codex-command-runner.exe</code> launch followed.</li></ul>The parent <code>.sandbox</code> directory remained owned by the signed-in user and granted that user Full Control. The access failure was therefore specific to the newly created marker, rather than the parent directory.Because Windows denied even ACL inspection from the normal account, I could not capture a complete pre-repair SDDL for the defective file. I therefore cannot state exactly which ACE was missing or protected. What is established is that the fresh file was unreadable, while its parent was accessible.<h3>Targeted ACL repair</h3>A narrowly scoped elevated repair was applied only to <code>setup_marker.json</code>.Before mutation, the procedure:<ul><li>created a timestamped backup using backup mode;</li><li>preserved the file’s content, ownership, and ACL metadata;</li><li>separately saved the original ACL with <code>icacls /save</code>;</li><li>refused to continue if the backup failed.</li></ul>The repair then granted the invoking account Full Control without changing ownership.Observed result:<pre><code>ROBOCOPY_EXIT=1
ICACLS_SAVE_EXIT=0
INITIAL_GRANT_EXIT=0
OWNER_CHANGED=False
MARKER_READABLE=True
MARKER_VERSION=5
MARKER_LENGTH=255</code></pre>The repaired ACL contained explicit Full Control for the invoking Windows user. Ownership remained:<pre><code>BUILTIN\Administrators</code></pre>Immediately after this one-file ACL repair:<ul><li>Codex accepted the existing marker;</li><li>sandbox initialization succeeded;</li><li>the setup loop stopped;</li><li><code>codex-command-runner.exe</code> launched;</li><li>no further DPAPI error occurred.</li></ul>This establishes the second causal transition:<pre><code>26.730 helper creates/rewrites version-5 marker
↓
Marker exists but normal invoking user cannot read it
↓
Codex reports marker “missing or incompatible”
↓
Setup repeats and orchestrator_helper_incomplete is returned
↓
Explicit access restored on that marker only
↓
Marker becomes readable and remains valid JSON
↓
Codex accepts marker
↓
Command runner launches and sandbox operations succeed</code></pre><div><hr></div><h2>Cross-version and multi-user evidence for the marker ACL issue</h2>The marker behavior is not unique to this machine or newly attributable to <code>26.730</code>.Related public reports include:<ul><li><a href="https://github.com/openai/codex/issues/30445">#30445 — Windows sandbox setup marker ACL prevents Codex from starting sandbox after UAC setup</a>, reported June 28, 2026 on package <code>26.623.5546.0</code>. The reporter found that granting the current user access to <code>setup_marker.json</code> immediately restored sandbox commands.</li><li><a href="https://github.com/openai/codex/issues/35407">#35407 — Windows Desktop 26.721 repeats elevated sandbox setup; marker rewritten but unreadable/rejected</a>, reported July 25, 2026 on package <code>26.721.4979.0</code>. That report captured the same successful-helper/setup-loop behavior and an unreadable freshly rewritten marker.</li><li><a href="https://github.com/openai/codex/issues/23712">#23712 — Windows Desktop repeatedly launches elevated setup helper</a>, reported May 20, 2026 on app version <code>26.513.40821</code>, records the earlier repeated “marker missing or incompatible” setup pattern, although it does not independently prove the marker ACL cause.</li></ul>My reproduction on <code>26.730.8199.0</code> extends the directly evidenced ACL problem across at least:<pre><code>26.623.5546.0
26.721.4979.0
26.730.8199.0</code></pre>Therefore:<ul><li>I do not believe <code>26.730</code> introduced the marker ACL defect.</li><li><code>26.730</code> did not repair it on this machine.</li><li>The evidence instead points to a longer-lived Windows sandbox marker-creation or ACL-inheritance issue that survived multiple releases.</li><li>The setup-loop symptom may extend further back, but only reports that directly tested marker readability should be treated as confirmation of the same root cause.</li></ul>The <code>26.727</code> build produced the setup-marker loop immediately after credential regeneration, but I did not capture the marker’s ACL in that build. The file-specific Access Denied condition was directly proven after the subsequent <code>26.730</code> update. It is therefore reasonable to say the same defect may have been present in <code>26.727</code>, but that specific build-level attribution is not proven by my data.<div><hr></div><h2>Post-repair validation</h2><h3>Disposable filesystem lifecycle</h3>A complete smoke test ran only within:<pre><code>C:\Temp\CodexTest</code></pre>Verified:<ul><li>sandbox initialization;</li><li>file creation;</li><li>exact-content write;</li><li>exact-content readback;</li><li>rename;</li><li>renamed-file verification;</li><li>deletion;</li><li>confirmation that no test artifacts remained;</li><li>no errors or warnings;</li><li>no access or modification outside the disposable directory.</li></ul><h3>Persistence across application restart</h3>After fully restarting the application:<ul><li>the “Try Windows setup again” condition did not return;</li><li>Codex accepted the existing setup state;</li><li>another sandbox task launched normally.</li></ul><h3>Repository lifecycle</h3>A controlled disposable-file test inside a real Git repository verified:<ul><li>initial <code>git status --short</code> recorded;</li><li>disposable file created;</li><li>exact content <code>FSBDL_WRITE_TEST_1</code> confirmed;</li><li>content changed to <code>FSBDL_WRITE_TEST_2</code> and confirmed;</li><li>file renamed;</li><li>file deleted;</li><li>both disposable paths absent afterward;</li><li>final <code>git status --short</code> exactly matched the initial state;</li><li>no existing repository file was modified;</li><li>no elevated filesystem fallback was used.</li></ul>This demonstrates more than UI recovery: the sandbox command runner resumed safe repository operations end to end.<div><hr></div><h2>Confirmed findings, strongest theories, and remaining unknowns</h2><h3>Confirmed</h3><ol start="1"><li>The old offline and online password blobs in <code>sandbox_users.json</code> were not decryptable.</li><li>An unrelated Codex-profile DPAPI key remained decryptable, so DPAPI was not generally broken for the signed-in Windows account.</li><li>Moving the old credential JSON caused Codex to generate a fresh credential store.</li><li>Both new password blobs decrypted successfully.</li><li>The <code>CryptUnprotectData</code> error disappeared immediately after regeneration.</li><li>The next blocker was a freshly created <code>setup_marker.json</code> that the invoking user could not read.</li><li>The <code>26.730</code> package, active processes, and runtime cache were internally consistent.</li><li>Granting the invoking user access to only the marker made Codex accept it.</li><li>Sandbox initialization and command execution then succeeded.</li><li>The repair persisted through application restart and a repository lifecycle test.</li></ol><h3>Strongest supported theory</h3>The incident consisted of two independently recoverable Codex-owned state failures:<ul><li>stale, orphaned, or context-incompatible DPAPI-protected sandbox credentials without an automatic recovery path;</li><li>a setup-marker ACL defect that prevented the normal process from reading state created by the elevated helper.</li></ul><h3>Not established</h3><ol start="1"><li>The exact Codex version or lifecycle event that originally made the old DPAPI blobs unusable.</li><li>Whether the missing SYSTEM master key resulted from a Codex update, failed credential migration, reinstall/reset behavior, Windows state change, or another event.</li><li>Whether <code>26.730</code> contains any DPAPI recovery change; the broken credential file had already been replaced before that build was installed.</li><li>The exact defective pre-repair marker SDDL, because the normal user could not read the file or its ACL.</li><li>Whether every user experiencing <code>CryptUnprotectData</code> has the same credential-file condition.</li><li>Whether every “marker missing or incompatible” report is an ACL defect; some may have other causes.</li></ol><div><hr></div><h2>Engineering recommendations</h2><h3>Credential-store recovery</h3>When decrypting a Codex-owned sandbox password returns <code>0x8009000B</code> or indicates that the required master key is unavailable, setup should not remain permanently blocked.A safe recovery path could:<ol start="1"><li>distinguish sandbox credentials from ChatGPT account authentication;</li><li>preserve or quarantine the unreadable <code>sandbox_users.json</code> for diagnostics;</li><li>regenerate only the Codex-created sandbox-account passwords and protected blobs;</li><li>update the corresponding local sandbox-account passwords;</li><li>verify that both new blobs can be decrypted in the context that will later launch the command runner;</li><li>surface a precise diagnostic if regeneration fails.</li></ol>At minimum, the UI should explain that the sandbox credential store is unreadable and offer a scoped repair. App reset/reinstall did not clear this state in the originally reported condition.<h3>Marker creation and validation</h3>The elevated setup helper should ensure that the normal invoking user can read and validate <code>setup_marker.json</code> after setup completes.Potential safeguards:<ol start="1"><li>explicitly preserve or grant the invoking user SID when creating/replacing the marker;</li><li>validate the final marker using the same unelevated identity/context as the desktop runtime;</li><li>avoid replacing an inheritable file with one carrying a protected ACL that excludes the caller;</li><li>distinguish “file absent,” “invalid schema/version,” and “Access Denied” instead of collapsing all three into “missing or incompatible”;</li><li>do not report helper success until the final marker is readable and accepted by the consuming process.</li></ol>Please consider linking this issue with #30445 and #35407. The matching repair result across multiple users and multiple package generations makes the marker ACL behavior appear product-level rather than machine-specific.<h3>Current status</h3>The sandbox is operational on this machine after:<ol start="1"><li>deliberately regenerating <code>sandbox_users.json</code>; and</li><li>restoring access to <code>setup_marker.json</code>.</li></ol>I am retaining the old credential-store backup, marker backup, saved ACL data, repair transcript, and relevant logs in case engineering wants specific artifacts or a controlled follow-up test.I do not recommend closing the issue solely because the local installation has recovered. Both recovery steps addressed Codex-owned state that the application did not repair automatically, and the marker ACL defect has independent cross-version reports from other users.</body></html>
</body>
</html>## Investigation update — two distinct sandbox state failures identified and locally resolved

I have now restored full Windows sandbox operation and can separate the investigation into two distinct failures:

An existing sandbox_users.json contained DPAPI-protected sandbox credentials that could no longer be decrypted.
After those credentials were deliberately regenerated, sandbox setup progressed further but failed because setup_marker.json was unreadable by the normal invoking Windows user.

These were sequential blockers. The marker failure was hidden until the credential-store failure was removed.

Executive assessment

The original CryptUnprotectData failed: 2148073483 condition did not disappear merely because an application update was installed.

It persisted until I deliberately moved the existing:

%USERPROFILE%\.codex\.sandbox\setup_marker.json

aside and allowed Codex to create a new credential store.

Immediately after that regeneration:

both offline and online sandbox credential entries existed;
each password field decoded to a 246-byte DPAPI-protected blob;
both blobs decrypted successfully under the current Windows user;
each produced a 24-byte plaintext password;
the next sandbox attempt no longer failed at CryptUnprotectData;
execution advanced to a later orchestrator_helper_incomplete / setup-marker failure.

The second failure was then isolated to:

%USERPROFILE%\.codex\.sandbox-secrets\sandbox_users.json

The current setup helper created this marker and reported successful completion, but the normal Codex process could not read the resulting file. Restoring access for the invoking Windows account made the marker immediately readable and restored sandbox operation.

The final recovery was verified through sandbox initialization, a disposable filesystem lifecycle, an application restart, and a real repository write lifecycle with no residual changes.

---

Phase 1: isolating the DPAPI credential failure

The original failure occurred before any command process initialized:

windows sandbox: CryptUnprotectData failed: 2148073483

Decimal 2148073483 is 0x8009000B, NTE_BAD_KEY_STATE.

The original issue also documented correlated Windows DPAPI telemetry:

Event 8198
DPAPI Unprotect failed
Status: 0x8009000B
ReasonForFailure: Could not get the master key
Security UserID: S-1-5-18
Process: lsass.exe

The referenced master-key GUID was absent from:

C:\Windows\System32\Microsoft\Protect\S-1-5-18

The broader SYSTEM DPAPI store was populated, so the evidence did not indicate a completely empty or destroyed DPAPI store. It instead suggested that the specific protected data referenced a key that was no longer available.

Credential-scope comparison

The two Codex credential systems were tested separately:

%USERPROFILE%\.codex\auth.json
%USERPROFILE%\.codex\.sandbox-secrets\sandbox_users.json

auth.json was readable and was not the failing credential system.

The existing sandbox_users.json contained entries for:

CodexSandboxOffline
CodexSandboxOnline

Both stored password blobs failed DPAPI decryption with “Key not valid for use in specified state.”

As a control, an unrelated Chromium DPAPI-protected key belonging to the Codex application profile decrypted successfully under the same Windows account. That was important evidence: DPAPI was not generally nonfunctional for this Windows profile. The failure was isolated to the stored sandbox-password blobs.

Working theory and targeted intervention

The working theory was that the existing sandbox-password blobs had become stale, orphaned, corrupted, or incompatible with the security context in which Codex now attempted to decrypt them.

Possible upstream explanations remain:

the credentials were protected under a different Windows security context;
a prior Codex build wrote them using a different DPAPI context or lifecycle;
a migration retained blobs after the corresponding DPAPI master key became unavailable;
reinstall/update behavior preserved credentials that should have been invalidated;
the application lacked an automatic recovery path when CryptUnprotectData returned NTE_BAD_KEY_STATE.

Rather than modify DPAPI master keys, local-account password data, the SAM, or auth.json, I performed a narrow and reversible test:

Fully stopped ChatGPT/Codex.
Moved—not deleted—the existing sandbox_users.json to a timestamped backup.
Restarted the application.
Reran elevated Windows sandbox setup.
Verified that Codex created a new sandbox_users.json.
Independently tested the new blobs without displaying their protected or plaintext values.

The replacement file was created on August 5, 2026 at approximately 12:07 PM:

Length:        828 bytes
CreationTime:  8/5/2026 12:07:01 PM
LastWriteTime: 8/5/2026 12:07:01 PM

Both new credential entries passed DPAPI decryption:

Mode:            offline
ProtectedBytes:  246
Result:          Decryptable
PlaintextLength: 24

Mode:            online
ProtectedBytes:  246
Result:          Decryptable
PlaintextLength: 24

The very next smoke test advanced past DPAPI and failed later with:

windows sandbox: orchestrator_helper_incomplete:
setup helper exited successfully before setup completed

It also began reporting:

sandbox setup required:
sandbox setup marker missing or incompatible

This establishes the observed causal transition:

Old sandbox_users.json present
    ↓
Both protected sandbox-password blobs fail DPAPI decryption
    ↓
Every sandbox attempt stops at CryptUnprotectData
    ↓
Old credential file moved aside
    ↓
Codex generates new offline and online credentials
    ↓
Both new blobs decrypt successfully
    ↓
CryptUnprotectData error disappears
    ↓
Sandbox reaches the subsequent setup-marker failure

Release-timeline qualification for the DPAPI finding

The update history matters:

The failure was present on the original reported 26.721 application line. The About dialog reported 26.721.41059; the installed MSIX package observed during diagnostics was 26.721.4979.0.
The Microsoft Store subsequently delivered 26.727.6591.0.
The old sandbox_users.json still contained two undecryptable blobs after that update. Therefore, 26.727.6591.0 did not automatically recover the existing broken credential state.
The credential store was deliberately moved and regenerated while investigating that state.
26.730.8199.0 was installed later, after the broken credential file had already been replaced.

Accordingly:

The evidence supports that deliberate credential regeneration resolved the local DPAPI failure.
The evidence does not support attributing that recovery to 26.727.
Because 26.730 was installed after regeneration, this machine cannot determine whether 26.730 contains code capable of recovering the old blobs; the old broken store was no longer active when that build ran.
It remains possible that Codex changed credential-generation or migration behavior during this release window. If so, the release still did not provide automatic recovery from an already-present undecryptable sandbox_users.json in the state actually observed.

This is the product behavior I believe engineering should investigate: NTE_BAD_KEY_STATE on Codex-owned sandbox credentials currently appears capable of creating a permanent startup failure instead of triggering a safe, narrowly scoped credential regeneration path.

---

Phase 2: setup completed, but its marker was unreadable

Once the credential store was regenerated, Codex consistently progressed into elevated sandbox setup.

The current helper successfully performed or reported:

sandbox-user provisioning;
WFP configuration;
installation of 12 WFP filters;
write-root ACL processing;
read-ACL processing;
creation of a version-5 setup_marker.json;
setup binary completed;
successful helper exit.

However, the normal command runner never launched. The next command again reported:

sandbox setup marker missing or incompatible

followed by:

orchestrator_helper_incomplete:
setup helper exited successfully before setup completed

Build-integrity verification

At this stage, the installed and active package was:

OpenAI.Codex_26.730.8199.0_x64__2p2nqsd0c76g0
Status: Ok

Every active ChatGPT/Codex process used the 26.730.8199.0 package path.

The current cached executables matched their package copies by size and SHA-256:

| Binary | Size | SHA-256 |
|---|---:|---|
| codex.exe | 363,706,672 | FA960EC081BEC3629F40C63ED610EBC49C7E5E077DFB42322B08CB6D460F0B8A |
| codex-code-mode-host.exe | 56,721,712 | 910159E6F9460103C846D7723A2EF82BED90DE45C582E0E004DC2CE7D10A3C3F |
| codex-command-runner.exe | 1,302,320 | D2C2E8332EC93CEB048E924A4C728932B3D5AF247B98FE7C9C2DDFC2ADFA33F7 |
| codex-windows-sandbox-setup.exe | 8,808,240 | 43B2658B5AB5D0A886E78CEE0510E605361EB33FBAC7D1F1DC7A195E58E6A944 |

The older runtime-cache directory contained only rg.exe, not an older codex.exe, command runner, code-mode host, or setup helper.

This evidence rules out a mixed package/current-cache explanation for the behavior observed under 26.730.8199.0.

File-specific ACL evidence

During a controlled setup attempt at approximately 12:49 PM, the log sequence was:

12:49:08.382 codex.exe:
sandbox setup required: sandbox setup marker missing or incompatible

12:49:11.140:
ensuring sandbox users offline=CodexSandboxOffline online=CodexSandboxOnline

12:49:12.007:
WFP setup succeeded for CodexSandboxOffline with 12 installed filters

12:49:12.269:
read-acl-only mode: applying read ACLs

12:49:12.271 codex-windows-sandbox-setup.exe:
setup binary completed

12:49:12.279:
read ACL run completed

The helper freshly recreated:

%USERPROFILE%\.codex\.sandbox\setup_marker.json

Immediately afterward:

the file existed;
its timestamp showed that it had just been rewritten;
Get-Content failed with Access Denied;
Get-Acl failed with UnauthorizedAccessException;
icacls reported Access Denied and processed zero files;
the normal Codex process classified the marker as “missing or incompatible”;
no codex-command-runner.exe launch followed.

The parent .sandbox directory remained owned by the signed-in user and granted that user Full Control. The access failure was therefore specific to the newly created marker, rather than the parent directory.

Because Windows denied even ACL inspection from the normal account, I could not capture a complete pre-repair SDDL for the defective file. I therefore cannot state exactly which ACE was missing or protected. What is established is that the fresh file was unreadable, while its parent was accessible.

Targeted ACL repair

A narrowly scoped elevated repair was applied only to setup_marker.json.

Before mutation, the procedure:

created a timestamped backup using backup mode;
preserved the file’s content, ownership, and ACL metadata;
separately saved the original ACL with icacls /save;
refused to continue if the backup failed.

The repair then granted the invoking account Full Control without changing ownership.

Observed result:

ROBOCOPY_EXIT=1
ICACLS_SAVE_EXIT=0
INITIAL_GRANT_EXIT=0
OWNER_CHANGED=False
MARKER_READABLE=True
MARKER_VERSION=5
MARKER_LENGTH=255

The repaired ACL contained explicit Full Control for:

the invoking Windows user

Ownership remained:

BUILTIN\Administrators

Immediately after this one-file ACL repair:

Codex accepted the existing marker;
sandbox initialization succeeded;
the setup loop stopped;
codex-command-runner.exe launched;
no further DPAPI error occurred.

This establishes the second causal transition:

26.730 helper creates/rewrites version-5 marker
    ↓
Marker exists but normal invoking user cannot read it
    ↓
Codex reports marker “missing or incompatible”
    ↓
Setup repeats and orchestrator_helper_incomplete is returned
    ↓
Explicit access restored on that marker only
    ↓
Marker becomes readable and remains valid JSON
    ↓
Codex accepts marker
    ↓
Command runner launches and sandbox operations succeed

---

Cross-version and multi-user evidence for the marker ACL issue

The marker behavior is not unique to this machine or newly attributable to 26.730.

Related public reports include:

[#30445 — Windows sandbox setup marker ACL prevents Codex from starting sandbox after UAC setup](https://github.com/openai/codex/issues/30445), reported June 28, 2026 on package 26.623.5546.0. The reporter found that granting the current user access to setup_marker.json immediately restored sandbox commands.
[#35407 — Windows Desktop 26.721 repeats elevated sandbox setup; marker rewritten but unreadable/rejected](https://github.com/openai/codex/issues/35407), reported July 25, 2026 on package 26.721.4979.0. That report captured the same successful-helper/setup-loop behavior and an unreadable freshly rewritten marker.
[#23712 — Windows Desktop repeatedly launches elevated setup helper](https://github.com/openai/codex/issues/23712), reported May 20, 2026 on app version 26.513.40821, records the earlier repeated “marker missing or incompatible” setup pattern, although it does not independently prove the marker ACL cause.

My reproduction on 26.730.8199.0 extends the directly evidenced ACL problem across at least:

26.623.5546.0
26.721.4979.0
26.730.8199.0

Therefore:

I do not believe 26.730 introduced the marker ACL defect.
26.730 did not repair it on this machine.
The evidence instead points to a longer-lived Windows sandbox marker-creation or ACL-inheritance issue that survived multiple releases.
The setup-loop symptom may extend further back, but only reports that directly tested marker readability should be treated as confirmation of the same root cause.

The 26.727 build produced the setup-marker loop immediately after credential regeneration, but I did not capture the marker’s ACL in that build. The file-specific Access Denied condition was directly proven after the subsequent 26.730 update. It is therefore reasonable to say the same defect may have been present in 26.727, but that specific build-level attribution is not proven by my data.

---

Post-repair validation

Disposable filesystem lifecycle

A complete smoke test ran only within:

C:\Temp\CodexTest

Verified:

sandbox initialization;
file creation;
exact-content write;
exact-content readback;
rename;
renamed-file verification;
deletion;
confirmation that no test artifacts remained;
no errors or warnings;
no access or modification outside the disposable directory.

Persistence across application restart

After fully restarting the application:

the “Try Windows setup again” condition did not return;
Codex accepted the existing setup state;
another sandbox task launched normally.

Repository lifecycle

A controlled disposable-file test inside a real Git repository verified:

initial git status --short recorded;
disposable file created;
exact content FSBDL_WRITE_TEST_1 confirmed;
content changed to FSBDL_WRITE_TEST_2 and confirmed;
file renamed;
file deleted;
both disposable paths absent afterward;
final git status --short exactly matched the initial state;
no existing repository file was modified;
no elevated filesystem fallback was used.

This was the first successful end-to-end repository operation since the original CryptUnprotectData failure began.

This demonstrates more than UI recovery: the sandbox command runner resumed safe repository operations end to end.

---

Confirmed findings, strongest theories, and remaining unknowns

Confirmed

The old offline and online password blobs in sandbox_users.json were not decryptable.
An unrelated Codex-profile DPAPI key remained decryptable, so DPAPI was not generally broken for the signed-in Windows account.
Moving the old credential JSON caused Codex to generate a fresh credential store.
Both new password blobs decrypted successfully.
The CryptUnprotectData error disappeared immediately after regeneration.
The next blocker was a freshly created setup_marker.json that the invoking user could not read.
The 26.730 package, active processes, and runtime cache were internally consistent.
Granting the invoking user access to only the marker made Codex accept it.
Sandbox initialization and command execution then succeeded.
The repair persisted through application restart and a repository lifecycle test.

Strongest supported theory

The incident consisted of two independently recoverable Codex-owned state failures:

stale, orphaned, or context-incompatible DPAPI-protected sandbox credentials without an automatic recovery path;
a setup-marker ACL defect that prevented the normal process from reading state created by the elevated helper.

Not established

The exact Codex version or lifecycle event that originally made the old DPAPI blobs unusable.
Whether the missing SYSTEM master key resulted from a Codex update, failed credential migration, reinstall/reset behavior, Windows state change, or another event.
Whether 26.730 contains any DPAPI recovery change; the broken credential file had already been replaced before that build was installed.
The exact defective pre-repair marker SDDL, because the normal user could not read the file or its ACL.
Whether every user experiencing CryptUnprotectData has the same credential-file condition.
Whether every “marker missing or incompatible” report is an ACL defect; some may have other causes.

---

Engineering recommendations

Credential-store recovery

When decrypting a Codex-owned sandbox password returns 0x8009000B or indicates that the required master key is unavailable, setup should not remain permanently blocked.

A safe recovery path could:

distinguish sandbox credentials from ChatGPT account authentication;
preserve or quarantine the unreadable sandbox_users.json for diagnostics;
regenerate only the Codex-created sandbox-account passwords and protected blobs;
update the corresponding local sandbox-account passwords;
verify that both new blobs can be decrypted in the context that will later launch the command runner;
surface a precise diagnostic if regeneration fails.

At minimum, the UI should explain that the sandbox credential store is unreadable and offer a scoped repair. App reset/reinstall did not clear this state in the originally reported condition.

Marker creation and validation

The elevated setup helper should ensure that the normal invoking user can read and validate setup_marker.json after setup completes.

Potential safeguards:

explicitly preserve or grant the invoking user SID when creating/replacing the marker;
validate the final marker using the same unelevated identity/context as the desktop runtime;
avoid replacing an inheritable file with one carrying a protected ACL that excludes the caller;
distinguish “file absent,” “invalid schema/version,” and “Access Denied” instead of collapsing all three into “missing or incompatible”;
do not report helper success until the final marker is readable and accepted by the consuming process.

Please consider linking this issue with #30445 and #35407. The matching repair result across multiple users and multiple package generations makes the marker ACL behavior appear product-level rather than machine-specific.

Current status

The sandbox is operational on this machine after:

deliberately regenerating sandbox_users.json; and
restoring access to setup_marker.json.

I am retaining the old credential-store backup, marker backup, saved ACL data, repair transcript, and relevant logs in case engineering wants specific artifacts or a controlled follow-up test.

I do not recommend closing the issue solely because the local installation has recovered. Both recovery steps addressed Codex-owned state that the application did not repair automatically, and the marker ACL defect has independent cross-version reports from other users.

wlhjkl · 20 days ago

I can confirm this failure independently on Codex Desktop for Windows today.

Observed error on every local process launch:

CryptUnprotectData failed: 2148073483
0x8009000B

Additional reproduction evidence from this session:

The primary task cannot launch even cmd /c echo tool-ok; failure occurs before process creation.
Existing subagents/workers fail at the same boundary.
A newly forked same-directory Codex task receives a fresh task id but its normal sandbox still fails identically.
apply_patch, shell execution, skill-file reads, and the Node REPL MCP all fail because they ultimately hit the same Windows sandbox credential initialization.
Fully terminating all Codex Desktop processes and reopening the app did not recover the credential state.
No repository command or project file operation is reached, so this is not a workspace permission or command-content issue.

This has a severe production impact: a long-running engineering task becomes completely unusable, and the only partial escape is requesting non-sandbox execution, which forces additional approval prompts. Recent Desktop updates have added more approval friction while this core Windows sandbox reliability problem remains unresolved. From a user perspective, frequent feature updates are not helpful when basic local execution can be permanently disabled and routine work requires repeated/batch approvals. The experience is extremely frustrating and not suitable for sustained professional development.

Requested fixes:

Add an in-app, auditable “Repair/Recreate Windows sandbox credentials” action that safely regenerates Codex-created sandbox users and DPAPI-protected credentials without requiring OS sign-out or profile deletion.
Detect 0x8009000B explicitly and present a deterministic recovery flow instead of repeatedly retrying every tool call.
Ensure a new/forked task can provision fresh sandbox credentials rather than inheriting the same broken state.
Improve approval ergonomics: allow scoped batch approval for a governed task/workspace, while preserving clear command/path boundaries, instead of requiring repeated prompts for the same recovery workflow.
Preserve task history and local work during repair.

No source code, customer data, device identifiers, or project-specific paths are included in this report.

takon-gi · 16 days ago

I am the reporter of duplicate issue #36052 and can confirm the same failure on another Windows environment.

The issue is still reproducible as of August 12, 2026:

Normal sandboxed commands fail before PowerShell starts with:

windows sandbox: CryptUnprotectData failed: 2148073483

apply_patch and the browser-control runtime can fail with the same error.
In my environment the failure is intermittent rather than permanently continuous. Restarting Codex may temporarily restore normal execution, but the error later returns.
Approved/out-of-sandbox execution can sometimes succeed while ordinary sandboxed execution continues to fail.
The problem has reproduced across different workspace locations and does not appear related to Japanese file or directory names.

Original duplicate report: #36052

QuentinScDS · 10 days ago

And today