ChatGPT for Windows cannot complete setup or enter limited-access mode

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

• #32995
• #32808

Powered by Codex Action

I am experiencing the same issue on Windows 11.

The ChatGPT/Codex app remains stuck on the “Complete Windows setup” screen. I approve the administrator/UAC prompt, but the setup still fails and returns to the same page.

I also tried:

• Repairing the app from Windows Settings
• Running the app as Administrator
• Restarting the app and Windows
• Retrying the Windows setup several times

The issue still persists.

Environment:

• OS: Windows 11
• Architecture: x64
• Installation source: Microsoft Store
• Subscription: ChatGPT Plus

Unlike the original report, I have not yet checked whether the sandbox log contains the same SetRemotePorts error.

Please let me know where the sandbox setup logs are stored so I can provide the relevant diagnostic information.

me too, unistall all and reinstall but still got error

Additional confirmed reproduction from a Windows user. Sanitized report below.

Environment

• Windows 10 22H2, x64, OS build 19045.6466
• ChatGPT/Codex package: OpenAI.Codex_26.715.8383.0_x64__2p2nqsd0c76g0
• Co-installed desktop package: OpenAI.ChatGPT-Desktop_1.2026.190.0_x64__2p2nqsd0c76g0
• Subscription: ChatGPT Plus

Symptoms

• App opens only to “Complete Windows setup”.
• All buttons visibly react to clicks, but no action is executed.
• Retry setup does nothing.
• Continue with limited access does nothing.
• The real UAC prompt is never launched from this screen.
• Clean reinstall, package re-registration, reboot, and clearing/recreating the Codex web profile did not initially resolve the loop.
• Launching the OpenAI.Codex AppID directly still returned to the same setup screen.

Observed process state

The package itself remained registered with Status: Ok. While the broken screen was open, the app still spawned:

• ChatGPT.exe main/UI process
• renderer, GPU, network and storage subprocesses
• bundled codex.exe ... app-server

This suggests the package and app server can start while the bootstrap/setup UI is stuck.

Related Windows events

Windows Event Viewer recorded a MoAppHang / Event ID 1002 for ChatGPT Classic.exe version 1.2026.190.0, with Hang type: Quiesce.

A prior sandbox setup log on the same machine contained:

helper_firewall_rule_create_or_add_failed
SetRemoteAddresses failed
HRESULT(0xD000000D)
An invalid parameter was passed to a service or function.

This may or may not be the same root cause, but it could be relevant to the Windows setup/bootstrap path.

Troubleshooting results

• Setting:

[windows]
sandbox = "unelevated"

did not by itself bypass the setup screen.

• Renaming/recreating %APPDATA%\Codex\web\Codex did not immediately fix the loop.
• The official Codex CLI (@openai/codex, codex-cli 0.144.6) could read and resume all existing sessions from .codex, confirming project/session data was intact.
• After restoring a valid minimal config.toml, validating sessions through the CLI, and restarting the app, the desktop app became accessible again and all projects were present.

Expected behavior

If elevated Windows setup fails, the app should either:

1. enter limited-access/unelevated mode reliably, or
2. show the precise sandbox/firewall/UAC error and allow retry.

The UI should never leave both recovery buttons visually clickable but functionally inert.

No project names, usernames, authentication files, or private logs are included in this report.

Same issue, how to deal with that?

Same.
Codex cannot complete Windows sandbox setup when using:

[windows]
sandbox = "elevated"
The application repeatedly prompts the user to complete Windows setup.

However, changing the configuration to:
[windows]
sandbox = "unelevated"
allows Codex to work normally.

Investigation:
The sandbox setup log indicates that the installation process completes successfully:

• WFP setup succeeded
• Sandbox users were created
• ACL permissions were applied successfully
• Setup binary completed successfully

Despite the successful sandbox setup process, elevated mode is still detected as incomplete by Codex.

Expected behavior:
The elevated sandbox mode should initialize successfully after the setup process completes.

Actual behavior:

sandbox.2026-07-30.log

Codex remains stuck prompting for Windows setup when using elevated sandbox mode.

This is worked for me. issue Fixed 🎉

The issue was caused by the config.toml file inside the .codex folder.

First, completely close the chatgpt app using task manager. then go to the folder where Codex is installed, open the .codex folder, and find the config.toml file.

Rename it to something like: config.toml.old

Then open the chatgpt app again. It will automatically create a new config.toml file, and everything should work.

This is the safest option. Do not delete the entire .codex folder, as you could lose your backups or other saved data.

Original comment link:
cannot finish

Follow-up: the issue recurred on the same Windows 10 machine after the app had worked normally for several days.

Observed sequence:

1. Codex/ChatGPT desktop was working normally with existing local sessions and workspaces.
2. The PC was shut down using a delayed Windows shutdown command while the app may still have been running.
3. On the next boot, the app again opened on the Vietnamese “Complete Windows setup” screen and could not proceed.
4. Codex CLI then failed with a TOML parse error:

Error loading config.toml:
C:\Users\<redacted>\.codex\config.toml:1:3319: key with no value, expected '='

1. Replacing the active config with a minimal valid file restored the CLI:

[windows]
sandbox = "unelevated"

1. codex resume --all immediately showed all previous local sessions; no project or session data was lost.
2. The sandbox state JSON was valid and did not require repair.
3. After reopening the desktop app, it displayed first-run onboarding (“Codex is now the ChatGPT app”), but all previous recent Codex sessions were still present and usable.

This recurrence suggests a possible unsafe/non-atomic write or incomplete flush of ~/.codex/config.toml during shutdown or forced app termination. That is an inference, not yet proven. The app currently appears to block startup on the malformed config instead of automatically recovering from a backup/default config.

