›_ Codex Issues
Codex Issues / #25296

Codex Desktop launched elevated still spawns medium-integrity shell

Open 💬 9 comments Opened May 30, 2026 by PrzemyslawKlys

What issue are you seeing?

On Windows, Codex Desktop appears to be configured for the elevated Windows sandbox, and the Desktop process is launched with --do-not-de-elevate, but the actual tool shell spawned for agent commands still runs with a filtered medium-integrity token rather than a high-integrity/admin token.

This makes elevated/admin work impossible from the Codex Desktop shell even when the app was opened through UAC and the config requests elevated Windows sandbox behavior.

This is related to, but not the same as:

  • #24490
  • #24050
  • #18620
  • #10090

In this case the sandbox setup refresh is not currently failing before commands run. Commands do run, but the spawned shell is not elevated.

Environment

OS: Windows 11 x64
Codex App: 26.527.3686.0
Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
Shell: C:\Program Files\PowerShell\7\pwsh.exe

Relevant config.toml:

model = "gpt-5.5"
sandbox_mode = "danger-full-access"
approval_policy = "never"

[windows]
sandbox = "elevated"

Process tree

The agent shell is spawned under Codex Desktop like this:

pwsh.exe
  parent: codex.exe app-server --analytics-default-enabled
    parent: Codex.exe ... --do-not-de-elevate

Observed command line for Codex.exe includes:

--do-not-de-elevate

Actual behavior

The shell process is still not elevated.

PowerShell check:

$id = [Security.Principal.WindowsIdentity]::GetCurrent()
$p = [Security.Principal.WindowsPrincipal]$id
[pscustomobject]@{
  User = $id.Name
  IsAdmin = $p.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
  PID = $PID
  Process = (Get-Process -Id $PID).ProcessName
  Integrity = ((whoami /groups | Select-String 'Mandatory Label').Line -replace '^\s+','')
} | Format-List

Observed:

User      : EVOTEC\przemyslaw.klys
IsAdmin   : False
Process   : pwsh
Integrity : Mandatory Label\Medium Mandatory Level

whoami /groups also shows admin groups as filtered/deny-only, for example:

BUILTIN\Administrators    Group used for deny only
EVOTEC\Domain Admins      Group used for deny only
EVOTEC\Enterprise Admins  Group used for deny only
Mandatory Label\Medium Mandatory Level

A protected-path write probe fails:

$path = 'C:\Program Files\codex-elevation-probe.tmp'
try {
  Set-Content -LiteralPath $path -Value 'probe' -ErrorAction Stop
  Remove-Item -LiteralPath $path -Force -ErrorAction Stop
  'ProtectedWrite=SucceededAndRemoved'
} catch {
  'ProtectedWrite=Failed'
  'Error=' + $_.Exception.GetType().FullName
  'Message=' + $_.Exception.Message
}

Observed:

ProtectedWrite=Failed
Error=System.UnauthorizedAccessException
Message=Access to the path 'C:\Program Files\codex-elevation-probe.tmp' is denied.

Sandbox log observations

Current sandbox logs show setup refreshes succeeding and the copied command runner being used:

setup refresh: processed 2 write roots (read roots delegated); errors=[]
codex-windows-sandbox-setup.exe setup binary completed
helper launch resolution: using copied command-runner path C:\Users\przemyslaw.klys.EVOTEC\.codex\.sandbox-bin\codex-command-runner-0.135.0-alpha.1.exe

There is an older stale setup error file from a previous date:

{
  "code": "helper_unknown_error",
  "message": "apply deny-read ACLs"
}

but its timestamp is older than the current successful setup refreshes.

UAC policy checks

EnableLUA                  : 1
ConsentPromptBehaviorAdmin : 5
PromptOnSecureDesktop      : 1
EnableInstallerDetection   : 1

Expected behavior

If Codex Desktop is launched elevated and configured with:

sandbox_mode = "danger-full-access"

[windows]
sandbox = "elevated"

then the shell/tool process used for commands that require administrator rights should either:

  1. run with a high-integrity/admin token, or
  2. clearly report that Codex Desktop cannot provide an elevated command token from this launch path/configuration.

At minimum, danger-full-access plus windows.sandbox="elevated" should not appear successful while command execution still uses a medium-integrity filtered token.

Why this matters

This breaks workflows such as installing MSI packages, modifying services, writing under C:\Program Files, or any other admin-required Windows operation. From the user perspective, UAC was approved and Codex appears to be running with elevated intent, but the actual agent shell cannot perform admin actions.

View original on GitHub ↗

9 Comments

PrzemyslawKlys · 1 month ago

Consolidated local findings from the elevation repro:

What reproduces

Codex Desktop installed via MSIX starts the Electron main/app-server path at medium integrity, even when the user expects an elevated session.

Observed on:

OpenAI.Codex      26.527.3686.0
OpenAI.CodexBeta  26.527.3774.0

Current Beta thread process chain:

