Skip to content

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

Open
Open
Windows 11 Codex Desktop de-elevates app-server despite admin launch; same version on Windows 10 stays elevated#28107
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@Tuo-Luo
Tuo-Luo
opened on Jun 13, 2026

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:

    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:

    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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on Jun 13, 2026

  2. github-actions commented on Jun 13, 2026

    @github-actions
    github-actionsBot
    on Jun 13, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. ZaunEkko commented on Jun 16, 2026

    @ZaunEkko
    ZaunEkko
    on Jun 16, 2026

    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.

  4. dxzcsd123 commented on Jul 7, 2026

    @dxzcsd123
    dxzcsd123
    on Jul 7, 2026

    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:

      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).

    3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions