Codex Sandbox Making Windows Slow? Check the LSASS Leak

If Windows becomes progressively laggy during a long Codex run, check whether lsass.exe handles and Windows logon sessions keep rising. Current Codex issue reports describe two related Windows sandbox leaks: repeated codex sandbox invocations can leave CodexSandboxOffline logon sessions behind, and sandboxed command execution can accumulate LSASS handles. Stop the high-frequency workload, update Codex, save your work, and reboot Windows to reclaim already orphaned state. Do not terminate LSASS, close its handles manually, or switch to danger-full-access just to hide the symptom.

Start with a read-only PowerShell snapshot:

$lsass = Get-Process -Name lsass

[pscustomobject]@{
  CapturedAt = Get-Date -Format o
  CodexVersion = (codex --version)
  LsassHandles = $lsass.HandleCount
  LsassWorkingSetMB = [math]::Round($lsass.WorkingSet64 / 1MB, 1)
  LogonSessions = @(Get-CimInstance Win32_LogonSession).Count
  CodexProcesses = @(Get-Process -Name codex -ErrorAction SilentlyContinue).Count
}

Expected result: one timestamped baseline with the Codex version, LSASS handle count, LSASS working set, total logon sessions, and running Codex process count. One high number does not prove a leak. Growth tied to a bounded Codex workload, followed by no recovery after Codex exits, is the stronger signal.

Match the Exact Failure Pattern

This guide applies when several of these signals appear together:

• desktop actions such as dragging, minimizing, or maximizing windows become slower over hours;

• Task Manager does not show an obvious Codex CPU or memory spike;

• lsass.exe handle count rises during sandboxed Codex commands;

• total Win32_LogonSession instances rise during repeated sandbox launches;

• Security event 4624 names CodexSandboxOffline when logon auditing is available;

• stopping every Codex process does not return the counts to baseline; and

• a reboot restores normal responsiveness.

Use a different diagnosis for a single slow tool call, CreateProcessAsUserW error 1312, spawn EPERM, a stuck codex-windows-sandbox-setup.exe, high GPU usage, disk pressure, or a network timeout. Those symptoms can coexist, but they are not proof of an LSASS or logon-session leak.

Two public reports also describe different execution paths. Issue 35940 measured roughly one orphaned logon session per direct elevated codex sandbox invocation and found no leak in its codex exec control. Issue 33356 measured roughly three to five LSASS handles per sandboxed command inside automated codex exec sessions. Treat them as related observations, not a universal rate for every Codex version and sandbox mode.

Prerequisites

Before measuring:

1. Save all work and note whether a reboot is acceptable during the maintenance window.

2. Record codex --version, Windows build, terminal, sandbox mode, and how Codex is launched.

3. Pause parallel agents and unrelated automation so the test has one bounded workload.

4. Use 64-bit PowerShell. Run as administrator only if your security policy allows it and a query requires elevation.

5. Do not run a stress loop on a machine that is already degraded.

Generate a redacted Codex diagnostic report:

codex doctor --json | Set-Content -Encoding utf8 codex-doctor.json

Expected result: the report identifies the Codex runtime, install method, Windows sandbox configuration, and app-server state. Redact usernames, local paths, organization details, and tokens before attaching it to an issue.

Step 1: Take a Quiet Baseline

Close Codex, its desktop app, IDE extensions, and automation workers. Wait until ordinary background activity settles, then take three samples about a minute apart:

1..3 | ForEach-Object {
  $lsass = Get-Process -Name lsass
  [pscustomobject]@{
    CapturedAt = Get-Date -Format o
    LsassHandles = $lsass.HandleCount
    LogonSessions = @(Get-CimInstance Win32_LogonSession).Count
  }
  if ($_ -lt 3) { Start-Sleep -Seconds 60 }
}

Expected result: small background variation rather than steady large growth. Save the output with the test notes. Microsoft documents Get-Process as returning process objects, including HandleCount, and Win32_LogonSession as the WMI class that describes Windows logon sessions.

Step 2: Measure One Normal, Bounded Codex Workload

Do not copy the 20-invocation public reproduction into a production machine. Instead, run one ordinary task that naturally uses your current sandbox for five to ten minutes. Keep the prompt, repository, model, and sandbox mode fixed. Take the same snapshot immediately before and after, then again five minutes after Codex exits.

Use a table like this:

Expected result: counts stay near the quiet baseline after the task. A repeatable upward step that remains after every Codex process exits supports the leak hypothesis. A short run may be noisy; issue 35940 notes that six invocations could appear flat, so compare natural longer workloads and idle controls rather than inventing a precise per-command rate from a small sample.

Step 3: Confirm the Sandbox Path

Record how the workload starts:

codex doctor --summary
codex --version
Get-Command codex -All

Classify it as one of these:

Expected result: the report names an exact executable, version, and sandbox path. If an IDE or desktop app uses another bundled runtime, test that surface separately.

Step 4: Check Event 4624 Only If Auditing Is Available

Microsoft documents Security event 4624 as the event created when a logon session is established. If your machine records these events and your policy permits reading the Security log, count recent entries that mention the sandbox account:

