Windows setup loop — "Couldn't check Windows setup" / "Windows setup didn't finish", sandbox-setup.exe crashes silently on elevation #42264

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Sep 2, 2026
2. github-actions commented on Sep 2, 2026

   

   github-actionsbot

   on Sep 2, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Windows sandbox provisioning fails with helper_unknown_error: setup refresh had errors #41715
   • Windows sandbox provisioning fails with helper_unknown_error after setup refresh #41755
   • Windows desktop chat-agent local helper fails with "setup refresh had errors" #41603

   Powered by Codex Action
3. keithdelk commented on Sep 3, 2026

   

   keithdelk

   on Sep 3, 2026

   More actions

   Experiencing the same problem.

   Windows 11. ChatGPT/Codex Windows app stuck on “Couldn't check Windows setup.” Uninstalled/reinstalled app and rebooted. Existing %USERPROFILE%.codex.sandbox\setup_marker.json was valid version 5 and my account had Full Control. Backed up .codex, renamed the old setup marker to force reprovisioning, relaunched app but setup still returns to “Couldn't check Windows setup.”
4. M07Amp commented on Sep 4, 2026

   

   M07Amp

   on Sep 4, 2026 – with ChatGPT Codex Connector

   More actions

   I encountered this same failure on Windows 11 after the ChatGPT/Codex desktop app attempted to update on September 3, 2026.

   Observed behavior:

   • App became stuck in the “Complete Windows setup” / “Windows setup didn’t finish” loop.
   • Retrying setup did not resolve it.
   • “Continue with limited access” had no effect and simply returned to the same loop.
   • The failure persisted after rebooting/reinstalling and into the following day.
   • This occurred during deadline-critical professional work and effectively made the Codex desktop environment unavailable.

   A workaround that successfully recovered the application was to completely close ChatGPT/Codex and rename the user’s .codex directory rather than delete it:

   Get-Process ChatGPT -ErrorAction SilentlyContinue | Stop-Process -Force
   
   $src = "$env:USERPROFILE\.codex"
   $dst = "$env:USERPROFILE\.codex-backup-20260904"
   
   if (Test-Path $src) {
       Rename-Item $src $dst
   }

   After launching ChatGPT/Codex again, the Windows setup completed successfully and the application opened normally.

   Important data-loss/UI issue:

   Because Codex started with a new .codex directory, all prior projects initially appeared to be missing. The underlying project/session data was still present in the renamed backup directory, but an ordinary user could reasonably conclude that their projects had been lost.

   We recovered the projects safely without restoring the entire prior .codex state, which could potentially reintroduce the setup failure.

   With Codex closed, the following durable data was restored from the backup into the newly created .codex directory:

   • sessions
   • archived_sessions
   • session_index.jsonl
   • .codex-global-state.json

   We deliberately did not restore the old runtime/configuration/database state such as config.toml, auth.json, state_5.sqlite, and other potentially corrupted setup state.

   After restarting Codex, the projects and their prior conversations were restored successfully and the application remained operational.

   Suggested product improvements:

   1. The setup screen should never leave the application in an unrecoverable loop where both Retry and Limited Access fail.
   2. Codex should detect corrupt/incompatible local configuration and offer a safe “rebuild application state while preserving projects and sessions” recovery option.
   3. Project/session data should be clearly separated from disposable runtime/setup state.
   4. Reset/reinstall/update procedures should never make locally stored projects appear lost without an explicit warning and recovery path.
   5. The workaround of rebuilding .codex while preserving project/session files should be documented until the underlying defect is corrected.
   6. Given that Codex is used for production development work, update failures should fail safely into the prior working version rather than blocking access to the environment.

   This was not merely an inconvenience. In my case, the failure occurred while I had deadline-sensitive project deliverables due that day. Had the backup directory been deleted rather than renamed during troubleshooting, the consequences could have been substantially worse.
