Codex Desktop on Windows flashes visible PowerShell/console windows during background process polling

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #25453

Powered by Codex Action

This is related to #25453, but it is not fully resolved for the visible-window symptom.

The user is on Codex Desktop OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0, which is newer than the 26.527.31326 version reported in #25453, and the issue still reproduces.

The likely shared root cause is the same PowerShell/CIM process polling path, but this report is specifically about child powershell.exe probes being created with a visible console window. Even if the polling interval/CPU behavior from #25453 has been improved, the Windows child-process creation path still needs hidden/no-window semantics for internal background probes.

So this can be treated as either:

• a remaining visible-console sub-bug under #25453, or
• a separate Windows Desktop UX/security-confidence bug caused by the same polling mechanism.

Update (2026-07-14): the related Git-window workaround is now a portable, maintained Windows project:

https://github.com/rwang23/codex-windows-console-guard

It now combines process-local Git/PowerShell/CMD wrappers with a narrowly scoped native console-window guard for MSIX activation paths that bypass the local PATH. The guard matches only Git console windows beneath either current ChatGPT.exe or legacy Codex.exe; it does not replace Git, modify persistent PATH, change the registry, or suppress unrelated terminals.

Scope remains important: this project mitigates the Git console-flash variant. It does not fix the PowerShell/CIM polling window in this issue, nor does it reduce the underlying polling CPU/process cost. Those still require a Codex Desktop no-window or persistent-native-helper fix upstream.

The README includes portable install, external restart, diagnostics, rollback, and agent instructions. I will keep compatibility updated when Windows desktop package/process behavior changes.

I have a small additional measurement from native Windows that may help separate the PowerShell polling symptom from the Git-specific churn.

Environment:

• Windows 11 Pro 10.0.26200
• Git 2.54.0.windows.1
• Codex Desktop active during the run
• Upstream source inspected: 63f009e9dad2e70454b7ed6434d8aa28dfb52b51

Process-start measurement:

• Non-admin polling mode, filtered to processes whose ancestry included Codex.exe or codex.exe.
• Polling likely undercounts very short-lived child processes, but it avoids counting unrelated system activity.

Observed in a 15s run:

• git.exe: 24 starts, 96/min
• conhost.exe: 29 starts, 116/min
• powershell.exe: 14 starts, 56/min

Observed in a 30s run:

• git.exe: 30 starts, 60/min
• conhost.exe: 51 starts, 102/min
• powershell.exe: 28 starts, 56/min

The sampled powershell.exe command lines included Get-CimInstance Win32_Process and Win32_PerfFormattedData_PerfProc_Process, which looks like process-tree or process-resource polling.

I searched the public Rust tree at the commit above for these strings:

• Get-CimInstance Win32_Process
• Win32_PerfFormattedData_PerfProc_Process
• ProcessId,ParentProcessId
• CpuPercent
• AgeSeconds

I did not find production matches under codex-rs. The only nearby PowerShell code I found was codex-rs/shell-command/src/command_safety/powershell_parser.ps1, which appears to be the long-lived AST parser path and does not match the sampled CIM/perf commands.

So my current read is:

• Git/untracked-diff amplification is a separate public-source patch target.
• This PowerShell/CIM polling path may live in the Desktop host/private integration or another runtime component outside the public Rust tree.
• If that is correct, the Windows-specific fix likely needs hidden/no-window process creation and/or replacing repeated short-lived PowerShell probes with a persistent/coalesced helper.

I am not opening any PR unless explicitly invited by a maintainer, per docs/contributing.md; this is just measurement data and a source-boundary note.

+1, reproduced on Windows 11 Pro (build 26200).

Affected versions on my machine:

• Codex Desktop app: OpenAI.Codex_26.623.4041.0_x64 (MSIX)
• ChatGPT/Codex VS Code extension: openai.chatgpt-26.616.41845

Repro: With the Codex desktop app running (even while idle), it continuously
spawns visible powershell.exe console windows. Each spawn allocates a conhost
console, so a black window flashes on the desktop roughly once a second.

Measured spawn rate: I sampled the process table and counted ~10 powershell
processes spawned in 12 seconds (≈1 every 1.2s), all parented to Codex.exe.

Exact command line being launched: powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; $cpuByPid = @{}; Get-CimInstance Win32_Process | Select ..."

(also a variant without $cpuByPid, just Get-CimInstance Win32_Process | Select ...)

So this is the desktop app's background process/CPU polling loop launching PowerShell
without CREATE_NO_WINDOW. To end users it looks exactly like malware activity.

No user-side workaround works. Removing the Windows Terminal console delegation
(HKCU\Console) does not help — the flashes persist. The only way to stop it is to
fully quit the Codex desktop app.

Please either pass CREATE_NO_WINDOW / set STARTUPINFO.wShowWindow = SW_HIDE when
spawning these helpers, or replace the per-second PowerShell polling with native
process-enumeration APIs (e.g. CreateToolhelp32Snapshot / NtQuerySystemInformation)
so it doesn't shell out to PowerShell at all.

