Skip to content

[Windows] "Finish Windows setup" loops with no UAC prompt; sandbox runner gets Access Denied on C:\Users\Default #37940

Description

@artofcharly

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

26.803.10989.0

What subscription do you have?

Business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop on Windows is stuck on the "Finish Windows setup" screen.

Clicking "Try Windows setup again" immediately returns:

Windows setup didn't finish

No real UAC prompt appears from this setup flow.

UAC itself is working normally on the machine. For example, launching Command Prompt or Codex with "Run as administrator" correctly triggers the Windows UAC prompt.

I performed extensive diagnostics and could not find a broken AppX package, corrupted sandbox state file, unreadable setup marker, or broken UAC configuration.

The current sandbox runner repeatedly logs:

hide users: failed to hide current user profile dir (C:\Users\Default): SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied.)

Environment

  • OS: Windows
  • Architecture: x64
  • Codex Desktop package: OpenAI.Codex
  • Codex Desktop version: 26.803.10989.0
  • Package status: Ok
  • Install location:
    C:\Program Files\WindowsApps\OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
  • PowerShell tested with: 7.6.4
  • Current sandbox runner observed in log:
    codex-command-runner-0.147.0-alpha.6.6.exe

Steps to reproduce

  1. Launch Codex Desktop normally.
  2. The app displays "Finish Windows setup".
  3. Click "Try Windows setup again".
  4. No actual Windows UAC dialog appears.
  5. The app returns "Windows setup didn't finish".
  6. Repeating the process produces the same result.

Expected behavior

The setup helper should request elevation if required, finish Windows sandbox setup, and allow Codex to execute sandboxed commands.

Actual behavior

Windows setup never completes.

The AppX application itself launches normally.

Microsoft-Windows-AppModel-Runtime/Admin shows successful Desktop AppX container creation for OpenAI.Codex, without corresponding activation errors.

Example:

Created Desktop AppX container ... for package OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0

Package status:

OpenAI.Codex 26.803.10989.0 Ok

UAC verification

UAC works normally outside this setup flow.

  • Command Prompt -> Run as administrator -> UAC prompt appears normally.
  • Codex -> Run as administrator -> UAC prompt appears normally.

Therefore this does not appear to be a globally disabled or broken UAC configuration.

Sandbox accounts

Both sandbox users exist and are enabled:

CodexSandboxOffline

  • Enabled: True
  • LastLogon: 2026-08-08 09:03:44
  • SID ends in -1003

CodexSandboxOnline

  • Enabled: True
  • LastLogon: empty
  • SID ends in -1004

However:

Get-CimInstance Win32_UserProfile | Where-Object LocalPath -match 'CodexSandbox'

returns no profiles.

There are also no corresponding ProfileList registry entries for either sandbox SID:

  • no main ProfileList key
  • no .bak ProfileList key

No relevant errors were emitted by Microsoft-Windows-User Profiles Service during the failed sandbox execution test.

setup_marker.json

The sandbox marker exists and is readable.

Contents:

{
  "version": 5,
  "offline_username": "CodexSandboxOffline",
  "online_username": "CodexSandboxOnline",
  "created_at": "2026-07-29T10:46:09.962168200+00:00",
  "proxy_ports": [],
  "allow_local_binding": false,
  "read_roots": [],
  "write_roots": []
}

ACL verification shows the current Windows user has Full Control:

NT AUTHORITY\SYSTEM:(F)
BUILTIN\Administrators:(F)
CHARLYPC\Admin:(F)

The marker can be read successfully with Get-Content.

Therefore the setup-marker ACL issue described in #30445 does not appear to apply here.

deny_read_acl_state.json

I also checked:

.codex\.sandbox\deny_read_acl_state.json

Contents are valid:

{
  "principals": {}
}

File length: 22 bytes

NUL-byte check:

NUL bytes: 0 / 22

Therefore this does not appear to be the NUL-filled state corruption described in #35718.

Deleting/regenerating this state file did not fix the problem.

Sandbox logs

Older sandbox setup attempts successfully reached:

setup refresh: processed 4 write roots (read roots delegated); errors=[]

setup binary completed

read-acl-only mode: applying read ACLs

read ACL run completed

However, the runner repeatedly logs:

hide users: failed to hide current user profile dir (C:\Users\Default): SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied.)

The same error is present with the newer runner:

codex-command-runner-0.147.0-alpha.6.6.exe

Example timestamps from 2026-08-11:

08:36:53
08:37:05
08:37:08

all report the same SetFileAttributesW ... error 5.

This looks similar to the C:\Users\Default behavior discussed in #35737, although my AppX package remains Status: Ok.

AppX status

I checked:

Get-AppxPackage OpenAI.Codex | Select-Object Name, Version, Status, InstallLocation

Result:

OpenAI.Codex 26.803.10989.0 Ok

