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

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

Summary

Codex Desktop on Windows repeatedly launches short-lived powershell.exe processes for background process inspection. These processes are created with a visible console window, causing black terminal windows to flash on screen during normal use, even when the user is not explicitly running a command.

This is disruptive and alarming because it looks like an unknown terminal or malware process briefly opening and closing.

Environment

OS: Windows
Codex Desktop version: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
Codex CLI helper path observed:
C:\Users\Administrator\AppData\Local\OpenAI\Codex\bin\fb2111b91430cb17\codex.exe
Shell observed:
C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe
User's default daily terminal: Warp
Windows Terminal delegation was removed from:
HKCU\Console\%%Startup
but visible black console flashes still occurred.

Evidence

Multiple Windows Event Log entries show Codex-spawned PowerShell processes with commands like:

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

and:

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"

Observed parent process:

ParentProcessId: 14100
Parent: Codex.exe

Observed event timing:

2026-06-05 21:33:28  PowerShell console started
2026-06-05 21:33:30  OpenConsole.exe prefetch updated
2026-06-05 21:41:22  OpenConsole.exe prefetch updated
2026-06-05 21:41:29  PowerShell.exe prefetch updated

After Windows Terminal delegation was removed, the issue persisted as a normal visible console flash, so this is not only a Windows Terminal default-terminal issue.

Expected behavior

Codex Desktop should launch all internal/background command probes without showing any user-visible console window.

On Windows, background process inspection should use one of:

CREATE_NO_WINDOW
hidden STARTUPINFO.wShowWindow
a non-console helper process
direct native process enumeration APIs instead of spawning powershell.exe

Actual behavior

Codex Desktop launches short-lived PowerShell commands that visibly flash a black console window. The user sees this even when they did not ask Codex to run a command.

User impact

Looks like malware or an unknown terminal pop-up.
Breaks user trust in Codex Desktop.
Distracts during normal work.
Makes it hard to tell whether a window came from Codex, Claude Code, MSI Center, Windows Terminal, or another background process.

Severity

Medium. This is not data loss, but it is highly visible, frightening, and makes the application feel unsafe on Windows.

Suggested fix

The Codex Desktop Windows process runner/process monitor should never spawn visible consoles for internal background probes. Please audit the Windows child-process creation path used for process polling and ensure hidden/no-window semantics are applied consistently.

Specifically, the code path that runs powershell.exe -NoProfile -NonInteractive -Command Get-CimInstance Win32_Process ... should create the child process with no visible console.

Extra note

This is not an MSI Center issue. MSI Center has its own console-host behavior at startup, but this separate repro was captured with Codex-spawned PowerShell process polling. The parent process evidence points to Codex.

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

Windows Codex Desktop spawns powershell.exe every second for full process polling, causing high CPU usage #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 Windows Codex Desktop spawns powershell.exe every second for full process polling, causing high CPU usage #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.

fix(windows): suppress console window flash on shell tool spawns

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: ryanquadrel@acc2ab3). 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.

Additional reproduction on a newer Windows Desktop build, including two startup helper paths not covered by the original report.

Environment

OpenAI.Codex package: 26.730.8199.0
Windows: 10.0.26200.0, x64
Installation: Microsoft Store / MSIX

Exact startup timeline

08:46:26: ChatGPT.exe started.
08:46:29: packaged codex.exe ... app-server --analytics-default-enabled started.

08:46:54: Windows PowerShell event log recorded PID 21140 running:

powershell.exe -NoProfile -NonInteractive -Command Get-CimInstance Win32_ComputerSystem | Select-Object -ExpandProperty TotalPhysicalMemory

08:46:57: Windows PowerShell event log recorded PID 13880 running powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -EncodedCommand ....
08:46:58: the user observed a visible PowerShell window flash.

The decoded second command is a Codex-specific Windows application-icon extractor. Identifying strings and operations include:

CodexShellIconNative
CODEX_NATIVE_DESKTOP_APP_ICON_PATH
SHCreateItemFromParsingName("shell:AppsFolder\\" + appId, ...)
GetAppsFolderIconDataUrl

It loads a 32x32 icon through IShellItemImageFactory, converts it to PNG, and writes a Base64 data URL. No encoded payload or local application path is attached here.

This provides a close timestamp correlation between a visible flash and a Codex-owned icon-extraction PowerShell helper. A second Codex startup helper querying total physical memory ran three seconds earlier.

Other console paths observed on the same machine

During an earlier active-use window, 41 short-lived PowerShell engine starts all executed the known Get-CimInstance Win32_Process / Win32_PerfFormattedData_PerfProc_Process sampler commands. The packaged call site already contained windowsHide: true, but visible flashes still occurred.
A separate privacy-limited process-start trace captured ChatGPT.exe -> git.exe -> conhost.exe at the exact minute of another user-visible flash. This suggests the audit should cover Git/repository helpers as well as PowerShell process polling.

Exclusions

A user-installed storage monitor was excluded by exact timing: it ran 11 seconds before ChatGPT.exe started and 43 seconds before the visible flash.
Its scheduled action is pure wscript.exe/VBScript and does not invoke PowerShell, CMD, Git, or console-host processes.
No project script or terminal command was intentionally running when the startup flash occurred.

Requested fix

Please apply no-console semantics centrally to every internal noninteractive Windows helper, including startup hardware probes, shell-icon extraction, process polling, Git/repository probes, and safety-worker startup/respawn. For the icon and memory paths, native in-process APIs or cached results would also avoid spawning PowerShell entirely.

