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
- Launch Codex Desktop normally.
- The app displays "Finish Windows setup".
- Click "Try Windows setup again".
- No actual Windows UAC dialog appears.
- The app returns "Windows setup didn't finish".
- 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:
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?
-
Launch Codex Desktop normally on Windows.
-
The app shows the "Finish Windows setup" screen.
-
Click "Try Windows setup again".
-
No real Windows UAC prompt appears.
-
After a short delay, Codex shows:
"Windows setup didn't finish"
-
Repeat the setup attempt.
The same result occurs every time.
-
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.
-
If I switch Codex to:
[windows]
sandbox = "unelevated"
and run:
whoami
the command fails with:
"Access is denied."
-
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
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 finishNo 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
OpenAI.Codex26.803.10989.0OkC:\Program Files\WindowsApps\OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0codex-command-runner-0.147.0-alpha.6.6.exeSteps to reproduce
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/Adminshows successful Desktop AppX container creation forOpenAI.Codex, without corresponding activation errors.Example:
Created Desktop AppX container ... for package OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0Package status:
OpenAI.Codex 26.803.10989.0 OkUAC verification
UAC works normally outside this setup flow.
Therefore this does not appear to be a globally disabled or broken UAC configuration.
Sandbox accounts
Both sandbox users exist and are enabled:
CodexSandboxOffline-1003CodexSandboxOnline-1004However:
Get-CimInstance Win32_UserProfile | Where-Object LocalPath -match 'CodexSandbox'returns no profiles.
There are also no corresponding ProfileList registry entries for either sandbox SID:
.bakProfileList keyNo relevant errors were emitted by
Microsoft-Windows-User Profiles Serviceduring 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.jsonContents are valid:
{ "principals": {} }File length: 22 bytes
NUL-byte check:
NUL bytes: 0 / 22Therefore 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 completedread-acl-only mode: applying read ACLsread ACL run completedHowever, 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.exeExample timestamps from 2026-08-11:
08:36:5308:37:0508:37:08all report the same
SetFileAttributesW ... error 5.This looks similar to the
C:\Users\Defaultbehavior discussed in #35737, although my AppX package remainsStatus: Ok.AppX status
I checked:
Get-AppxPackage OpenAI.Codex | Select-Object Name, Version, Status, InstallLocationResult:
OpenAI.Codex 26.803.10989.0 OkSo the package is not currently
ModifiedorNeedsRemediation.Unelevated sandbox test
I also tested:
Codex started in this mode, but even the simplest command:
whoamifailed with:
Access is denied.So
unelevatedis not a working workaround on this machine.I reverted to the normal/elevated configuration afterward.
Troubleshooting already attempted
Oksetup_marker.jsondeny_read_acl_state.jsonsandbox = "unelevated"Win32_UserProfileProfileListI have intentionally NOT modified ACLs/ownership on
C:\Users\Defaultbecause 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:
deny_read_acl_state.jsoncausing setup loopsetup_marker.jsonACL issueSetFileAttributesWAccess Denied onC:\Users\DefaultThe important difference in my environment is:
deny_read_acl_state.jsonis validsetup_marker.jsonis valid and readableOkQuestion
Could this be a regression in the Windows sandbox setup/runner in Codex Desktop
26.803.10989.0/ runner0.147.0-alpha.6.6?I can provide additional sandbox logs or Windows Event Viewer output if needed.
What steps can reproduce the bug?
Launch Codex Desktop normally on Windows.
The app shows the "Finish Windows setup" screen.
Click "Try Windows setup again".
No real Windows UAC prompt appears.
After a short delay, Codex shows:
"Windows setup didn't finish"
Repeat the setup attempt.
The same result occurs every time.
UAC itself works normally outside this flow:
If I switch Codex to:
[windows]
sandbox = "unelevated"
and run:
whoami
the command fails with:
"Access is denied."
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
whoamiwithout returning "Access is denied".The Windows setup screen should not appear again after a successful setup.
Additional information
Additional diagnostics:
Sandbox accounts exist and are enabled:
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:
deny_read_acl_state.json is valid:
Therefore the corrupted/NUL-filled deny_read_acl_state.json issue does not appear to apply.
Older sandbox logs show successful setup stages:
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
whoamifails 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