Requested hardening:

• Write config.toml atomically (temp file + fsync/flush + rename).
• Keep and validate a last-known-good backup.
• If parsing fails, quarantine the malformed file and start with a safe default instead of returning to the setup loop.
• Log which component last wrote the file.
• Avoid rewriting the entire TOML as a single malformed line.

Privacy: local usernames, project names, conversation contents, auth files, and raw logs are omitted.

This is worked for me. issue Fixed 🎉 The issue was caused by the config.toml file inside the .codex folder. First, completely close the chatgpt app using task manager. then go to the folder where Codex is installed, open the .codex folder, and find the config.toml file. Rename it to something like: config.toml.old Then open the chatgpt app again. It will automatically create a new config.toml file, and everything should work. This is the safest option. Do not delete the entire .codex folder, as you could lose your backups or other saved data. Original comment link: cannot finish

Yes but the solution needs you to rename the config.toml each time you reopen ChatGPT Desktop. Also, it doesn't work with special cases that use custom providers (and the "proxies" don't know how to elevate ChatGPT properly to avoid this issue than can be avoided being admin/launching it as admin).

对我来说有效！问题已解决🎉 问题是由 .codex 文件夹内的 config.toml 文件引起的。 首先，使用任务管理器完全关闭 chatgpt 应用程序。然后转到 Codex 的安装文件夹，打开 .codex 文件夹，找到 config.toml 文件。 将其重命名为类似这样的名称：config.toml.old 然后再次打开 chatgpt 应用。它会自动创建一个新的 config.toml 文件，一切应该就能正常运行了。 这是最稳妥的做法。请勿删除整个 .codex 文件夹，否则可能会丢失备份或其他已保存的数据。 原评论链接： 无法完成

非常有用我也遇到这个问题，也解决了codex自己把config.toml 给改了 然后就打不开了，重新恢复就行了

Hello Codex team,

I hit an unrecoverable state in the ChatGPT/Codex desktop app on Windows. The app launches straight into the full-screen "Complete Windows setup" onboarding screen and cannot be dismissed — none of the buttons work, "Continue with limited access" is unresponsive, and the same screen returns on every launch.

Environment

OS: Windows 11 Enterprise, build 26200
App package: OpenAI.Codex (MSIX), version 26.803.8161.0
Config also references app version 26.803.41515 (possible UI/app-server version skew)
CODEX_HOME: C:\Users<user>.codex
Root cause (from the desktop logs) The app-server fails to LOAD the configuration because config.toml contains a duplicate TOML table. Every onboarding action then fails:

error [electron-message-handler] Request failed conversationId=none durationMs=3
error={"code":-32600,"message":"failed to load configuration:
C:\Users\<user>\.codex\config.toml:297:30: duplicate key"}
info [AppServerConnection] response_routed ... errorCode=-32600
hadInternalHandler=false hadPending=true method=windowsSandbox/setupStart
info [AppServerConnection] response_routed ... errorCode=null
hadInternalHandler=false hadPending=true method=windowsSandbox/readiness
The duplicate was an identical [mcp_servers.<name>.env] table declared twice (same table header repeated a few lines apart). TOML forbids re-declaring a table, so the entire config load aborts, which cascades into the onboarding/windowsSandbox setup calls returning -32600 in an infinite retry loop.

Impact / why this is a product bug

A single malformed key in config.toml makes the WHOLE desktop app unusable — it hard-blocks onboarding instead of degrading gracefully.
The onboarding UI does not surface the parse error to the user at all. The screen just says "Windows setup not completed" and offers "Retry" / "Continue with limited access", neither of which works.
"Continue with limited access" is non-functional in this state, so there is no user-facing escape hatch.
When the setup step elevates itself, it spawns an admin-level app process holding the frozen window. That window has no working close/cancel control and cannot be terminated without administrator rights.
windowsSandbox/setupStart returns hadInternalHandler=false in this build — the method appears to have no registered handler, suggesting the onboarding UI and the installed app-server may be out of version sync.
How I recovered (workaround for other users)

Edited C:\Users<user>.codex\config.toml and removed the duplicated table block (kept a single copy).
Fully closed all ChatGPT/codex processes (the elevated one required an admin taskkill /IM ChatGPT.exe /F or a reboot).
Relaunched — onboarding no longer appears and the app works.
Suggested fixes

Make config loading resilient: on a duplicate key, log a warning and apply last-wins (or skip the offending table) instead of aborting the entire config load.
Never hard-block onboarding on config load / windowsSandbox setup. "Continue with limited access" must always work.
Surface config parse errors directly in the UI, including the exact file path, line and column.
If the setup elevates and shows a window, that window must have a working Close/Cancel, and the app must not leave an unkillable elevated window behind.
Investigate the windowsSandbox/setupStart "hadInternalHandler=false" / version skew between the onboarding UI and the app-server.

Title: ChatGPT Desktop / Codex Windows setup fails at firewall sandbox step

Environment

OS: Windows 11, version 25H2, build 10.0.26200.9168
DISM version: 10.0.26100.8972
Account: Administrator
App: OpenAI.ChatGPT-Desktop, version 1.2026.190.0
Package status: Ok
ChatGPT Classic works. The new app does not.

Symptom

App opens to "Finish Windows setup / needs a one-time permission."
"Try Windows setup again" does not complete.
"Continue with limited access" does not work either.

Diagnostics completed: Repair, Reset, reinstall, restart, DISM ScanHealth/RestoreHealth, SFC all successful. UAC at default.

Request: Confirm if this is the known firewall rule creation defect in issues 33967 and 34406. Provide a supported fix or app update that does not require deleting user data, editing the registry, or removing protected system packages.