No raw event logs, command payloads, usernames, local paths, session IDs, prompts, or project content are included.

I can confirm that this issue is still reproducible on a newer Windows desktop build.

Environment:

Windows 11 x64
Microsoft Store package: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0

Observed behavior:
While Codex Desktop is open, a PowerShell/console window intermittently flashes over other applications, sometimes even when I am not actively entering a new command. It may occur every few minutes and is especially noticeable against dark backgrounds.

I captured the problem in a 1920×1080, 30 fps screen recording. In one confirmed occurrence, the window was visible for exactly one frame (approximately 33 ms). The captured frame clearly shows:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

The window appears partially transparent, so the Codex interface underneath remains visible. This can initially look like a corrupted or duplicated Codex window.

Local Codex logs also show codex.exe repeatedly launching short-lived PowerShell commands. No display-driver reset or Desktop Window Manager crash was found around the captured occurrence.

Impact:

Highly distracting during video work, recording, games, and dark full-screen previews
Looks alarming because it resembles an unknown console or rendering failure
No data loss or application crash has been observed

Please ensure that all internal PowerShell and console processes are launched with reliable no-window semantics on Windows. I can provide the original short recording and adjacent extracted frames if the maintainers need them.

No usernames, private paths, session IDs, prompts, or project content are included in this comment.

this is still happening on one of my windows machines (1 on 3) not sure why. How can this be fixed?

Additional Windows Desktop reproduction observed on 2026-10-10. Posting this diagnostic summary with the affected user's authorization.

Environment

Windows 11 Home, x64, OS version 10.0.26300, build 26300.
Installed MSIX package from Get-AppxPackage OpenAI.Codex: 26.1007.2314.0.
Running app's update check reports installed app version 26.1007.21434, build 13901, production channel, and up_to_date. These are separately reported values; the discrepancy has not been explained.
Bundled backend: codex-cli 0.162.0-alpha.17.2.
Native Windows desktop use, with MCP integrations enabled.

Reproduction and user-visible behavior

Fully close Codex and Claude. The user also reports ending their remaining processes.
Reopen Codex Desktop.
A terminal/console window briefly appears and disappears after reopening.
Additional flashes occur during ordinary chat use, including shortly after submitting a message. The user also reported a flash around a reply that involved no diagnostic tool commands.

This is intermittent, not a measured fixed interval. The user describes it as newer behavior, or newly noticeable; the last known good build is unknown. The diagnostic session itself used shell commands, so flashes during those commands cannot reliably be attributed to background polling.

Expected: internal startup, repository, and other background helpers should not create visible terminal windows.

Actual: brief, unexpected terminal windows appear during normal use, making it difficult to distinguish intended agent activity from other background activity.

Sanitized process evidence

A process snapshot after the fresh launch showed these Codex-owned chains. Times below are local on 2026-10-10:

Start time	Observed process chain
14:59:22	packaged desktop root `ChatGPT.exe` starts
14:59:26	`ChatGPT.exe -> codex.exe app-server -> conhost.exe`
14:59:32	`ChatGPT.exe -> codex-computer-use-swift.exe -> conhost.exe`
14:59:38-39	Codex backend starts Node/MCP helpers, including CMD launchers for app-tools/code-review, with console hosts
15:00:39	`ChatGPT.exe -> git.exe -> conhost.exe`
15:00:45	`codex.exe -> codex-code-mode-host.exe -> conhost.exe`

An earlier Task Manager console-host entry was traced to a Codex code-review MCP CMD launcher. This explains some of the many CMD/conhost entries, but does not establish that they are leaking or that this launcher caused a visible flash.

Evidence limitation: the exact window/PID responsible for the visible flash was not captured. The chains above demonstrate console-backed Codex helpers, not proof that any particular child displayed a window. We have not established that this machine's symptom is specifically the PowerShell/CIM polling path in the original issue.

The fresh-launch reproduction suggests accumulated helpers from old sessions are not required for the symptom. Please include startup helpers, Git/repository probes, MCP launchers, and code-mode helper startup in the Windows no-window audit, alongside the process-polling path.

No raw logs, chat transcripts, private paths, credentials, or project content are attached.

Navigation Menu

Repository navigation

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

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

Summary

Environment

Evidence

Expected behavior

Actual behavior

User impact

Severity

Suggested fix

Extra note

Environment

Exact startup timeline

Other console paths observed on the same machine

Exclusions

Requested fix

Environment

Reproduction and user-visible behavior

Sanitized process evidence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

Summary

Environment

Evidence

Expected behavior

Actual behavior

User impact

Severity

Suggested fix

Extra note

Activity

github-actions commented on Jun 5, 2026

superPilipala commented on Jun 5, 2026

rwang23 commented on Jun 12, 2026

Nicolas0315 commented on Jun 21, 2026

shuangquanhuang commented on Jun 26, 2026

15597771770-cpu commented on Jul 3, 2026

howareyou1129 commented on Jul 3, 2026

houyupeng commented on Jul 6, 2026

ryanquadrel commented on Jul 13, 2026

rwang23 commented on Jul 16, 2026

ctmaomao commented on Aug 6, 2026

Environment

Exact startup timeline

Other console paths observed on the same machine

Exclusions

Requested fix

wangyedingaka-debug commented on Aug 13, 2026

albanx commented on Sep 29, 2026

brianlaughlin commented on Oct 10, 2026

Environment

Reproduction and user-visible behavior

Sanitized process evidence

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions