Windows: codex sandbox leaks one logon session per invocation (lsass grows until reboot)

Open 💬 5 comments Opened Jul 29, 2026 by Darkplates

`codex sandbox` leaks one Windows logon session per invocation

Reporter: Pedro Bento
Platform: Windows 11 Pro 26200
Versions affected: codex-cli 0.144.3 and 0.146.0 (both measured)

Summary

On Windows, every codex sandbox invocation creates an interactive logon
session for the CodexSandboxOffline sandbox account and never releases it.
The sessions accumulate inside lsass.exe for the lifetime of the boot. Because
lsass cannot be restarted, the only way to reclaim them is a reboot.

After 23 hours of automated use this machine held 15 510 orphaned logon
sessions and lsass had grown to 79 396 handles. The symptom is
progressive, whole-desktop slowness — dragging, minimising and maximising
windows become visibly laggy — that persists after every Codex process has
exited and disappears only on reboot.

codex exec does not leak. Only codex sandbox does.

Evidence

Security event 4624 for the leaked sessions:

LogonType                 2   (Interactive)
LogonProcessName          seclogo          (Secondary Logon service, in svchost)
AuthenticationPackageName Negotiate
TargetUserName            CodexSandboxOffline

The sessions are orphaned — enumerating Win32_LogonSession and associating to
Win32_Process returns no process for any of them. No process on the machine
holds a comparable handle count, so nothing but lsass is retaining them:

lsass     79 396 handles
System    22 068
explorer   8 253
codex       3 296

Not a profile-hive leak: HKEY_USERS holds 6 keys and no C:\Users\CodexSandbox*
profile directories exist.

Reproduction

function N { (Get-CimInstance Win32_LogonSession).Count }
$before = N
1..20 | ForEach-Object {
  codex sandbox -P :workspace -c windows.sandbox="elevated" -- cmd /c exit 0
}
"leaked: $((N) - $before)"

Measured with paired idle blocks before and after to subtract background:

| version | mode | leaked per invocation |
|---|---|---|
| 0.144.3 | elevated | 0.9 – 1.5 |
| 0.146.0 | elevated | 0.66 |
| 0.144.3 / 0.146.0 | unelevated | 0 |

A short 6-invocation run can read as zero — the measurement needs enough
invocations, and idle control blocks on both sides, to clear the noise.

codex exec --sandbox workspace-write -c windows.sandbox="elevated" running a
shell command leaks nothing, which is what makes the asymmetry look like a
missing handle close on the codex sandbox path specifically rather than in
sandbox setup generally.

Why `unelevated` is not a workaround

unelevated does not leak, but on both versions it:

leaves the network reachable even with --sandbox-state-disable-network

(a TCP connect to 1.1.1.1:443 succeeds inside the sandbox), and

kills child processes created with piped stdio —

node -e "require('child_process').execSync('node -v', {stdio:'pipe'})"
fails with spawnSync ... EPERM, which breaks node --test and similar
runners.

elevated blocks the network correctly (EACCES) and allows piped spawns, so
it is the only usable mode — and it is the one that leaks.

Impact

Any automated use that invokes codex sandbox per command accumulates this
quickly. At roughly 668 sessions/hour on this workload the machine reaches
five figures within a day, and the degradation is indistinguishable from a
general "Windows is slow" problem, which makes it very hard to attribute. It
took a full day of elimination — GPU, VRAM, DWM, MPO, GDI handles, disk,
memory pressure — before the logon-session count was measured.

Expected

codex sandbox should release the logon session it creates when the sandboxed
command exits, or reuse a single session across invocations.

View original on GitHub ↗

5 Comments

Darkplates · 1 month ago

Cross-referencing: this is very likely the same underlying defect as #33356
(handle growth per sandboxed command), and probably related to #34062 (profile
load per command) and #34575 (lost logon session / error 1312). Maintainers may
want to consolidate.

What this report adds beyond #33356 is the mechanism and the accounting: the
growth is one logon session per codex sandbox invocation, created through
the Secondary Logon service (event 4624, LogonProcessName seclogo, target
CodexSandboxOffline) and never released, which is why the handle count in
lsass tracks it at roughly 5 handles per session and why only a reboot clears
it. It also isolates the asymmetry — codex exec running shell commands does
not leak, only codex sandbox does — which should narrow where the missing
release is.

Darkplates · 29 days ago

Follow-up with a finding that should help reproduction: the leak is
state-dependent, not constant.

After a reboot cleared the 15 510 accumulated sessions, the same
measurements that reliably leaked before now leak nothing:

8 × codex sandbox -P :workspace -c windows.sandbox="elevated" on the

fresh boot: 0 sessions leaked (pre-reboot: the same batch leaked 5-12).

One hour of automated workload (BENTO queue, 9 concurrent tasks, including

10 sandbox invocations): 0 sessions leaked, lsass steady around
1 500-3 000 handles. Pre-reboot the same workload leaked 668-1080/hour.

So a fresh lsass releases the CodexSandboxOffline logon sessions
correctly, and something later tips it into never releasing them; once that
happens, every launch strands one session and only a reboot recovers. The
trigger is what I cannot isolate from outside -- uptime, a session-count
threshold, or some failed cleanup that flips the behaviour. The 22-hour
uptime figures in the original report describe the degraded regime.

Practical implication for anyone measuring: a short test on a fresh machine
will conclude "no leak" and be wrong an hour or a day later. Watching
(Get-CimInstance Win32_LogonSession).Count over time is the reliable
signal.

MajesticMug · 1 day ago

Bump

This is causing severe performance issues during long sessions and the only way to release those orphaned resources is through a PC restart.

This should be a higher priority!

Darkplates · 1 day ago

I will be honest about this: I am now running Codex on 2 different computers and both have the same issue - I'm LOVING codex with 5.6 sol Ultra.. but the ammount of subagents it calls for and the tasks they run... my new computer (5080 with ryzen 7 7800x3d, 32gb DDR5 6000) still needs to be restarted every 4-5 hours if I want to run Codex on ultra. I'm unclear how prevalent this bug is in codex CLI, but using Codex windows app I can guarantee it's unbearable.

I understand this might not be affecting all users, but I'm choosing to mantain an OpenAI first envoirement - Codex windows app is vital for this. And this should be something OpenAI should strive for, allowing a user to remain in their ecosystem. Right now I paid 3k€ for a new computer and I still need stop everything and restart every 6 hours if I want to avoid going down to 0.3-0.6 fps. It makes close to 0 sense, specially the lack of replies, considering this is an issue that has been raised in multiple tickets, from multiple people.