$startedAt = (Get-Date).AddMinutes(-30)

$sandboxLogons = Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id = 4624
  StartTime = $startedAt
} -ErrorAction Stop | Where-Object {
  $_.Message -match 'CodexSandboxOffline'
}

$sandboxLogons | Select-Object TimeCreated, Id, RecordId
"Sandbox logons: $($sandboxLogons.Count)"

Expected result: event timestamps can be compared with the bounded Codex workload. A localized Windows installation may format the message differently, and audit policy may omit the event. Missing events do not prove that no logon session exists; keep the CIM and handle measurements as the baseline.

Step 5: Update Before Choosing a Workaround

Run the supported self-update path:

codex update
codex --version
codex doctor --summary

If codex update says another package manager owns the installation, update with the manager reported by codex doctor. Open a new PowerShell window afterward and verify that Get-Command codex -All does not put an older executable first.

Expected result: the measured workload runs on the intended current build. Repeat the quiet baseline and one bounded task. Do not assume an update fixed the leak until the counts remain stable on the same test.

Step 6: Contain an Active Leak Safely

If LSASS handles or logon sessions keep climbing:

1. Stop the automation that repeatedly invokes the affected sandbox path.

2. Let the current Codex task finish or stop it normally.

3. Save all open work.

4. Capture the final counts, version, doctor report, and timestamps.

5. Reboot Windows during an approved maintenance window.

6. Measure a fresh post-reboot baseline before resuming any long run.

Expected result: the reboot returns LSASS handles and logon sessions near the machine's normal baseline and restores desktop responsiveness. The reboot contains accumulated state; it does not fix the underlying Codex path.

Do not terminate lsass.exe. Windows treats it as a critical security process. Do not use Sysinternals Handle or Process Explorer to close individual LSASS handles. Microsoft describes those tools as diagnostics; manually closing handles in a security process can destabilize the system.

Step 7: Choose the Least-Risky Temporary Operating Mode

There is no universal safe flag workaround in the current reports:

• danger-full-access avoided one handle leak but removes filesystem isolation;

• unelevated avoided one logon-session leak but the reporter found reachable networking and broken piped child processes;

• codex exec avoided the direct codex sandbox leak in one test, while a separate report measured a different LSASS handle leak inside sandboxed codex exec commands.

Prefer to pause high-frequency Windows automation, shorten bounded runs, use an approved isolated VM, or move the workload to a supported non-Windows runner until your exact updated build stays flat. If policy permits a temporary mode change, document the lost isolation, add compensating controls, and test it on a disposable repository before any real work.

Common Failure Modes

Why This Diagnostic Works

LSASS participates in Windows authentication and security operations. A sandbox path that repeatedly creates tokens or logon sessions without releasing their references can move the resource pressure into lsass.exe, so closing Codex does not remove the retained state. Measuring the security process and logon-session inventory before, during, and after one controlled workload separates this pattern from ordinary Codex memory usage or a graphics problem.

This uses the same repeatable structure that made Aident's Ollama networking guide useful: match an exact symptom, measure the boundary, change one variable, and state the expected result. For broader setup failures, use the Codex Windows sandbox error guide. If you need stronger isolation while waiting on a Windows fix, compare Codex and Claude Code in a Docker sandbox.

Run a Read-Only Integration Outside the Local Windows Sandbox

If a local Windows sandbox is under containment, Aident Loadout can execute an external integration through a separately authenticated hosted Action. Set it up by pasting:

Follow https://aident.ai/SETUP.md

Then use the public aident CLI to discover, inspect, preflight, and execute one read-only GitHub issue search:

$search = aident capabilities search `
  --query "search GitHub issues and pull requests" `
  --types '["action"]' | ConvertFrom-Json

$actionName = $search.data.results[0].data.name

aident capabilities get --name $actionName

$inputObject = @{
  q = '"lsass" repo:openai/codex is:issue'
  per_page = 5
  response_detail = 'minimal'
}
$inputJson = $inputObject | ConvertTo-Json -Compress

aident capabilities preflight --name $actionName --input $inputJson
aident capabilities execute --name $actionName --input $inputJson

Expected result: preflight validates read-only input and the execution returns current issue metadata with no GitHub write, no local sandbox launch, and no provider credential copied into the prompt. The measurable goal is one verified result through Aident Loadout, followed by a clean repository diff.

Sources

• OpenAI: Codex CLI command reference, accessed August 2, 2026

• GitHub: codex sandbox leaks one Windows logon session per invocation, opened July 29, 2026

• GitHub: Sandboxed exec leaks LSASS handles per command, opened July 15, 2026

• GitHub: Elevated sandbox helpers accumulate and busy-spin, opened July 10, 2026

• Microsoft: Get-Process, accessed August 2, 2026

• Microsoft: Win32_LogonSession class, accessed August 2, 2026

• Microsoft: Security event 4624, accessed August 2, 2026

• Microsoft Sysinternals: Handle, accessed August 2, 2026

Refresh this guide when Codex changes Windows sandbox token ownership, logon-session cleanup, codex sandbox, codex exec, or the elevated and unelevated sandbox contracts.