›_ Codex Issues
Codex Issues / #28107

Windows 11 Codex Desktop de-elevates app-server despite admin launch; same version on Windows 10 stays elevated

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

This may be related to #25296, but I am opening a separate issue because I have a same-version Windows 10 vs Windows 11 comparison, a launch timeline observation, and a workaround that keeps the Windows 11 app-server elevated.

Environment

  • Windows 11: Codex Desktop 26.609.4994.0
  • Windows 10: Codex Desktop 26.609.4994.0
  • Install path format:

``text
C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0\app\Codex.exe
``

  • Shell: pwsh

Behavior

On Windows 11, even when Codex Desktop is launched through an administrator path, the final tool host may still run as medium integrity:

  • Codex.exe: Limited / Medium
  • codex.exe app-server: Limited / Medium
  • tool shell: Limited / Medium

This breaks workflows that require administrator permissions, such as creating file symbolic links, writing to protected directories, installing packages, or modifying machine-level components.

On Windows 10, with the same Codex Desktop version, the elevated state is preserved:

  • Codex.exe: Full / High
  • codex.exe app-server: Full / High
  • node_repl.exe: Full / High
  • tool shell: Full / High

One additional observation: on the Windows 10 machine, the parent process of Codex.exe was still a non-elevated explorer.exe, so the difference does not appear to be simply "High parent process vs Medium parent process".

Windows 11 launch timeline observation

In one captured Windows 11 launch record, the initial Codex.exe process appeared as Full / High first.

Around 0.4 seconds later, another Codex.exe process appeared as Limited / Medium, with command-line arguments including:

--no-startup-window --do-not-de-elevate

A few seconds later, codex.exe app-server was also running as Limited / Medium.

So the failure does not look like Codex never receives an elevated token. It looks more like the Windows 11 Desktop / packaged app / relaunch / single-instance path briefly starts elevated and then transitions to a medium-integrity process before app-server is started.

Things tested on Windows 11 that did not solve it

  • Setting AppCompat RUNASADMIN for Codex.exe
  • Changing UAC policy:
  • ConsentPromptBehaviorAdmin=0
  • PromptOnSecureDesktop=0
  • Restarting after those changes
  • Launching only through Start Menu / Explorer with Run as administrator

These did not reliably keep codex.exe app-server and the tool shell as Full / High.

Workaround: create a Codex Admin Start Menu launcher

The workaround that worked for me is not modifying the Codex installation package and not relying on AppCompat RUNASADMIN. Instead, I created an independent Start Menu shortcut / launcher, for example:

Codex Admin.lnk

The shortcut is placed under:

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Codex Admin.lnk

The shortcut points to a PowerShell launcher script. When the user starts Codex Admin from Start Menu or Desktop, the flow is:

  1. The launcher triggers UAC and starts an elevated helper.
  2. The user confirms UAC.
  3. The elevated helper confirms that it is Full / High.
  4. The elevated helper terminates existing Codex.exe / codex.exe / node_repl.exe processes to avoid reusing an old medium-integrity app-server.
  5. The elevated helper directly starts:

``text
Codex.exe --do-not-de-elevate
``

After launching this way on Windows 11, verification shows:

  • Codex.exe: Full / High
  • codex.exe app-server: Full / High
  • node_repl.exe: Full / High
  • tool shell: Full / High

The user can then manually Pin to Start this Codex Admin shortcut and use it as a stable one-click entry point for elevated Codex sessions.

Note: this is not the Windows Startup folder and does not auto-run Codex at login. It is only a Start Menu shortcut / launcher. Also, Windows 11 does not appear to provide a stable public command-line API suitable for force-pinning arbitrary shortcuts to Start, so the Pin to Start step is manual.

Source-code level observation

I looked at the public openai/codex repository. In the public app-server code, tool commands appear to be spawned normally from the app-server process. Therefore, if codex.exe app-server is already Limited / Medium, spawned shells will also be medium integrity.

This makes me suspect that the issue happens before app-server starts, likely in the Codex Desktop / packaged app / relaunch / single-instance path, rather than in the app-server command-spawn logic itself.

I also could not find the implementation of --do-not-de-elevate in the public Rust source, so that logic may live in the Desktop/Electron/MSIX packaged app layer or another part of the Desktop app code.