Codex (Beta).exe
  -> resources\codex.exe app-server --analytics-default-enabled
    -> pwsh.exe

Shell result:

IsAdmin:   False
Integrity: Medium Mandatory Level
Protected write to C:\Program Files: UnauthorizedAccessException

Portable proof

Using the same installed Codex stable binaries, I copied the package app folder out of C:\Program Files\WindowsApps and patched only the copied Codex.exe embedded manifest:

asInvoker -> requireAdministrator

Launching that copied Win32 app with --do-not-de-elevate works end-to-end:

work\CodexStablePortable\Codex.exe
  TokenElevation: 1
  TokenElevationType: 2

work\CodexStablePortable\resources\codex.exe app-server --analytics-default-enabled
  TokenElevation: 1
  TokenElevationType: 2

per-thread app-server --listen stdio://
  TokenElevation: 1
  TokenElevationType: 2

pwsh / powershell inside that thread:
  IsAdmin: True
  Integrity: High Mandatory Level

So Codex Desktop + resources\codex.exe app-server can run elevated when the Win32 launch path actually provides an elevated token.

MSIX comparison with Store PowerShell

MSIX is not an absolute blocker to elevation. Store PowerShell is installed on the same machine:

Microsoft.PowerShell 7.6.2.0
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.2.0_x64__8wekyb3d8bbwe

It is also a Windows.FullTrustApplication, uses runFullTrust / unvirtualizedResources, and pwsh.exe has requestedExecutionLevel level="asInvoker". But launching Store pwsh.exe with Start-Process -Verb RunAs succeeds:

{
  "Path": "C:\\Program Files\\WindowsApps\\Microsoft.PowerShell_7.6.2.0_x64__8wekyb3d8bbwe\\pwsh.exe",
  "IsAdmin": true,
  "Integrity": "High Mandatory Level"
}

One visible package-shape difference:

PowerShell:
  windows.appExecutionAlias -> pwsh.exe

Codex:
  no windows.appExecutionAlias
  Application Executable="app/Codex (Beta).exe"

Directly trying to launch Codex Beta's packaged EXE with Start-Process -Verb RunAs fails before an elevated process is created:

Access is denied:
C:\Program Files\WindowsApps\OpenAI.CodexBeta_...\app\Codex (Beta).exe

Refined interpretation

This does not look like "Codex cannot run elevated" and it also is not simply "MSIX can never elevate." The local evidence suggests the current Codex MSIX package/launch shape does not expose a working elevated app-server path.

Possible product directions:

  • provide a non-MSIX installer/channel for elevated Codex sessions;
  • add a supported MSIX elevation launch path, potentially using an execution alias / different package layout / appropriate restricted capability;
  • use a split architecture where the MSIX UI remains medium and a separately installed elevated helper/service owns privileged operations.
amatsuki5032 · 1 month ago

I can reproduce the same class of issue on another Windows 11 machine.

Environment

  • Codex Desktop App: 26.527.3686.0
  • MSIX package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
  • Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
  • Codex CLI: 0.136.0
  • Host: Windows native agent / PowerShell
  • Date observed: 2026-06-02 JST

What I did

  1. Fully exited Codex Desktop.
  2. Opened Codex from the Start menu using Run as administrator.
  3. Approved the UAC prompt.
  4. In the newly opened Codex session, checked the current token and the running Codex / codex processes.

Actual result

The Codex session still reports a non-admin token:

User            : <redacted>\<redacted>
IsAdministrator : False
ComputerName    : <redacted>

Every visible Codex process also reports Elevated=False, including the Desktop app process and bundled agent processes:

Codex.exe  -> Elevated=False  C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\Codex.exe
codex.exe  -> Elevated=False  C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
codex.exe  -> Elevated=False  C:\Users\<redacted>\AppData\Local\OpenAI\Codex\bin\7dea4a003bc76627\codex.exe

This was after the user explicitly launched from the Start menu with Run as administrator and approved UAC.

Related observations

  • Direct Start-Process -Verb RunAs against the WindowsApps Codex.exe path fails with access denied from a normal PowerShell context. That may be expected for direct MSIX executable launching, but it makes shortcut/batch based admin relaunches unreliable.
  • With C:\Users\<redacted>\.codex\config.toml set to:
[windows]
sandbox = "elevated"

codex exec --sandbox workspace-write failed with:

windows sandbox: spawn setup refresh

Changing it to:

[windows]
sandbox = "unelevated"

made the same workspace-write CLI/runner canary pass again. That works around normal non-admin CLI work, but does not solve the Desktop app not inheriting/admin-spawning an elevated token.

Expected result

This matches the Windows docs expectation that launching Codex via Run as administrator should let the agent inherit that permission level. If the MSIX/Start-menu admin path cannot actually provide a high-integrity token to the app/server/agent shell, the app should surface that clearly instead of appearing to accept the elevated launch path while all spawned agent processes remain medium integrity.

amatsuki5032 · 1 month ago

Follow-up after reinstall:

The user reinstalled the Codex Desktop app from Microsoft Store / Marketplace. The app package updated from:

OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0

to:

OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0

After reinstall, the user again launched Codex from the Start menu using Run as administrator and approved UAC. The newly opened Codex session still reports:

IsAdministrator: False

and all observed Codex / codex processes are still Elevated=False.

So, at least on this machine, reinstalling/updating the MSIX package to 26.527.7698.0 did not fix the issue.

amatsuki5032 · 1 month ago

Additional debugging found a working workaround and narrows the failure boundary.

What does not work on this machine

  • Start menu -> Codex -> Run as administrator -> UAC approval
  • AppsFolder shell verb / runas activation

Those paths still produce a Codex session with IsAdministrator: False and all observed Codex / codex processes at medium integrity.

What does work

Launching an elevated PowerShell first, then starting the MSIX package executable directly from that already elevated token:

$pkg = Get-AppxPackage -Name OpenAI.Codex
$exe = Join-Path $pkg.InstallLocation 'app\Codex.exe'
Get-Process Codex,codex -ErrorAction SilentlyContinue | Stop-Process -Force
Start-Process -FilePath $exe -ArgumentList @('--do-not-de-elevate')

With this flow, the Codex session reports:

IsAdministrator: True

and the relevant Codex.exe / codex.exe app-server processes are observed with Elevated=True. Electron child processes such as renderer/GPU may still show Elevated=False, but the main app/server/agent shell path is elevated and admin-only commands such as fltmc succeed from the Codex session.

Interpretation

This suggests the issue is specifically in the Start-menu / AppsFolder / MSIX activation route for Run as administrator, not in Codex's ability to run elevated once app\Codex.exe is launched from an already elevated token.

A practical workaround is a two-stage launcher:

  1. non-elevated shortcut/batch starts powershell.exe -Verb RunAs
  2. the elevated PowerShell stops existing Codex processes
  3. it launches %InstallLocation%\app\Codex.exe --do-not-de-elevate directly

This worked on the affected machine after reinstalling/updating Codex Desktop to 26.527.7698.0.

JoeyGennaro · 1 month ago

I was running into exactly the same issue. Starting Codex from the Start menu -> right click -> run as admin -> all processes spawned by the runner with medium integrity instead of high -> all conceivable actions blocked by our group policy (appropriately so)

Using the two-stage launcher as the practical workaround works for me as well. Thank you so much.

jlj001031 · 1 month ago

I encountered the same issue, and the operation behavior was the same as above. In previous versions, if you ran Codex with administrator privileges, subsequent privilege escalation operations didn't require manual UAC confirmation. But after updating to the latest version, each privilege escalation requires manual UAC confirmation, which is very unfriendly for developers. I hope this is fixed soon. Thanks !

Tuo-Luo · 1 month ago

I opened #28107 with additional diagnostics for this same elevated-launch / medium-integrity tool-shell problem.

The new details there are:

  • Same Codex Desktop version 26.609.4994.0: Windows 10 stays Full / High, while Windows 11 transitions to Limited / Medium.
  • A Windows 11 launch timeline where an initial Codex.exe appears as Full / High, then a --no-startup-window --do-not-de-elevate Codex.exe appears as Limited / Medium before codex.exe app-server starts.
  • A working workaround: use an external elevated Start Menu launcher/helper that terminates old Codex processes and starts Codex.exe --do-not-de-elevate, after which Codex.exe, codex.exe app-server, node_repl.exe, and the tool shell all remain Full / High on Windows 11.
ZaunEkko · 1 month ago

Additional reproduction on a newer Microsoft Store build. This is the same machine/details I also posted on #28107: https://github.com/openai/codex/issues/28107#issuecomment-4714594390

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

This repro is slightly different from the earlier workaround comments here: on this machine, even the two-stage launch path did not preserve elevation.

Tested launch flow:

  1. Start an elevated PowerShell via UAC.
  2. Confirm the helper PowerShell is elevated.
  3. Launch the packaged app executable directly:
$pkg = Get-AppxPackage OpenAI.Codex
$exe = Join-Path $pkg.InstallLocation 'app\Codex.exe'
Start-Process -FilePath $exe

The helper log confirmed the launcher itself was elevated and Start-Process succeeded:

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

After launch, the Store-package Codex 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

But token checks 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

I also checked the package manifest capabilities for this build. It declares:

runFullTrust
unvirtualizedResources
internetClient

I did not see allowElevation.

So on this Windows 11 / Store build, the Start Menu admin path does not produce an elevated agent, and launching app\Codex.exe from an already elevated helper process also still results in a medium/non-elevated Codex Desktop + app-server process tree.

PrzemyslawKlys · 1 month ago 
$pkg = Get-AppxPackage -Name OpenAI.Codex
$exe = Join-Path $pkg.InstallLocation 'app\Codex.exe'
Start-Process -FilePath $exe -ArgumentList @('--do-not-de-elevate')

Still works fine. You need to provide the do-not-de-elevete argument