Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Codex Desktop launched elevated still spawns medium-integrity shell

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

$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 }

Root Cause

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.

Code Example

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

---

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

[windows]
sandbox = "elevated"

---

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

---

--do-not-de-elevate

---

$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

---

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

---

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

---

$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
}

---

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

---

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

---

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

---

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

---

sandbox_mode = "danger-full-access"

[windows]
sandbox = "elevated"
RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex Desktop launched elevated still spawns medium-integrity shell