So the package is not currently Modified or NeedsRemediation.

Unelevated sandbox test

I also tested:

[windows]
sandbox = "unelevated"

Codex started in this mode, but even the simplest command:

whoami

failed with:

Access is denied.

So unelevated is not a working workaround on this machine.

I reverted to the normal/elevated configuration afterward.

Troubleshooting already attempted

  • Restarted Windows
  • Reset the Codex/ChatGPT Windows app
  • Reinstalled/restarted the application
  • Verified UAC works normally
  • Verified AppX package status is Ok
  • Verified AppX container creation
  • Verified sandbox users exist and are enabled
  • Verified setup_marker.json
  • Verified marker ACL
  • Verified deny_read_acl_state.json
  • Verified state file contains zero NUL bytes
  • Removed/regenerated sandbox state files
  • Tested sandbox = "unelevated"
  • Checked Win32_UserProfile
  • Checked ProfileList
  • Checked User Profiles Service events
  • Checked current sandbox logs

I have intentionally NOT modified ACLs/ownership on C:\Users\Default because it is a Windows system profile directory and changing its security configuration does not seem like a safe workaround.

Related issues

This appears related to, but not identical to:

The important difference in my environment is:

  • deny_read_acl_state.json is valid
  • setup_marker.json is valid and readable
  • marker ACL includes my user with Full Control
  • AppX package status remains Ok
  • UAC works normally
  • yet Windows setup still cannot complete and sandbox execution still fails

Question

Could this be a regression in the Windows sandbox setup/runner in Codex Desktop 26.803.10989.0 / runner 0.147.0-alpha.6.6?

I can provide additional sandbox logs or Windows Event Viewer output if needed.

What steps can reproduce the bug?

  1. Launch Codex Desktop normally on Windows.

  2. The app shows the "Finish Windows setup" screen.

  3. Click "Try Windows setup again".

  4. No real Windows UAC prompt appears.

  5. After a short delay, Codex shows:
    "Windows setup didn't finish"

  6. Repeat the setup attempt.
    The same result occurs every time.

  7. UAC itself works normally outside this flow:

    • "Run as administrator" for Command Prompt shows the UAC prompt.
    • "Run as administrator" for Codex also shows the UAC prompt.
  8. If I switch Codex to:
    [windows]
    sandbox = "unelevated"

    and run:
    whoami

    the command fails with:
    "Access is denied."

  9. The current sandbox runner log repeatedly contains:
    hide users: failed to hide current user profile dir (C:\Users\Default):
    SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied.)

Expected:
Windows setup should request elevation if needed and complete successfully.

Actual:
The setup loops forever with "Windows setup didn't finish", while sandbox execution also fails.

What is the expected behavior?

When I click "Try Windows setup again", Codex should trigger the Windows UAC elevation prompt, complete the required Windows sandbox setup, and proceed to the application normally.

After setup is completed, Codex should be able to execute sandboxed commands such as whoami without returning "Access is denied".

The Windows setup screen should not appear again after a successful setup.

Additional information

Additional diagnostics:

  • Codex Desktop version: 26.803.10989.0
  • AppX package status: Ok
  • UAC works normally outside the Codex setup flow.
  • "Run as administrator" for both Command Prompt and Codex correctly triggers UAC.
  • Microsoft-Windows-AppModel-Runtime/Admin shows successful creation of the Codex Desktop AppX container without activation errors.

Sandbox accounts exist and are enabled:

  • CodexSandboxOffline - Enabled: True, LastLogon: 2026-08-08 09:03:44
  • CodexSandboxOnline - Enabled: True, LastLogon: empty

No CodexSandbox profiles are returned by Win32_UserProfile.
No ProfileList registry entries (including .bak entries) exist for either sandbox SID.
No relevant Microsoft-Windows-User Profiles Service errors are logged during the failure.

The sandbox setup marker exists and is readable:

  • setup_marker.json version: 5
  • ACL includes SYSTEM, Administrators, and my Windows user with Full Control.

deny_read_acl_state.json is valid:

  • {"principals": {}}
  • File size: 22 bytes
  • NUL bytes: 0

Therefore the corrupted/NUL-filled deny_read_acl_state.json issue does not appear to apply.

Older sandbox logs show successful setup stages:

  • "processed 4 write roots (read roots delegated); errors=[]"
  • "setup binary completed"
  • "read ACL run completed"

However, the current runner (0.147.0-alpha.6.6) repeatedly logs:

hide users: failed to hide current user profile dir (C:\Users\Default): SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied.)

I also tested:

[windows]
sandbox = "unelevated"

In this mode even whoami fails with "Access is denied", so unelevated mode is not a working workaround.

I intentionally did NOT modify ownership or ACLs of C:\Users\Default, ProfileList, sandbox users, or Windows security policies.

Related issues that appear similar:
#32492
#30445
#35718
#35737

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions