[Windows] Elevated sandbox fails with `CreateProcessWithLogonW failed: 1168` when the Codex sandbox profile has a broken `ProfileList` / `.bak` state

Open 💬 1 comment Opened Jul 14, 2026 by stonedreamforest

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 no ProfileImagePath.
  • ProfileList\<SID>.bak existed and contained ProfileImagePath=C:\Users\CodexSandboxOffline.
  • Win32_UserProfile returned two records for the same SID; one had Status=8 (corrupted), and neither was loaded.
  • The referenced profile directory did not exist.
  • User Profile Service emitted events 1500, 1501, 1515, and 1544, 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:

  1. Exported both registry keys:
  • ProfileList\<SID>
  • ProfileList\<SID>.bak
  1. Removed only those two keys.
  2. Kept the local account, SID, password state, and group membership unchanged.
  3. 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.

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 .bak key 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:

  1. Detect an invalid profile state such as:
  • main SID key exists but lacks ProfileImagePath;
  • a sibling .bak key exists;
  • the profile is marked corrupted and is not loaded.
  1. Emit a specific actionable diagnostic instead of only:

``text
CreateProcessWithLogonW failed: 1168
``

  1. 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:

  1. Add a sandbox-profile health check after provisioning and before runner launch for both CodexSandboxOffline and CodexSandboxOnline.
  2. Resolve the user SID and inspect the profile state using supported Userenv / profile APIs where possible.
  3. 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.
  1. On failure, log a redacted health summary:
  • account exists / enabled;
  • profile key exists;
  • ProfileImagePath exists;
  • .bak conflict exists;
  • loaded / corrupted status;
  • User Profile Service event IDs if available.
  1. Add regression coverage for profile-state classification, including the exact main key missing ProfileImagePath + .bak key present state.

Likely source areas:

  • codex-rs/windows-sandbox-rs/src/sandbox_users.rs
  • codex-rs/windows-sandbox-rs/src/identity.rs
  • codex-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

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