Codex Windows Mouse Lag but No taskkill Storm? Check WMI

If Codex Desktop makes the mouse, typing, and other Windows apps stutter but taskkill.exe is not accumulating, check for repeated PowerShell and WMI process snapshots. Current reports describe a pre-storm pattern in which Codex repeatedly queries Win32_Process and Win32_PerfFormattedData_PerfProc_Process, sometimes around once per second. Fully exit Codex, update the app, reproduce with one short task, and compare a quiet process baseline with the affected run. Do not patch app.asar, disable WMI, kill WmiPrvSE.exe, or copy a version-specific launcher from a forum.

Start in an external PowerShell window, not inside the lagging Codex task:

$tracked = 'ChatGPT', 'Codex', 'codex', 'powershell', 'pwsh', 'git', 'conhost', 'taskkill', 'WmiPrvSE'

Get-Process -Name $tracked -ErrorAction SilentlyContinue |
  Group-Object ProcessName |
  Sort-Object Count -Descending |
  Select-Object Count, Name

Expected result: one read-only snapshot of the relevant process counts. A few Electron, console-host, or PowerShell processes can be normal. The useful signal is a repeatable burst tied to Codex opening, switching tasks, or running a command.

Match the Exact Failure Pattern

This guide applies when several signals appear together:

• mouse movement or typing stalls across Windows, not only inside Codex;

• lag begins after Codex opens or gets worse while a task runs;

• short-lived powershell.exe or conhost.exe processes keep appearing;

• WMI Provider Host becomes active or WMI Activity event 5858 names Win32_Process or Win32_PerfFormattedData_PerfProc_Process;

• taskkill.exe stays at zero or does not grow into a backlog; and

• closing Codex stops new bursts, even if Windows takes a few seconds to recover.

Use a different diagnosis when hundreds of taskkill.exe and conhost.exe processes accumulate. That is the later cleanup-storm pattern covered by Fix Codex Windows High CPU: taskkill.exe and WMI. If LSASS handles or Windows logon sessions grow during sandboxed commands, use the resource-leak branch in the Codex Windows sandbox error guide.

Current public reports do not establish one universal cause for every Codex input-lag incident. Other reported branches include Git review process bursts, long conversation rendering, browser or GPU crashes, USB/HID discovery, oversized local state, and workspace disk pressure. Diagnose the observed process path before choosing a workaround.

Prerequisites

Before testing:

1. Save open work and stop any Codex task whose output you need.

2. Record the desktop app version from Settings > About and the Windows build from winver.

3. Close unrelated terminals, IDE agents, and automation that could create PowerShell or Git processes.

4. Use a short disposable or clean repository for the control run.

5. Keep the test to one Codex task and one minute. Do not stress an already unstable machine.

Record the installed Store package when available:

Get-AppxPackage '*Codex*', '*ChatGPT*' |
  Select-Object Name, Version, Status, InstallLocation

Expected result: the package name, version, status, and install location are captured for the report. If both old and new packages appear, also record which executable Task Manager shows during the reproduction.

Step 1: Take a Quiet 30-Second Baseline

Fully quit Codex from the app or system tray. Wait ten seconds, then run:

$tracked = 'ChatGPT', 'Codex', 'codex', 'powershell', 'pwsh', 'git', 'conhost', 'taskkill', 'WmiPrvSE'

$samples = 1..30 | ForEach-Object {
  $capturedAt = Get-Date
  Get-Process -Name $tracked -ErrorAction SilentlyContinue |
    Group-Object ProcessName |
    ForEach-Object {
      [pscustomobject]@{
        CapturedAt = $capturedAt
        Name = $_.Name
        Count = $_.Count
      }
    }
  Start-Sleep -Seconds 1
}

$samples |
  Group-Object Name |
  ForEach-Object {
    [pscustomobject]@{
      Name = $_.Name
      Minimum = ($_.Group.Count | Measure-Object -Minimum).Minimum
      Maximum = ($_.Group.Count | Measure-Object -Maximum).Maximum
    }
  } |
  Sort-Object Name

Expected result: a quiet range for each process name. The PowerShell window running the sampler counts toward the baseline, so compare the change between runs rather than treating one process as suspicious.

Step 2: Reproduce Once With One Short Task

Open Codex and a clean repository. Start one new task with a bounded instruction such as:

Run one read-only command that prints the current directory, report the result, and stop

While the task runs, repeat the same 30-second sampler from the external PowerShell window.

Expected result on a healthy build: any helper processes exit quickly and the counts return to the quiet range. A repeating increase in powershell, conhost, or WmiPrvSE that aligns with visible input stalls supports the process-snapshot branch. A rising taskkill count means you should stop and use the cleanup-storm guide instead.

Do not run ten parallel tasks to make the signal louder. One issue report measured roughly 1.2 to 1.3 short-lived PowerShell children per second, while another found much larger descendant bursts after older tasks accumulated. Those are observations from specific builds and machines, not a safe target or universal rate.

Step 3: Check WMI Activity Errors Once

Windows records WMI provider failures in the WMI Activity operational log. Query only the bounded test window:

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

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-WMI-Activity/Operational'
  Id = 5858
  StartTime = $startedAt
} -ErrorAction Stop |
  Where-Object {
    $_.Message -match 'Win32_Process|Win32_PerfFormattedData_PerfProc_Process'
  } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Expected result: matching event timestamps can be compared with the lag window. One August 3 report captured event 5858 about three seconds after Codex logged a failed child-process snapshot. No matching event does not rule out successful WMI polling, because event 5858 records a failure path rather than every query.

