Windows app stuck on "Finish Windows setup" — sandbox setup never triggers a real UAC prompt, "Retry" fails instantly

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

Unknown — the app is blocked on the "Finish Windows setup" screen and I cannot reach the About dialog.

What subscription do you have?

Plus

What platform is your computer?

"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"

What issue are you seeing?

On first launch the Windows app is stuck on the "Finish Windows setup" screen ("ChatGPT necesita un permiso por única vez para funcionar en tu computadora"). It always shows "La instalación de Windows no se completó", and clicking "Reintentar la configuración de Windows" fails instantly. No real Windows UAC prompt ever appears when clicking Retry — the UAC dialog shown on that screen is only an illustration, and no actual elevation request is triggered. The setup gate blocks before the app is usable at all.

What steps can reproduce the bug?

Install the ChatGPT/Codex desktop app from the Microsoft Store on Windows 11 Pro.
Launch the app.
It shows "Finish Windows setup" requesting a one-time permission.
Click "Reintentar la configuración de Windows" — it fails immediately with "La instalación de Windows no se completó". No real UAC prompt appears.

Already verified/attempted, none resolves it:

CPU virtualization: enabled (confirmed in Task Manager)
VirtualMachinePlatform and Containers-DisposableClientVM features: both enabled, rebooted
Local Administrator account; "Run as administrator" → same error
UAC at default level; AppInfo service running
Clean reinstall from Microsoft Store → same error
Reset %USERPROFILE%.codex → same error
"Continuar con acceso limitado" also fails
Added [windows] sandbox = "wsl" to config.toml → no effect (setup gate blocks before it's read)

Workaround: Codex CLI inside WSL2 works fine, which points to the native Windows sandbox setup step being the broken component. Looks related to issues #26737 and #26883.

What is the expected behavior?

The app should complete the one-time Windows setup and open normally.

Additional information

No response

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

Windows setup fails before the UAC prompt, and both setup options are non-functional #32149
cannot finish Windows setup to continue #32248
Codex starts and wants more permissions. It hangs and doesn't allow me to move further. Codex is a bricked. #32255

Powered by Codex Action

I deleted my .codex/config.toml and restarted the app and it fixed it

I am seeing the same issue on Windows 11 with a ChatGPT Pro account.

Symptoms:

The app is stuck on Finish Windows setup.
Clicking Try Windows setup again does not trigger a real Windows UAC prompt.
The app reports that Windows setup did not finish.
Continue with limited access does not provide a stable workaround; the app may briefly show the main Codex screen and then return to the same setup loop.

Troubleshooting already attempted without success:

Reset the app and restarted Windows.
Uninstalled and reinstalled the app multiple times, including a fresh reinstall again today.
Confirmed that %USERPROFILE%\.codex\config.toml contained [windows] sandbox = "unelevated".
Tried the setup button repeatedly; no actual UAC dialog appears.

The same behavior persists after today’s reinstall. This appears to be the same native Windows sandbox/onboarding failure described in this issue, not a one-time installation problem.

Additional detail from another affected Windows user: after a fresh reinstall, %USERPROFILE%\.codex\config.toml does not exist, so the workaround of deleting or renaming config.toml is not applicable. The app still loops on “Finish Windows setup”; clicking Retry does not trigger a real UAC prompt.

Additional reproduction detail from my Windows 11 / ChatGPT Pro installation:

I renamed %USERPROFILE%\.codex\config.toml so the app would start without the existing user configuration.
On the next launch, the app temporarily passed the Finish Windows setup gate and displayed the main ChatGPT Work/Codex home screen.
It then automatically attempted to download/install a ChatGPT update.
The update failed with the dialog: “Unable to install the ChatGPT update. Try checking for updates again.”
This machine previously also returned Microsoft Store / winget source connectivity errors (WinHttpSendRequest: 12029, 0x80072efd).

So disabling config.toml changes the failure mode but does not yet produce a stable working installation. Screenshot available if needed.

I found another confirmed root cause that can produce this exact desktop symptom.

The ChatGPT/Codex Windows app was stuck on Finish Windows setup and clicking Retry/UAC did not recover it. Repair, restart, running as administrator, and changing [windows].sandbox did not help.

The actual problem was a malformed %USERPROFILE%\.codex\config.toml. Two project table headers containing non-ASCII/Chinese folder names were missing the closing single quote, for example:

# Invalid
[projects.'D:\codeX\Example项目]

# Valid
[projects.'D:\codeX\Example项目']

The desktop app surfaced this as a Windows setup failure instead of reporting the TOML parse error.

A safe diagnostic was:

npx @openai/codex resume

The CLI reported the exact location:

Error loading config.toml:
...config.toml:87:31: unclosed table, expected `] `

After backing up config.toml and correcting only the malformed project table headers, the Windows desktop app opened normally again with all projects intact.

Suggested troubleshooting before reinstalling or resetting data:

Back up %USERPROFILE%\.codex\config.toml.
Run npx @openai/codex resume (or another CLI command) to force config parsing and obtain an exact line number.
Check every [projects.'...'] header, especially paths with non-ASCII characters, for a missing closing quote/bracket.
Fix only the malformed lines; do not rename/delete the whole .codex directory.

It would be helpful if Desktop displayed the underlying config.toml parse error instead of routing users to the Windows sandbox setup screen.

I've discovered another critical root cause for the "Finish Windows setup" hang (where the UAC prompt never triggers) that is related to authentication rather than Windows privileges or system features.

The Underlying Issue

If your user session has expired or the OAuth refresh token has been revoked, the desktop app fails to fetch the cloud configuration bundle (cloudConfigBundle) during startup:

failed to load configuration: Your access token could not be refreshed because your refresh token was revoked. Please log out and sign in again.

This causes the backend windowsSandbox/setupStart call to fail with a 401 Unauthorized / Auth error. Instead of displaying a prompt to log out and log in again, the Desktop UI incorrectly routes this error to the "Finish Windows setup" gate, making it appear as a permissions/sandbox setup failure.

The Fix / Workaround

To break the loop and force the app to show the login screen:

Close the ChatGPT/Codex Desktop application completely.
Open File Explorer and navigate to your user profile directory: %USERPROFILE%\.codex (usually C:\Users\<username>\.codex).
Locate the file named auth.json.
Rename auth.json to auth.json.bak (or delete it).
Relaunch the ChatGPT/Codex app.

The app will now detect that no login session exists, skip the sandboxing gate, and successfully route you to the Sign In screen. Once you log back in, a fresh OAuth session will be established, and the app will open normally.

CODEX FIX.zip

Root cause found: invalid config.toml key, not UAC (Windows 11, app 26.727.x)

Same symptom: stuck on "Finish Windows setup", no real UAC prompt, Retry fails instantly. Tried the usual things (reinstall, run as admin, config reset) — no luck.

The desktop app silently falls back to default config when config.toml fails to parse. One legacy key in the [agents] block is rejected by the current schema:

[agents]
approvals_reviewer = "user"   # expects a struct now

App log shows:

Invalid configuration; using defaults.
config.toml:7:1: invalid type: string "user", expected struct AgentRoleToml

One bad key → whole file rejected → app runs on defaults → the config-load failure gets surfaced as the "Windows setup not completed" gate (no UAC, instant failure). Removing the key and restarting fixed it immediately.

this took days to track down.

Root cause found: invalid config.toml key, not UAC (Windows 11, app 26.727.x)

Same symptom: stuck on "Finish Windows setup", no real UAC prompt, Retry fails instantly. Tried the usual things (reinstall, run as admin, config reset) — no luck.

The desktop app silently falls back to default config when config.toml fails to parse. One legacy key in the [agents] block is rejected by the current schema:

[agents]
approvals_reviewer = "user" # expects a struct now
App log shows:
Invalid configuration; using defaults.
config.toml:7:1: invalid type: string "user", expected struct AgentRoleToml
One bad key → whole file rejected → app runs on defaults → the config-load failure gets surfaced as the "Windows setup not completed" gate (no UAC, instant failure). Removing the key and restarting fixed it immediately.

this took days to track down.

Did you find a workaround for this to proceed with a working codex application?

Confirmed on Windows 11 x64, ChatGPT Plus, app 26.825, account is a Local Administrator, UAC at default, AppInfo service running. Exact same symptom set: stuck on the "one-time permission" / "Finish Windows setup" gate, "Retry" fails instantly, and no real UAC prompt ever appears (the dialog on that screen is only an illustration). Running as Administrator changed nothing.

What fixed it (clean, reproducible):

Close the ChatGPT/Codex Desktop app completely.
In C:\Users\<you>\.codex, rename the whole config.toml (keep a copy) rather than editing a single line::
Rename-Item "C:\Users\insyd.codex\config.toml" config.toml.bak
Relaunch the app. It regenerates a clean config.toml and passes the setup gate / opens normally.
Re-merge only what you actually need from the old file (plugins, trusted [projects] blocks, profile) back into the fresh config — the Desktop rewrites the rest.

Key detail versus the other reports here: my config was NOT malformed — python -c "import tomllib; tomllib.load(open('config.toml','rb'))" returned PARSE OK. The trigger was instead a structurally-valid-but-ambiguous file: top-level service_tier/model keys sitting outside any section and a duplicated notify entry. So the failure is NOT only caused by TOML parse errors (missing quotes / legacy keys) — a valid-looking but "off-schema" config is enough to drop Desktop onto the setup gate. Renaming the file wholesale (not fixing one line) is the reliable workaround.

Also worth noting: simply setting [windows] sandbox = "unelevated" did NOT get past the gate by itself; only the fresh regenerated config did.

I hit this too and spent a day instrumenting it. I think I can point at exactly where the two halves disagree, and I can show it survives a complete wipe — so this is not stale state on any of our machines.

Same symptom as #35349, #37940 and #42264.

Environment


OS	Windows 11 Home 10.0.26200.9457 (25H2), locale ko-KR
App	`OpenAI.Codex 26.915.4065.0` (Store product `9PLM9XGG6VKS`), `Status: Ok`
App-server	client_version `26.915.31945`, bundled `codex-cli 0.155.0-alpha.9.2`
Standalone CLI	`codex-cli 0.155.1` (`npm i -g @openai/codex`) — unaffected, works fine
Account	member of `Administrators`, ordinary UAC-filtered token
Virtualization	`VirtualMachinePlatform` Enabled, `HypervisorPresent` True

Worth noting for this thread: it is not only sandboxed execution that breaks. Sending any message fails
with "Failed to send message / update the agent sandbox to continue". It is a hard gate.

The two records disagree

HKLM\SOFTWARE\OpenAI\Codex\WindowsSandboxService has exactly one value and no subkeys:

ProvisionedInstallation = {"user_sid":"S-1-5-21-…-1001",
                           "codex_home":"\\\\?\\C:\\Users\\<user>\\.codex",
                           "session_id":2,
                           "desktop_installation":{"created_codex_home":false,
                                                   "cache_home":"C:\\Users\\<user>\\.cache"}}
subkeys: (none)     ← RegisteredCore does not exist

That is the legacy variant. The app-server requires the registered variant and logs this on every
windowsSandbox/readiness (~/.codex/logs_2.sqlite, table logs):

WARN app-server\src\request_processors\windows_sandbox_processor.rs:67
     Registered Core startup refresh requires manual setup: registered runtime ownership is missing

Corresponding strings in the shipped binaries:

SOFTWARE\OpenAI\Codex\WindowsSandboxService\RegisteredCore
Core installation record is missing runtime state
ProvisionedInstallation … legacy … registered
struct RuntimeRegistration with 5 elements
  package_family  accounts  metadata_roots  ready_package  retiring
struct RuntimeAccountRegistration with 4 elements
  cleanup_logon_pending  account  user_sid  alias_path

--user <USER> is documented as "Windows user that will run Codex after managed deployment", which
suggests registered is a managed-deployment artifact — but the consumer readiness path hard-requires it.

"Retry" never reaches the helper — measured

Every click produces this within ~1 s, with no error logged anywhere:

TRACE app-server request: windowsSandbox/setupStart …
TRACE app-server event:   windowsSandbox/setupCompleted targeted_connections=1

setupStart returns errorCode=null in 13–40 ms. The packaged service
(CodexSandboxService.OpenAI.Codex in the Application event log) records nothing at all for these
attempts — the request never reaches it. None of orchestrator_elevation_required /
orchestrator_helper_launch_* is ever emitted.

I ran a process watcher polling every 120 ms for 90 s while clicking Retry repeatedly:

codex-windows-sandbox-setup.exe — never spawned
consent.exe (the UAC prompt) — never raised

So the "no real UAC prompt" observation in this issue and #37940 is not a UAC problem at all. The
orchestrator is never entered.

Why the app cannot fix itself

ACL on that key:

Owner: NT AUTHORITY\SYSTEM
  BUILTIN\Users                                           Allow  ReadKey
  APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES  Allow  ReadKey
  S-1-15-3-1024-…  (the Codex package SID)                Allow  ReadKey
  BUILTIN\Administrators / NT AUTHORITY\SYSTEM            Allow  FullControl

The unelevated packaged app has read-only access to its own key, and logs at startup:

WARN app-server\src\request_processors\initialize_processor.rs:189
     could not register desktop uninstall ownership

Everything I tried

Attempt	Result
Delete `ProvisionedInstallation` (elevated)	Service recreates it in the legacy shape within seconds
`[windows] sandbox = "unelevated"`	Identical failure, identical warning
Run the app's `codex-windows-sandbox-setup.exe` in place	`Access is denied` even from an elevated shell (WindowsApps execute ACL)
Drive provisioning through the standalone CLI orchestrator	Succeeds — creates `CodexSandboxOffline`/`Online`, populates `CodexSandboxUsers`, recreates `.sandbox/`, writes `setup_marker.json` v5, finishes the read-ACL pass. App still rejects it
`codex sandbox setup --elevated --user <U> --codex-home <H>` (CLI 0.155.1)	`Windows elevated sandbox setup completed`, exit 0, no `RegisteredCore`
Same command using the app's own `0.155.0-alpha.9.2` binary, copied out of WindowsApps	Identical: success, exit 0, no `RegisteredCore`
Elevated `Add-AppxPackage -Register …\AppxManifest.xml`	Succeeds, no change
Full wipe: uninstall package → delete `HKLM\SOFTWARE\OpenAI` → reinstall from Store → launch	Service writes `ProvisionedInstallation` in the legacy shape again; `RegisteredCore` still absent; same warning

That last row is the one that matters. With no package and no HKLM\SOFTWARE\OpenAI present, a clean
Store install still writes only the legacy record. The install path and the readiness check simply disagree.

So for anyone still trying: wiping %USERPROFILE%\.codex, reinstalling, toggling Windows features, or
running the setup helper by hand will not help. Please don't lose your session history over this.

How my machine got here (this may be the common origin)

The app ran its own uninstall cleanup and logged, under provider CodexSandboxService.OpenAI.Codex:
removed CodexSandboxOffline profile and account, removed CodexSandboxOnline profile and account,
remove sandbox group: completed, remove firewall rules: completed, remove WFP filters: completed,
removed .sandbox / .sandbox-bin / .sandbox-secrets.
It then tried to re-register itself and failed with
0x80073D28 — Administrator privileges required to install packaged service
(RegisterByPackageFamilyName, AppXDeploymentServer/Operational), because the app-server is unelevated.
That left the package removed outright. A Store reinstall restored the package and the service — but not
the runtime ownership record, and per the table above nothing restores it.

Two smaller things noticed along the way: remove sandbox group logged success while the group actually
survived, and 10 firewall rules pointing at five previous package versions' chatgpt.exe were left behind
(two of them Block). The uninstall cleanup does not look complete.

Suggested fixes

Fall back to the legacy record when RegisteredCore is absent and a valid setup_marker.json exists.
That alone would unblock every machine in these four issues.
Or make codex sandbox setup --elevated write the registered record when a package identity is present,
instead of only the legacy marker.
Surface the actual reason in the UI. "Setup stopped" plus a retry button that provably does nothing is what
led several of us to wipe profiles and reinstall repeatedly.
Don't let the uninstall cleanup delete accounts/group/ownership before the re-registration that needs
elevation has succeeded — today a failed elevation there leaves the machine unrecoverable.

Workaround that does work

The standalone CLI is unaffected: npm i -g @openai/codex (0.155.1) against the same CODEX_HOME keeps the
same account, model and history. For VS Code-family IDEs, pointing chatgpt.cliExecutable at that binary
restores the extension too — which also sidesteps the older bundled CLI failing on newer rollouts with
unknown variant `completed` .

Happy to supply the raw log rows, the event-log dump or the process-watch trace if any of it is useful.

Additional affected installation: app 26.915.4065.0, registered-Core transition

Adding independently collected evidence from another Windows installation. This matches the missing-RegisteredCore state described in #32492 (comment). It is not confirmation of the exact underlying code defect.

Environment

Windows 11 Pro 25H2, x64, build 26200.9457.
Store package: OpenAI.Codex 26.915.4065.0.
Bundled app-server: 0.155.0-alpha.9.2.
The Windows account is a direct member of the local Administrators group. The diagnostic process is not elevated.
UI shows the Korean equivalents of “Windows setup did not complete” / “Setup stopped”, with a Retry button.

New evidence: runtime selection changed under the same app build

Desktop startup logs on 2026-09-22 show this transition (timestamps below are UTC):

12:08:31 coreGateEnabledAtStartup=false selectedRuntimeSource=bundled
12:34:16 coreGateEnabledAtStartup=true  selectedRuntimeSource=app-package

Before the transition, the executable was the app-managed copy under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe. After it, the app launched codex.exe from its installed WindowsApps package.

The stored desktop flag electron-windows-core-runtime-frameworks-enabled is true. No feature flags were manually changed during this investigation.

After the transition, app-server logs contain the same warning at 12:39:28, 12:40:08, 12:50:33 and 13:03:47 UTC:

Registered Core startup refresh requires manual setup: registered runtime ownership is missing

Observed installation state

CodexSandboxService.OpenAI.Codex is Running, automatic startup, with its executable in the current app package.
The 64-bit HKLM key SOFTWARE\OpenAI\Codex\WindowsSandboxService exists.
Its only value is ProvisionedInstallation; it has no subkeys.
In particular, ...\WindowsSandboxService\RegisteredCore is absent.
User config.toml passes a TOML syntax parse. This does not establish that every key passes Codex's typed configuration schema.

A legacy-helper provisioning run in the local logs reports successful WFP setup, successful provisioning, and successful refresh at 12:43 UTC. That did not resolve the later registered-Core warning. This was not a successful registered-Core setup.

Repeated UI attempts and diagnostic gap

After restoring [windows] sandbox = "elevated" and restarting the app, the user encountered the same failed-setup banner again. Recent desktop logs at 14:55 and 14:57 UTC show windowsSandbox/setupStart requests, including request responses in 5–6 ms with errorCode=null.

Those request responses are not proof of setup completion. We could not recover the corresponding windowsSandbox/setupCompleted.error value from the ordinary desktop logs. The generic “Setup stopped” label is not sufficient to identify whether provisioning, service communication, package registration or configuration failed.

Selecting “continue without administrator access” sets windows.sandbox = "unelevated", and the user reports being able to continue. However, full-access permissions were also used during troubleshooting, so we have not independently verified workspace-write sandbox enforcement or repaired elevated setup. RegisteredCore remains absent.

Requested investigation

Please investigate whether selecting the app-contained registered Core can leave an existing installation with only legacy provisioning state, while the official setup/retry path fails to produce the required ownership registration.

Please also surface the actual structured completion error and failing stage in the UI/logs. A Running service and a successful legacy setup should not be mistaken for successful registered-Core setup.

A supported repair should preserve user projects, sessions and configuration and establish the required registration through the legitimate provisioning flow—not require manually inventing registry records or disabling readiness checks.

No registry values, accounts, firewall rules, package permissions, authentication files or session history were deleted or reset in this investigation. No full logs, conversation transcripts, usernames, machine names, user SIDs or project paths are included in this report.

Additional affected installation: MSIX transition, reinstall, and missing RegisteredCore on 26.917

Adding another affected Windows installation, with local state and selected logs checked on 2026-09-22. This matches the registration mismatch described above; it does not independently establish the exact installer defect.

Environment and verified current state

Native Windows 11, x64.
Initial affected/reinstalled Store package: OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0.
Current installed package: OpenAI.Codex_26.917.6896.0_x64__2p2nqsd0c76g0.
CodexSandboxService.OpenAI.Codex is Running, startup mode Auto, with its executable in the current 26.917 package.
HKLM\SOFTWARE\OpenAI\Codex\WindowsSandboxService contains ProvisionedInstallation, but RegisteredCore is absent.
Current config uses [windows] sandbox = "unelevated". Top-level sandbox_mode = "danger-full-access" and approval_policy = "never" were retained. Successful full-access commands should not be interpreted as proof that elevated sandboxing is repaired.

Observed sequence and evidence

The local sandbox log shows commands using a helper under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash> earlier on September 22, then the helper under the WindowsApps package at 13:25 local time (17:25 UTC).
Before the uninstall/reinstall, that packaged helper logged:

grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0\app for sandbox_group: SetNamedSecurityInfoW failed: 5
setup error: read ACL run had errors

The user encountered “Update Agent sandbox to continue.” Uninstall/reinstall troubleshooting followed. Store reinstall initially failed with 0x80073CF9 (reported during that troubleshooting). A saved recovery transcript confirms a manifest-only orphaned package directory was removed and an elevated Store/winget reinstall completed successfully.
The user reports that elevated setup still did not recover: Retry completed almost immediately and diagnostics reported “registered runtime ownership is missing.” The absent registration is independently verified; the exact retry completion payload was not captured during this follow-up.
Switching to unelevated restored a reported test turn. A subsequent update to 26.917 preserved that setting and the user reports the error card is gone. The registry mismatch remains on 26.917. We have not switched back to elevated to retest 26.917, and have not independently tested all sandbox enforcement properties.

Troubleshooting context

Prior recovery also attempted a SYSTEM-level read/execute ACL grant for CodexSandboxUsers on the 26.915 app directory. The saved transcript has mixed verification results (directory ACE reported absent, executable ACE present), so this report does not claim that ACL repair was complete. No new registry or permission changes were made during this follow-up.

The original ACL failure preceded uninstall. The later missing-registration state should therefore be investigated separately rather than assumed to explain every earlier symptom. A retained ProvisionedInstallation incorrectly suppressing registration is a hypothesis, not a confirmed code-level cause.

Requested behavior

Please investigate migration/runtime selection and the supported setup/retry path when legacy provisioning exists but registered-Core ownership is missing. Setup should repair required registration or expose the actual failing stage. A supported repair should preserve projects, sessions, and configuration without requiring manual registry fabrication or WindowsApps permission changes.

Personal paths, user SIDs, machine identifiers, full logs, and conversation transcripts are omitted.

Additional affected Windows installation — French UI, reported 2026-09-22

Reporting another affected installation with the user's authorization. This is a symptom-only report; the affected computer has not been inspected remotely.

On opening the Codex desktop app on Windows, the UI shows:

La configuration de Windows ne s’est pas terminée
Configuration interrompue

Attempting to send any prompt then fails with:

Impossible d’envoyer le message
Mettez à jour le bac à sable de l’agent pour continuer

English equivalents: Windows setup did not complete / Setup stopped; Failed to send message / Update the agent sandbox to continue.

Impact: the user cannot submit prompts or use the app, rather than merely having individual shell commands fail.

The exact Windows build, Windows app version, UAC behavior, setup completion payload, and RegisteredCore state are not yet verified. The September 22 registration-mismatch reports above are relevant possible explanations, not a confirmed diagnosis for this installation. No workaround has been verified on this computer yet.

Please investigate the setup/readiness gate and provide a supported, non-destructive recovery path. Exposing the actual structured setup failure in the UI would help distinguish configuration/authentication problems from elevation, package migration, and missing runtime registration.

No account identifiers, local usernames, project paths, credentials, or logs are included.

Confirmed workaround on the previously reported installation: clean config + `unelevated` sandbox

Following up on the earlier report in this thread: the affected user confirms that the PowerShell procedure below resolved the Windows setup / message-submission block on their computer. Sharing the steps so they may help other affected users.

The symptoms were “Windows setup did not complete / Setup stopped”, followed by “Failed to send message / Update the agent sandbox to continue”.

What worked

The script stopped the Codex/ChatGPT processes in the current Windows session, backed up the existing config.toml, and replaced it with this minimal configuration, written as UTF-8 without BOM:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[windows]
sandbox = "unelevated"

The user then reopened the app and reported that the problem was resolved.

Important limitation: replacing the configuration and selecting unelevated happened together. We have not isolated which change was necessary, inspected the original configuration for a specific defect, or verified that elevated sandbox setup / RegisteredCore registration was repaired. This is a confirmed workaround for one installation, not a universal fix or proof of the underlying cause. Exact Windows and app versions have not been collected.

Before running

Use a regular, non-administrator PowerShell window under the Windows account that normally runs Codex. Save your work and stop active tasks first: the script terminates Codex/ChatGPT processes in that session.

This replaces your custom settings in config.toml (including any model/profile/MCP settings there) with a minimal configuration, after saving a timestamped backup next to the file. Review and selectively restore needed settings afterward. Keep the backup private. The script does not delete the .codex directory, project files, conversation history or authentication files, and does not edit registry keys, Windows accounts, WindowsApps permissions or firewall rules.

OpenAI documents unelevated as a fallback with weaker isolation than the preferred elevated sandbox, especially for networking. This configuration does not select danger-full-access or bypass approvals. Follow your organization's policy on managed devices. See the official Windows sandbox documentation.

PowerShell procedure

This is the same procedure with account-specific checks removed and messages generalized. It uses the current profile and respects a custom CODEX_HOME.

& {
    $ErrorActionPreference = "Stop"

    # Stop Codex/ChatGPT processes in this Windows session only.
    # Save your work and stop active tasks before running this block.
    $sessionId = (Get-Process -Id $PID).SessionId
    Get-Process -Name "Codex","ChatGPT","codex-command-runner" -ErrorAction SilentlyContinue |
        Where-Object { $_.SessionId -eq $sessionId } |
        Stop-Process -Force -ErrorAction Stop

    # Respect an existing custom CODEX_HOME.
    $codexHome = if ([string]::IsNullOrWhiteSpace($env:CODEX_HOME)) {
        Join-Path $env:USERPROFILE ".codex"
    } else {
        $env:CODEX_HOME
    }

    if (-not [System.IO.Path]::IsPathRooted($codexHome)) {
        throw "CODEX_HOME is relative. Stopping to avoid modifying the wrong directory."
    }

    New-Item -ItemType Directory -Path $codexHome -Force | Out-Null
    $config = Join-Path $codexHome "config.toml"

    if (Test-Path -LiteralPath $config) {
        $backup = "$config.before-workaround-$(Get-Date -Format 'yyyyMMdd-HHmmssfff').bak"
        Copy-Item -LiteralPath $config -Destination $backup
        Write-Host "Previous configuration backed up to: $backup"
    }

    $newConfig = @'
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[windows]
sandbox = "unelevated"
'@

    # Write UTF-8 without BOM; compatible with Windows PowerShell.
    [System.IO.File]::WriteAllText(
        $config,
        $newConfig,
        [System.Text.UTF8Encoding]::new($false)
    )

    Write-Host ""
    Write-Host "Fallback configuration saved to: $config"
    Write-Host "Reopen Codex from the Start menu."
}

To undo the configuration change, fully close Codex and restore your chosen config.toml.before-workaround-*.bak over config.toml. Restoring the old configuration may bring back the original failure.

A supported repair for the stronger sandbox and a UI that exposes the actual setup error would still be valuable. Successful app use with this fallback should not be treated as confirmation that elevated setup is fixed.

The "Windows setup did not complete / Setup stopped" loop on 26.917 has a concrete root cause. With registered Core enabled, setup won't provision when the default sandbox_mode is danger-full-access (registered Core requires a service-compatible sandbox policy). Because of that, the service never writes the RegisteredCore receipt that readiness waits for.

I posted the root cause with code links, plus a workaround that keeps [windows] sandbox = "elevated" (temporarily switch to workspace-write, click Retry setup, then switch back): #47383 (comment)

That probably also explains why the clean-config workaround above helped: workspace-write passes this check, and unelevated skips the registered-Core readiness gate entirely.

Windows app stuck on "Finish Windows setup" — sandbox setup never triggers a real UAC prompt, "Retry" fails instantly #32492

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 11, 2026

PyroClash commented on Jul 12, 2026

skydiver1118 commented on Jul 12, 2026

skydiver1118 commented on Jul 12, 2026

skydiver1118 commented on Jul 13, 2026

zengxm1979 commented on Jul 15, 2026

heinerborle commented on Jul 16, 2026

The Underlying Issue

The Fix / Workaround

alicemsu commented on Jul 27, 2026

MBDWWLC commented on Aug 4, 2026

LukasMosser commented on Aug 13, 2026

Rene-Kuhm commented on Sep 1, 2026

lloitesa013 commented on Sep 22, 2026

Environment

The two records disagree

"Retry" never reaches the helper — measured

Why the app cannot fix itself

Everything I tried

How my machine got here (this may be the common origin)

Suggested fixes

Workaround that does work

srtdog64 commented on Sep 22, 2026

Additional affected installation: app 26.915.4065.0, registered-Core transition

Environment

New evidence: runtime selection changed under the same app build

Observed installation state

Repeated UI attempts and diagnostic gap

Requested investigation

Kyle1366 commented on Sep 22, 2026

Additional affected installation: MSIX transition, reinstall, and missing RegisteredCore on 26.917

Environment and verified current state

Observed sequence and evidence

Troubleshooting context

Requested behavior

WITH-BY commented on Sep 22, 2026

Additional affected Windows installation — French UI, reported 2026-09-22

WITH-BY commented on Sep 22, 2026

Confirmed workaround on the previously reported installation: clean config + unelevated sandbox

What worked

Before running

PowerShell procedure

fishyes commented on Sep 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Confirmed workaround on the previously reported installation: clean config + `unelevated` sandbox