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

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.