›_ Codex Issues
Codex Issues / #22912

Windows desktop freezes while electron-sampler fails WMI process snapshots in sandbox

Open 💬 6 comments Opened May 15, 2026 by iAxvleda
💡 Likely answer: A maintainer (chess-oai, contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex Desktop 26.506.3741.0 from the Windows MSIX package path:

OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0

What platform is your computer?

Microsoft Windows [Version 10.0.26200.8457]

What issue are you seeing?

Codex Desktop repeatedly freezes/stalls for a few seconds during normal UI interaction, including sending a message, streaming a response, moving the app window, and resuming/opening threads.

This still happens after reinstalling Codex Desktop and after disabling a previously active heartbeat automation. It also reproduces when no custom pet/avatar is active, so this does not appear to be a custom pet rendering/cache issue.

The app logs repeatedly show electron-sampler failing to collect a child process snapshot. The command it runs uses PowerShell/WMI, and it fails inside the Codex Windows sandbox with access denied.

Representative redacted log excerpt:

warning [electron-sampler] Failed to collect child process snapshot
errorMessage="Command failed: powershell.exe -NoProfile -NonInteractive -Command
$ErrorActionPreference = 'Stop';
$cpuByPid = @{};
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process |
  ForEach-Object { $cpuByPid[[int]$_.IDProcess] = [double]$_.PercentProcessorTime };
Get-CimInstance Win32_Process |
  Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,
    @{Name='CpuPercent';Expression={$cpuByPid[[int]$_.ProcessId]}},
    @{Name='AgeSeconds';Expression={[int]((Get-Date) - $_.CreationDate).TotalSeconds}} |
  ConvertTo-Json -Depth 2
"

Get-CimInstance : Zugriff verweigert.

Running the same WMI checks from a normal user PowerShell session succeeds. Running them from the Codex sandbox user fails. The sandbox command context reports the user as:

<HOST>\CodexSandboxOffline

The local Windows groups Leistungsüberwachungsbenutzer / Performance Monitor Users and Leistungsprotokollbenutzer / Performance Log Users were empty, which likely explains why CodexSandboxOffline cannot read those WMI classes.

Additional observations

The same sessions also show long thread/resume / metadata operations around the freezes, for example:

method=thread/resume conversationId=<redacted> durationMs=58400 errorCode=null
method=thread/goal/get conversationId=<redacted> durationMs=58558 errorCode=-32600
error={"code":-32600,"message":"goals feature is disabled"}

method=thread/metadata/update conversationId=<redacted> durationMs=47839 errorCode=null

That may be separate from the sampler issue, but both show up around the observed stalls.

Related: #21774 mentions later sampler warnings after a Windows desktop restart, but this issue is specifically about recurring UI freezes/stalls while electron-sampler repeatedly fails WMI process snapshots from the Windows sandbox context.

Steps to reproduce / local checks performed

  1. Start Codex Desktop on Windows with the default/elevated Windows sandbox configuration.
  2. Use the app normally: open/resume threads, send a message, move the window, wait for a streamed response.
  3. Observe repeated short UI freezes.
  4. Check Codex logs under %LOCALAPPDATA%\Codex\Logs.
  5. Observe repeated electron-sampler warnings with the WMI Get-CimInstance command above.
  6. Verify that the same WMI command succeeds outside Codex's sandbox but fails from the sandboxed CodexSandboxOffline context.

Expected behavior

Codex Desktop should not freeze because a diagnostic/sampling command cannot access WMI process counters from the sandbox. If WMI access is unavailable, the sampler should either skip that data source, handle access denied cheaply, or avoid running the command from a sandbox token that lacks the required rights.

Actual behavior

The app repeatedly attempts the WMI process snapshot from the sandboxed context, logs access-denied failures, and the desktop UI freezes/stalls intermittently.

View original on GitHub ↗

6 Comments

SergeyPomelov · 1 month ago

Still reproducible on Codex Desktop 26.707.9981.0 on Windows 10.

Symptoms: the desktop UI intermittently stalls for several seconds, including keyboard input lag. Other apps remain responsive. Especially after returning to working with its window after a time.

Codex logs repeatedly show:
[electron-sampler] Failed to collect child process snapshot

The failing sampler invokes PowerShell Get-CimInstance Win32_Process / Win32_PerfFormattedData_PerfProc_Process.

At the time of sampling, Codex was not under sustained local load:

yamamoto-koki414 · 1 month ago

Same symptom on Windows 11 ARM64, native arm64 build (not emulated).
Adding quantified data since this thread lacks measurements.

Environment

  • Codex desktop 26.715.4045.0 (arm64, MSIX), Electron/Chromium 150.0.7871.124
  • Workspace bundle stuck at 26.614.11603 (mismatched with app version)
  • Snapdragon X Plus 8-core / Adreno X1-45 (31.0.133.1)
  • Windows 11 build 26200, single 1920x1280 display, on AC power
  • Verified native arm64 via IsWow64Process2 (no emulation)

Measured behavior (0.6s sampling, 100 samples, repeated 3x)

  • Main process Responding=False for 32-40% of wall time
  • Cycle: ~14s period, ~5s hang duration, occurs while completely idle
  • During hang: CPU 0%, disk I/O 0MB, threads drop 59 -> 54
  • Thread waits: UserRequest 35 / EventPairLow 11 / Unknown 8
  • Resource Monitor "Analyze Wait Chain" returns empty

(not blocked on another process or lock)

  • Zero suspended threads (rules out PLM / power throttling)

Control test (same time window, Responding=False rate)
ChatGPT.exe 32% | chrome 0% | explorer 0% | claude 0%
-> Codex-specific, not a system-wide stall.

Re: the WMI/electron-sampler root cause in this issue
I confirmed CodexSandboxOffline and CodexSandboxOnline existed on my
machine and that Performance Monitor Users was empty. I added both
accounts to that group, fully restarted, and re-measured:

before: 32% / 38% after: 40%

No improvement. The electron-sampler WMI failure also appears only
2x in my logs, which does not match the ~14s freeze cycle. So the WMI
access-denied issue may be a symptom rather than the root cause here.

Separate but concurrent defect: runtime distribution is broken

  • install-primary-runtime retries every 30s forever:

Failed to download primary runtime manifest (404 Not Found)

  • Settings -> Configuration -> Reinstall fails:

"Could not reinstall Codex dependencies"

  • Yet "Diagnose" reports "Codex dependencies are healthy" (inconsistent)
  • Result: bundle cannot update off 26.614

Ruled out (no effect)
GPU compositing disabled, plugins disabled, right panel/browser closed,
MCP servers removed (npx-based slack), OneDrive (not running, 0 placeholders),
Defender (0% CPU during hang), DNS/network (22-453ms; main process holds
no sockets), settings reset, reinstall, reboot.

Note: editing [windows] sandbox in config.toml is futile — the app
appends the key back at the end of the file on every launch, and it is not
exposed in the settings UI.

florentseiler · 1 month ago

Reproduced on Codex Desktop 26.715.4045.0, Windows x64 (MSIX), with an additional user-visible symptom: a PowerShell console window briefly appears on the desktop and can steal focus during normal Codex use.

Local evidence

  • Live process tree during the popup: ChatGPT.exe (Codex Desktop main process) → powershell.exe → conhost.exe.
  • The PowerShell command line matches the sampler command reported here: Get-CimInstance Win32_PerfFormattedData_PerfProc_Process followed by Get-CimInstance Win32_Process and JSON conversion.
  • The active Codex log records repeated [electron-sampler] Failed to collect child process snapshot warnings containing that exact command.
  • Read-only inspection of the packaged desktop code shows a 30-second sampler heartbeat on Windows that invokes the PowerShell/WMI worker while the primary window is focused.
  • Custom hooks and an MCP server that previously launched PowerShell directly had already been moved behind a no-window launcher and the app was restarted. The popup still recurred, with the process parent confirmed as the Codex Desktop main process, so this occurrence is independent of those custom launchers.

No supported local configuration switch for this sampler was found. I did not modify the signed app package, replace PowerShell, alter PATH, or add broad system restrictions.

Expected handling

On Windows, the sampler's PowerShell child should be created with windowsHide: true / CREATE_NO_WINDOW (or replaced with a console-free API). If WMI access repeatedly fails, sampling should degrade or stop instead of repeatedly creating a visible console host.

Local usernames, paths, process IDs, thread IDs, and conversation content have been intentionally omitted.

wsyzsfxq · 1 month ago

Reproduced on Codex Desktop 26.715.7063.0, Windows x64 (MSIX) with bundled app-server 0.145.0-alpha.18.

This occurrence differs from the original access-denied case:

  • The WMI calls do run, but then fail with 0x80041006 / "Not enough memory" after the WMI provider becomes resource-exhausted.
  • The impact is system-wide rather than only an intermittent Codex UI stall: WmiPrvSE.exe stays at high CPU and the whole desktop becomes sluggish. Fully exiting Codex restores normal behavior.
  • One affected WMI provider instance reached approximately 540 MB working set, 298 threads, and 515 seconds of accumulated CPU time.
  • The Codex desktop log recorded 25 [electron-sampler] Failed to collect child process snapshot warnings in about five minutes. The failing commands were the same Get-CimInstance Win32_Process and Win32_PerfFormattedData_PerfProc_Process queries reported above.
  • During the failure, hundreds of taskkill.exe processes and matching conhost.exe children accumulated. The cleanup helpers were descendants of the main ChatGPT.exe process.

Read-only inspection of the packaged desktop code shows a 30-second sampler heartbeat, additional active/focused sampling rate-limited to roughly five seconds, and a five-second timeout for the Windows WMI worker. The Windows process-tree cleanup path invokes taskkill.exe /pid <pid> /t /f.

The observed failure sequence is therefore consistent with a feedback loop:

electron-sampler WMI snapshot
-> WMI query stalls/fails
-> more sampler/cleanup workers
-> taskkill enumerates the process tree through WMI
-> WMI provider becomes further overloaded

This appears to connect the sampler failure reported here with the cleanup storms in #34025 and #34260.

Suggested handling: after repeated WMI failures, back off or disable process sampling for the session; also bound the concurrency and lifetime of Windows taskkill cleanup helpers.

Local usernames, paths, repository names, conversation IDs, and raw logs have been omitted.

wsyzsfxq · 1 month ago

Additional reproduction detail: a very large image-heavy thread appears to be a reliable trigger/amplifier for this WMI failure.

Thread characteristics

The affected Codex thread's local rollout file is 178.6 MB:

  • 26 records contain embedded data:image / image_url payloads.
  • Those image-bearing records account for approximately 93.5 MB.
  • 22 individual records are larger than 1 MB; the largest is about 12.7 MB.
  • The thread contains repeated image-generation/image-inspection results, long local tool runs, and four interrupted turns.

From a separate healthy thread, requesting the affected thread's latest 10 turns produced an internal response of 87,124,454 bytes, exceeding the observed 67,108,864-byte IPC frame limit. Reading one turn at a time works until reaching the image-heavy turn.

This IPC limit was observed in the cross-thread inspection path, so it is not necessarily the desktop UI's exact message limit. It does, however, provide direct evidence that a normal history page for this thread has become abnormally large.

Reproduction pattern

  1. Open/resume the affected image-heavy thread.
  2. Send even a short text message.
  3. Codex begins restoring/processing the thread.
  4. WmiPrvSE.exe thread count and CPU rise; the whole machine becomes sluggish.
  5. Fully closing Codex, or terminating only the overloaded WMI provider host, restores responsiveness.

During a read-only investigation from another thread, a newly created WMI provider host grew from 11 to 233 threads before sustained CPU usage began. After terminating only that abnormal provider instance, Windows created a replacement with 10 threads and no taskkill.exe backlog.

Working interpretation

The large thread does not directly call WMI. The evidence suggests that thread rehydration/serialization and the associated local-tool/process activity create a trigger condition that the Electron process sampler then amplifies through repeated WMI process snapshots. Interrupted tool turns and process-tree cleanup may further amplify it.

This connects two failure modes:

oversized image-heavy thread is resumed
-> expensive history rehydration / IPC pressure / local process activity
-> electron-sampler repeatedly snapshots child processes through WMI
-> WMI provider thread/resource growth
-> sampler and cleanup failures
-> system-wide lag

The same task can be continued safely from its on-disk artifacts in a new clean thread; continuing to send messages in the oversized thread repeatedly reproduces the problem.

Suggested safeguards

  • Store generated/viewed images by file reference instead of duplicating Base64 payloads in thread history.
  • Lazy-load or paginate large tool/image outputs during thread resume.
  • Chunk IPC responses instead of creating a single frame above the transport limit.
  • Stop or back off the Electron sampler when WMI queries time out or the provider thread count grows abnormally.
  • Avoid carrying large tool outputs into a forked/copied thread; provide a compact handoff instead.

No usernames, local paths, prompts, repository names, or image contents are included here.

chess-oai contributor · 23 days ago

thanks for the detailed reports and investigation here: they were really helpful 💖

  • we’ve shipped fixes in 26.730.7989.0 that address some major sources of powershell/wmi storms
  • taskkill.exe can still be started by other process-cleanup paths, and we’re continuing to work on reducing that separately

if you’re still seeing sustained wmi cpu usage or system-wide lag after 26.730.7989.0, please share an updated /feedback id