›_ Codex Issues
Codex Issues / #36613

Windows native agent setup fails without displaying the required UAC prompt

Open 💬 3 comments Opened Aug 2, 2026 by oldschoolbif
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.727.6591.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 Pro, x64 Windows build 26200 PowerShell 7.6.4 WSL2 with Ubuntu 24.04.4 also installed

What issue are you seeing?

After changing the Agent environment from Windows Subsystem for Linux to Windows native, Codex displays a "Finish Windows setup" screen.

The screen says that ChatGPT needs one-time permission and instructs the user to click "Finish setup" and approve a UAC prompt.

However, no UAC prompt appears.

Clicking the setup button eventually produces the red error:

Windows setup didn't finish

The only usable path is "Continue with limited access."

The setup screen does not explain why elevation failed, which executable it attempted to launch, where diagnostic logs are located, or how to retry the setup manually.

What steps can reproduce the bug?

  1. Open the Codex Windows app.
  1. Open Settings > General.
  1. Set Agent environment to:

Windows Subsystem for Linux

  1. Use Codex under WSL.
  1. Return to Settings > General.
  1. Change Agent environment to:

Windows native

  1. Restart the application when requested.
  1. Observe the "Finish Windows setup" screen.
  1. Click the button to finish or try Windows setup.
  1. Observe that no UAC prompt appears.
  1. After waiting, observe the error:

Windows setup didn't finish

  1. Select "Continue with limited access" to proceed.

What is the expected behavior?

Clicking "Finish Windows setup" should display a normal Windows UAC prompt identifying the executable and its verified publisher.

After approval, Codex should confirm that the Windows-native sandbox was configured successfully.

If setup fails, Codex should display:

  • the failed setup step
  • the executable or command that failed
  • the Windows error code
  • the relevant log location
  • a retry option
  • a documented manual setup procedure
  • an explanation of what "limited access" changes

Additional information

The setup screen showed ChatGPT as the application and OpenAI LLC as the expected verified publisher, but the actual UAC dialog never appeared.

The failure occurred immediately after switching back from WSL to Windows-native execution to recover existing Codex chats that had been created under Windows paths.

Continuing with limited access allowed the app to open, but the Windows-native sandbox remained unavailable.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 25 days ago

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

  • #35965

Powered by Codex Action

LukasMosser · 15 days ago

Hi, this issue is preventing anyone from installing ChatGPT on windows and is a critical bug to fix. We cannot proceed currently with using the latest installer.

codex-corp · 4 days ago

I hit what appears to be the same issue on Windows with OpenAI.Codex 26.818.5229.0.

Symptoms:

  • "Finish Windows setup" kept failing.
  • No UAC prompt appeared from the app, although UAC worked normally when launching Command Prompt as administrator.
  • Get-AppxPackage OpenAI.Codex reported Status = Ok.
  • codex-windows-sandbox-setup.exe was present in the installed package.
  • WSL/Ubuntu itself was working, and codex --version inside WSL returned codex-cli 0.146.0.

My ~/.codex/config.toml contained:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

What fixed it for me was simply removing that section fully, Then I restarted the Codex/ChatGPT Windows app. After that, the app started normally and the Windows setup loop was gone.

I did not need to change UAC settings, take ownership of WindowsApps, or set windows.sandbox = "unelevated".

This suggests there may be a stale/conflicting desktop WSL preference in config.toml that interferes with switching back to Windows-native setup. Hopefully this helps narrow down the issue.