I can reproduce this on a newer Codex Desktop build:

• Codex Desktop package: OpenAI.Codex_26.623.8305.0_x64__2p2nqsd0c76g0
• Platform: Windows
• Observed visible short-lived PowerShell/console flashes during normal Codex Desktop usage.
• Current process evidence shows powershell.exe launched under Codex.exe / codex.exe, running Get-CimInstance Win32_Process and Get-CimInstance Win32_PerfFormattedData_PerfProc_Process.
• The local packaged code appears to come from:

app/resources/app.asar!/.vite/build/child-process-snapshot-worker.js

Relevant packed snippet shows the worker uses execFile("powershell.exe", ["-NoProfile", "-NonInteractive", "-Command", ...], { windowsHide: true }).

So this does not look like a missing windowsHide option at the call site. It looks like hidden/no-window semantics are not consistently taking effect in this Windows Desktop runtime path.

Additional observed log symptom:

GetCimInstanceCommand sometimes fails with HRESULT 0x80041010 / Invalid class, while the visible console flash still occurs.

Impact: this is visually alarming because it looks like an unknown terminal or malware process briefly opening and closing, even when the user did not explicitly run a command.

Additional confirmation on a newer Windows Desktop build.

Environment:

• Codex package: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0
• OS: Windows 11 10.0.26100 x64 (Microsoft Windows 11 IoT Enterprise Subscription LTSC)
• Observed date/time: 2026-07-04, Asia/Taipei

Observed behavior:

While Codex Desktop was open, Task Manager repeatedly showed short-lived Windows PowerShell processes appearing and disappearing. The user-facing symptom was alarming because it looked like a hidden process continuously starting and closing.

A 15 second live process sample captured several transient powershell.exe children with parent Codex.exe; each appeared for a single sample and then exited. Representative captured command prefix:

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 -Filter ... | Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,... | ConvertTo-Json -Depth 2"

Another short-lived Codex-spawned probe observed immediately afterward:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2"

There was also a long-lived PowerShell child under the app-server process:

parent: codex.exe app-server --analytics-default-enabled
command shape: powershell.exe -NoLogo -NoProfile -NonInteractive -EncodedCommand ...

That one appears to be the command-safety/AST parser and is separate from the repeatedly appearing short-lived Codex.exe process-polling probes.

Impact:

• The repeated powershell.exe process creation is visible/noisy in Task Manager.
• It makes the app look suspicious to users because a shell process keeps appearing and disappearing while they are not intentionally running a command.
• It also causes nearby WMI Provider Host activity, consistent with the CIM polling command.

This still reproduces on 26.623.13972.0, so the visible PowerShell/background process polling issue appears to remain present in current Windows Desktop builds.

Same issue here on Windows 11 with Codex Desktop.

I see visible black console flashes during normal use, often near integer-minute boundaries around :07 / :08.

Windows PowerShell logs show short-lived powershell.exe ConsoleHost sessions running commands shaped like:

powershell.exe -NoProfile -NonInteractive -Command ... Get-CimInstance Win32_Process ... Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ... ConvertTo-Json

Local examples:

• 2026-07-06 17:30:00-17:30:02
• 2026-07-06 22:20:04-22:20:12

A live process sample showed powershell.exe parented by Codex.exe.

Impact: distracting black window flashes and intermittent mouse/keyboard stutter. This appears to match #25453 and this issue. Please prioritize hidden/no-window process creation or replacing this polling path with a persistent/native helper.

Follow-up from a Windows Desktop reproduction: the command-safety PowerShell parser has a ready CREATE_NO_WINDOW fix linked in #18984 (commit acc2ab3: https://github.com/ryanquadrel/codex/commit/acc2ab3b6c58b5c3d07ccd096d42dfb181d00283). This addresses the long-lived parser child. Separately, the packaged Desktop Electron local-process runner still needs windowsHide: true for every non-interactive spawn/exec/execFile path, including wsl.exe and local ssh.exe. That host source is not present in the public repository, so the desktop team must land that portion internally. The two fixes are complementary; neither alone covers all observed console flashes.

Follow-up to the earlier local-workaround note: the maintained Windows mitigation has been updated for the merged ChatGPT/Codex desktop package and is available at:

https://github.com/rwang23/codex-windows-console-guard

The guard now covers Codex-owned PseudoConsoleWindow/traditional console surfaces, the packaged ChatGPT.exe -> codex.exe backend/helper path, and the Chrome native-host cmd.exe bridge. This helps with the visible symptom when AppX activation bypasses the process-local wrapper PATH.

The scope is intentionally limited. It does not fix the short-lived Get-CimInstance/process-sampling PowerShell polling, its CPU cost, or the underlying Electron/Desktop no-window inconsistency. Those still need the upstream persistent/native-helper or reliable Windows no-window launch fix described in this issue.