[Windows] Elevated sandbox fails with `CreateProcessWithLogonW failed: 1168` when the Codex sandbox profile has a broken `ProfileList` / `.bak` state
What version of Codex is running?
codex-cli 0.144.0-alpha.4, bundled with the VS Code extension openai.chatgpt-26.707.41301-win32-x64.
Platform
- Windows 11 x64
- Native Windows elevated sandbox
- VS Code extension
- PowerShell 7.6.3
Summary
The elevated Windows sandbox consistently failed before launching even cmd.exe:
windows sandbox failed: CreateProcessWithLogonW failed: 1168
The unelevated sandbox worked. The elevated sandbox account existed, was enabled, had valid group membership, and authenticated successfully. The actual failure was caused by a corrupted Windows user-profile registration for CodexSandboxOffline:
ProfileList\<SID>existed but had noProfileImagePath.ProfileList\<SID>.bakexisted and containedProfileImagePath=C:\Users\CodexSandboxOffline.Win32_UserProfilereturned two records for the same SID; one hadStatus=8(corrupted), and neither was loaded.- The referenced profile directory did not exist.
- User Profile Service emitted events
1500,1501,1515, and1544, with “Element not found”.
Backing up and removing only those two broken ProfileList keys allowed Windows to recreate the profile on the next sandbox launch. The same elevated sandbox test then succeeded with exit code 0.
Reproduction / diagnosis
The Codex executable below is the one bundled with the VS Code extension, not the helper-cache copy under .codex\.sandbox-bin.
$cmd = Join-Path $env:WINDIR 'System32\cmd.exe'
& $codex `
-c 'windows.sandbox="unelevated"' `
sandbox -- `
$cmd /d /c echo CODEX_UNELEVATED_OK
# Result: success, exit code 0
& $codex `
-c 'windows.sandbox="elevated"' `
sandbox -- `
$cmd /d /c echo CODEX_ELEVATED_OK
# Result:
# windows sandbox failed: CreateProcessWithLogonW failed: 1168
# exit code 1
Disabling the private desktop did not change the result:
& $codex `
-c 'windows.sandbox="elevated"' `
-c 'windows.sandbox_private_desktop=false' `
sandbox -- `
$cmd /d /c echo CODEX_ELEVATED_DEFAULT_DESKTOP_OK
Account and authentication state
Both sandbox accounts existed and were enabled. Both were members of CodexSandboxUsers.
Security events around the failed launch showed:
4648: explicit credentials for CodexSandboxOffline
4624: successful logon
LogonType: 2
LogonProcess: seclogo
AuthenticationPackage: Negotiate
4634: immediate logoff
This excluded missing accounts, bad credentials, disabled accounts, and logon-right failures.
User Profile Service evidence
Immediately after the failed launch, the Application log contained:
1500: Windows cannot log you on because your profile cannot be loaded.
Detail: Element not found.
1501: Windows cannot create a temporary profile directory.
Detail: Element not found.
1515: Windows has backed up this user profile.
1544: Windows cannot back up the ProfileList entry because a backup entry already exists.
Registry and WMI state
For the SID of CodexSandboxOffline:
ProfileList\<SID>
exists: true
ProfileImagePath: missing
State: present
ProfileList\<SID>.bak
exists: true
ProfileImagePath: C:\Users\CodexSandboxOffline
State: present
Win32_UserProfile returned two entries for the same SID:
LocalPath: C:\Users\CodexSandboxOffline
Loaded: false
Status: 8
LocalPath: <empty>
Loaded: false
Status: 0
The directory C:\Users\CodexSandboxOffline did not exist.
Recovery that worked
With all Codex / VS Code processes closed and the profile unloaded:
- Exported both registry keys:
ProfileList\<SID>ProfileList\<SID>.bak
- Removed only those two keys.
- Kept the local account, SID, password state, and group membership unchanged.
- Re-ran the elevated sandbox command.
Result:
CODEX_ELEVATED_OK
exit code 0
Windows recreated a valid main key. Immediately after the first successful launch it reported:
ProfileImagePath: C:\Users\CodexSandboxOffline
State: 516
A subsequent healthy diagnostic reported the normalized state:
ProfileImagePath: C:\Users\CodexSandboxOffline
State: 0
Backup .bak entry: absent
Win32_UserProfile Status: 0
The CreateProcessWithLogonW 1168 error disappeared.
Diagnostic and guarded recovery script
A community diagnostic kit is provided with this report so other affected users can classify the failure before changing Windows profile state.
- Attachment: CodexSandbox1168-DiagnosticKit.zip
- ZIP SHA-256:
55439f698240d63c443ea401fd1c3007b42c60e41e3713c8c97f54e96851646b
The script is read-only by default:
Unblock-File -LiteralPath .\CodexSandbox1168-DiagnoseRepair.ps1
pwsh -NoProfile -File .\CodexSandbox1168-DiagnoseRepair.ps1
A healthy result looks like:
Unelevated: exit=0, success=True
Elevated: exit=0, success=True
Diagnosis: Elevated sandbox is healthy.
Repair mode must be run from elevated PowerShell 7 and is deliberately gated. It proceeds only when all of the following are true:
- unelevated execution succeeds;
- elevated execution fails with
CreateProcessWithLogonW failed: 1168; - the sandbox account exists, is enabled, and has the expected group membership;
- the main SID key exists but lacks
ProfileImagePath; - a sibling
.bakkey exists and contains a profile path; - no profile record for the SID is loaded;
- corrupt-profile or matching User Profile Service evidence is present;
- every candidate profile path is inside the Windows profiles directory and belongs to the Codex sandbox account.
pwsh -NoProfile -File .\CodexSandbox1168-DiagnoseRepair.ps1 -Repair
Before making changes, repair mode exports the affected registry keys, renames an existing profile directory instead of deleting it, requires explicit REBUILD confirmation, and reruns the elevated sandbox test afterward.
This script is a community troubleshooting aid, not an official OpenAI utility. Users should review it before running it and should not use -Repair for a generic error 1168 unless the script identifies the exact repairable signature.
Expected behavior
Codex should not remain permanently broken when a Codex-owned sandbox profile enters this recoverable Windows state.
At minimum, setup / refresh / runner startup should:
- Detect an invalid profile state such as:
- main SID key exists but lacks
ProfileImagePath; - a sibling
.bakkey exists; - the profile is marked corrupted and is not loaded.
- Emit a specific actionable diagnostic instead of only:
``text``
CreateProcessWithLogonW failed: 1168
- Preferably self-heal the Codex-owned profile when it is safe to do so, while preserving the sandbox account SID and credentials.
Suggested implementation direction
The current setup path ensures that the local users, passwords, and CodexSandboxUsers membership exist, but the observed failure was in Windows profile state rather than account state.
A possible fix:
- Add a sandbox-profile health check after provisioning and before runner launch for both
CodexSandboxOfflineandCodexSandboxOnline. - Resolve the user SID and inspect the profile state using supported Userenv / profile APIs where possible.
- If the profile is unloaded and belongs to a Codex-managed sandbox account:
- recreate a missing profile;
- or remove and recreate a confirmed corrupted profile using supported APIs such as
DeleteProfileW/CreateProfile; - avoid directly editing arbitrary user profiles.
- On failure, log a redacted health summary:
- account exists / enabled;
- profile key exists;
ProfileImagePathexists;.bakconflict exists;- loaded / corrupted status;
- User Profile Service event IDs if available.
- Add regression coverage for profile-state classification, including the exact
main key missing ProfileImagePath + .bak key presentstate.
Likely source areas:
codex-rs/windows-sandbox-rs/src/sandbox_users.rscodex-rs/windows-sandbox-rs/src/identity.rscodex-rs/windows-sandbox-rs/src/elevated_impl.rs- runner transport / Windows process-launch code
Related issues
- #17458 — sandbox users exist but profiles are not initialized until first logon
- #21455 — temporary-profile leakage / User Profile Service interaction
This report is related to both, but the observed failure mode is distinct: a previously created Codex sandbox account had a corrupted ProfileList main/.bak state that deterministically caused CreateProcessWithLogonW failed: 1168 and was recoverable by rebuilding only the Codex-owned profile registration.
Additional information
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