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
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 / Mediumcodex.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 / Highcodex.exe app-server: Full / Highnode_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=0PromptOnSecureDesktop=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:
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:
-
The launcher triggers UAC and starts an elevated helper.
-
The user confirms UAC.
-
The elevated helper confirms that it is Full / High.
-
The elevated helper terminates existing Codex.exe / codex.exe / node_repl.exe processes to avoid reusing an old medium-integrity app-server.
-
The elevated helper directly starts:
Codex.exe --do-not-de-elevate
After launching this way on Windows 11, verification shows:
Codex.exe: Full / Highcodex.exe app-server: Full / Highnode_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.
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:
Shell:
pwshBehavior
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 / Mediumcodex.exe app-server:Limited / MediumLimited / MediumThis 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 / Highcodex.exe app-server:Full / Highnode_repl.exe:Full / HighFull / HighOne additional observation: on the Windows 10 machine, the parent process of
Codex.exewas still a non-elevatedexplorer.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.exeprocess appeared asFull / Highfirst.Around 0.4 seconds later, another
Codex.exeprocess appeared asLimited / Medium, with command-line arguments including:A few seconds later,
codex.exe app-serverwas also running asLimited / 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
RUNASADMINforCodex.exeConsentPromptBehaviorAdmin=0PromptOnSecureDesktop=0Run as administratorThese did not reliably keep
codex.exe app-serverand the tool shell asFull / 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:The shortcut is placed under:
The shortcut points to a PowerShell launcher script. When the user starts
Codex Adminfrom Start Menu or Desktop, the flow is:The launcher triggers UAC and starts an elevated helper.
The user confirms UAC.
The elevated helper confirms that it is
Full / High.The elevated helper terminates existing
Codex.exe/codex.exe/node_repl.exeprocesses to avoid reusing an old medium-integrity app-server.The elevated helper directly starts:
After launching this way on Windows 11, verification shows:
Codex.exe:Full / Highcodex.exe app-server:Full / Highnode_repl.exe:Full / HighFull / HighThe user can then manually
Pin to StartthisCodex Adminshortcut 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 Startstep is manual.Source-code level observation
I looked at the public
openai/codexrepository. In the public app-server code, tool commands appear to be spawned normally from the app-server process. Therefore, ifcodex.exe app-serveris alreadyLimited / 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-elevatein 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:
Full / HighCodex.exe, followed shortly by a medium-integrity relaunch process.Codex.exe --do-not-de-elevatekeeps the Windows 11 app-server and tool shell asFull / High.