Do not run Get-CimInstance Win32_Process in a tight loop while diagnosing WMI pressure. The diagnostic query itself uses WMI and can add noise.

Step 4: Separate the Main Windows Lag Branches

Use the smallest matching branch:

Expected result: the problem is assigned to one observed branch before any configuration is changed. Multiple branches can coexist, but one process count should not be used to prove all of them.

Step 5: Update and Retest the Same Control

Install the latest Codex or ChatGPT desktop app through its normal update path or Microsoft Store. Reboot only if Windows or the installer requests it, then verify the version again.

Repeat the quiet baseline and the same one-command task. Keep the repository, prompt, and sampling window unchanged.

Expected result: the updated build stays near the quiet process range and input remains responsive. Issue 36025 reported the WMI snapshot failure on Microsoft Store builds through August 3, including build 26.727.6591.0, so an update is a required check rather than proof that the current regression is fixed.

Step 6: Contain the Lag Without Patching the App

If the exact updated build still reproduces:

1. Stop the current Codex task normally.

2. Fully quit the desktop app and confirm its process group exits.

3. Save the before-and-after counts, event timestamps, package version, and one short reproduction.

4. Use the Codex CLI or VS Code extension for bounded work if that surface does not reproduce on your machine.

5. Keep parallel tasks paused until the desktop control stays responsive.

6. Add the sanitized evidence to the closest existing Codex issue instead of opening a vague duplicate.

Expected result: no new helper bursts are created while the desktop app is closed, and work can continue through a tested surface. Switching surfaces is containment, not a claim that the desktop bug is fixed.

Do not edit or repack the signed Store application, patch app.asar, inject a module stub, disable Windows Management Instrumentation, terminate WmiPrvSE.exe, or restart Desktop Window Manager. Social posts describe version-specific interventions, but they do not establish a safe general fix and can hide the evidence maintainers need.

Step 7: Capture a Short WPR Trace Only When Needed

If the lightweight checks are inconclusive and support asks for a trace, Windows Performance Recorder can capture a bounded CPU and process timeline. Run an elevated PowerShell window:

wpr -status

If no recording is already active:

wpr -start CPU.light
# Reproduce the lag once for 30 to 60 seconds.
wpr -stop "$env:USERPROFILE\Desktop\codex-input-lag.etl" "Codex input lag reproduction"

Expected result: one ETL file on the desktop. Do not start a second WPR session when another recording is active. Review the trace-sharing policy first because ETL files can expose process names, paths, timing, and other local metadata.

Microsoft documents that WPR memory mode is bounded by its recording buffers, while file mode can grow until it fills the disk. The commands above intentionally avoid -filemode for a short reproduction.

Common Failure Modes

Why This Diagnostic Works

The mouse-lag symptom is broad, but the process boundary is measurable. A quiet baseline shows ordinary Windows and PowerShell activity. The one-task control tests whether Codex adds recurring helpers at the same timestamps as the stalls. Event 5858 can then corroborate a failed WMI snapshot without turning the diagnostic into another WMI polling loop.

This follows the useful structure behind Aident's Ollama networking guide: use the exact problem wording, answer early, test one boundary, state the expected result, and separate neighboring failure modes.

Verify One Hosted Action With Codex Desktop Closed

If the desktop app is under containment, Aident Loadout can execute an integration Action without reopening the Codex desktop process tree. Use the installed public aident CLI in a normal terminal:

aident account auth status
aident vault vault --action status

$action = 'composio:github_tools:github_search_github_graphql'
$inputObject = @{
  query = 'repo:openai/codex is:issue "WMI" "Windows"'
  type = 'ISSUE'
  first = 5
}
$inputJson = $inputObject | ConvertTo-Json -Compress

aident capabilities get $action
aident capabilities preflight $action --input $inputJson
aident capabilities execute $action --input $inputJson

Expected result: authentication and Vault status pass, the current Action schema is inspected, preflight accepts the bounded read-only query, and up to five issue records return while Codex Desktop remains closed. No provider credential should be copied into the prompt and no repository file should change.

Use Aident Loadout to complete that one hosted read-only Action. Measure success as one verified result, zero local desktop helper bursts, and a clean repository diff.

Sources

• System-wide mouse and input lag from repeated PowerShell WMI process snapshots, OpenAI Codex issue, opened July 29, 2026 and updated August 3, 2026

• Windows Codex Desktop performance discussion, OpenAI Codex discussion, opened June 25, 2026

• Codex Desktop input lag despite clean logs and disabled plugins, OpenAI Codex issue, opened June 19, 2026

• Windows standalone app triggers WMI Provider Host at high CPU, OpenAI Codex issue, opened July 18, 2026

• Windows desktop project actions trigger CPU spikes and WMI failures, OpenAI Codex issue, opened July 22, 2026

• Insane performance issues with the Codex app, r/codex, posted July 27, 2026

• Severe Codex Windows app lag and system-wide mouse freezing, r/codex, posted July 16, 2026

• Get-WinEvent, Microsoft, accessed August 3, 2026

• Windows Performance Recorder command-line options, Microsoft, accessed August 3, 2026

• Process Explorer, Microsoft Sysinternals, accessed August 3, 2026

Refresh this guide when Codex changes desktop process discovery, WMI sampling, Git review scans, optional device discovery, task cleanup, or the Windows app update path.