5. M07Amp commented on Sep 4, 2026

   

   M07Amp

   on Sep 4, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up with a more specific finding after recovering the app and isolating the configuration involved. Project/client details are anonymized below.

   I had one project using a reusable least-privilege permission model structured like this:

   # User-level ~/.codex/config.toml
   [permissions.shared_matter_base]
   description = "Reusable least-privilege base for matter workspaces"
   extends = ":workspace"
   
   [permissions.shared_matter_base.filesystem]
   ":root" = "deny"
   ":minimal" = "read"

   The project itself had a local .codex/config.toml similar to:

   default_permissions = "project_matter"
   
   [permissions.project_matter]
   description = "Project-specific AI workspace permissions"
   extends = "shared_matter_base"
   
   [permissions.project_matter.filesystem]
   # project-specific read/write/deny paths followed here

   The recovery sequence produced a strong A/B indication that the user-level custom permission profile was involved in the Windows setup loop:

   1. With the original ~/.codex present, the Windows app remained stuck in the "Windows setup didn't finish" loop.

   2. Renaming the entire ~/.codex directory allowed Windows setup to complete and the app to launch.

   3. Restoring project/session/global-state data, while leaving the old user-level config.toml out, still allowed the app to launch.

   4. New tasks in the affected project then failed with an error equivalent to:

      failed to resolve feature override precedence: permissions profile 'project_matter' extends undefined profile 'shared_matter_base'

   5. Restoring only the missing shared_matter_base definition to the new user-level ~/.codex/config.toml caused the Windows setup loop to return immediately.

   6. Rolling that user-level profile back out allowed the app to launch again.

   7. I then changed the project-local profile to inherit directly from Codex's built-in :workspace profile and copied the two baseline restrictions into the project-local profile:

   default_permissions = "project_matter"
   
   [permissions.project_matter]
   extends = ":workspace"
   
   [permissions.project_matter.filesystem]
   ":root" = "deny"
   ":minimal" = "read"
   
   # existing project-specific read/write/deny paths remain here

   With that change, the Windows app launches normally and new tasks in the project work again.

   So the project itself does not appear to be the underlying cause. The more specific trigger appears to be the presence/handling of a user-defined global permission profile in the upgraded Windows app, particularly where a project-local profile inherits from that global custom profile. I would still characterize this as a strong observed causal sequence rather than a definitive source-level diagnosis.

   This also reveals a recovery hazard: rebuilding ~/.codex can make the desktop app usable again while silently breaking project-local permission profiles that inherit from user-level custom profiles. Users may not discover that second failure until they try to create a new task.

   For now, the safer configuration pattern appears to be self-contained project-local profiles that inherit only from built-in profiles such as :workspace, with organization/project baseline restrictions copied into the local profile rather than inherited from a user-level custom profile.

   Suggested regression tests:

   • Windows desktop setup/update with a valid custom [permissions.<id>] profile in ~/.codex/config.toml that extends :workspace.
   • A project-local .codex/config.toml whose selected profile extends that user-level custom profile.
   • Recovery/reprovisioning of Windows setup while preserving project-local configs and sessions.

   This was the first project on this machine configured with this shared-base/project-child permissions pattern, which helped isolate the behavior.
6. cosmicjj commented on Oct 3, 2026

   

   cosmicjj

   on Oct 3, 2026

   More actions

   I encountered a similar Windows setup loop on Codex desktop 26.930.3930.0 / CLI 0.160.0, running Windows 10 build 19045.

   CLI doctor reported provisioning complete, but the desktop app-server’s windowsSandbox/readiness returned updateRequired. The sandbox service was Running/Automatic.

   A separate app-server session using the desktop-selected cached executable called windowsSandbox/setupStart with mode=elevated. It completed successfully. Fresh readiness checks then returned ready, an elevated sandbox command passed, and the desktop issue was resolved.

   No registry receipts were manually created, and no reinstall or package ownership changes were needed.

   The attached sanitized report includes the provisioning request, verification results, and relevant log messages. We established a recovery path, but not why earlier setup attempts through the desktop UI failed. Could comparing those execution contexts help narrow this down?

   codex-sandbox-public-report.txt