Expected behavior

If Codex Desktop is launched through an administrator path, app-server and the tool shell should remain elevated.

If the current Windows 11 launch path cannot provide an elevated command token, Codex should report that clearly instead of appearing to launch as administrator while still running actual tool commands under medium integrity.

Notes

This issue is highly related to #25296. The additional information here is:

  • Same Codex Desktop version: Windows 10 stays elevated, Windows 11 does not.
  • The Windows 11 launch record shows an initial Full / High Codex.exe, followed shortly by a medium-integrity relaunch process.
  • An external elevated helper plus Codex.exe --do-not-de-elevate keeps the Windows 11 app-server and tool shell as Full / High.
  • Packaging that workaround as a Start Menu shortcut / launcher provides a stable one-click elevated entry point.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26619
  • #27889

Powered by Codex Action

ZaunEkko · 2 months ago

I can reproduce this on a newer Microsoft Store build.

Environment:

OS: Windows 11 x64
Codex Desktop package: OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0
Package version: 26.609.9530.0
Install path: C:\Program Files\WindowsApps\OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0
SignatureKind: Store

I tested two launch paths:

  1. Start Codex Desktop from the Start Menu using Run as administrator.
  2. Start an elevated PowerShell via UAC, confirm the helper PowerShell is elevated, then launch the packaged app executable directly:
$pkg = Get-AppxPackage OpenAI.Codex
$exe = Join-Path $pkg.InstallLocation 'app\Codex.exe'
Start-Process -FilePath $exe

The elevated helper log showed:

Elevated: True
Exe: C:\Program Files\WindowsApps\OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0\app\Codex.exe
Start-Process succeeded

After launch, the Codex Desktop process tree was present and the main process command line included --do-not-de-elevate:

Codex.exe --no-startup-window --do-not-de-elevate
codex.exe app-server --analytics-default-enabled

However, checking the process tokens via OpenProcessToken + GetTokenInformation(TokenElevation) showed all Store-package Codex processes were still not elevated:

Codex.exe                         Elevated 0
resources\codex.exe app-server    Elevated 0
Codex.exe renderer/gpu/utility     Elevated 0

So at least on this Windows 11 machine, even launching app\Codex.exe from a confirmed elevated helper process does not preserve a high-integrity/admin token for either the desktop process or codex.exe app-server.

I also checked the package manifest capabilities. This build declares:

runFullTrust
unvirtualizedResources
internetClient

I did not see allowElevation in the manifest.

This matches the user-visible behavior: Codex Desktop can appear to be started through an administrator path, but commands inside the app still report a medium-integrity / non-admin token.

dxzcsd123 · 1 month ago

Adding a data point from another affected machine, because this breaks a very basic user expectation: if I explicitly right-click → Run as administrator and accept the UAC prompt, I expect Codex to be able to do what an administrator can do. Instead, agent commands still run without admin rights, and nothing in the UI indicates that elevation was silently dropped.

Environment

  • Windows 11 Pro build 26200 (25H2)
  • Codex Desktop 26.623.19656.0 (MSIX OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0), CLI codex-cli 0.142.5
  • config.toml: sandbox_mode = "danger-full-access", approval_policy = "never", [windows] sandbox = "elevated" (elevated sandbox setup completed; CodexSandboxOnline / CodexSandboxOffline users exist)

Observations on the same machine (same config):

  1. Desktop app launched elevated → agent commands still not elevated, as described in this issue.
  2. CLI from an elevated PowerShell works correctly. With danger-full-access, codex exec runs commands at High integrity with BUILTIN\Administrators Enabled — net session succeeds:

``text
Mandatory Label\High Mandatory Level S-1-16-12288
BUILTIN\Administrators Enabled group
net session -> "There are no entries in the list."
``

So the core exec path propagates elevation fine; the drop is specific to the Desktop app launch chain (the de-elevated relaunch described in this issue).

  1. codex sandbox <cmd> runs as codexsandboxoffline at Medium integrity (S-1-16-8192), net session → access denied. That part is expected sandbox behavior and is fine.

If de-elevating the Desktop app on Windows 11 is intentional, please at least surface it to the user (a warning or status indicator), and provide a supported way for an explicitly elevated launch to stay elevated.