# Codex for Windows: recurring visible PowerShell windows, including after closing the app **URL:** \ **Category:** Codex CLI\ **Tags:** issue\ **Created:** [August 4, 2026, 12:39pm UTC](https://community.openai.com/t/codex-for-windows-recurring-visible-powershell-windows-including-after-closing-the-app/1389052 "2026-08-04T12:39:20Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Jozso72](https://avatars.discourse-cdn.com/v4/letter/j/ecae2f/32.png) [@Jozso72](https://community.openai.com/u/Jozso72)\ **Post date:** [August 4, 2026, 12:39pm UTC](https://community.openai.com/t/codex-for-windows-recurring-visible-powershell-windows-including-after-closing-the-app/1389052/1 "2026-08-04T12:39:20Z")
**Subject:** Codex for Windows: recurring visible PowerShell windows, including after closing the app While using Codex for Windows, and even after closing the app window, PowerShell windows repeatedly appear and disappear shortly afterward. At one point, two windows appeared simultaneously. I restarted the PC and closed the Codex/ChatGPT windows and related processes, but the behavior continued. The Windows PowerShell log shows that this internal process-monitoring command is repeatedly launched: ```auto powershell.exe -NoProfile -NonInteractive -Command Get-CimInstance Win32_PerfFormattedData_PerfProc_Process Get-CimInstance Win32_Process ``` During an earlier process-tree check, the parent process of `powershell.exe` was `codex.exe`. This suggests that Codex’s internal process monitor is launching visible console windows and may leave background processes running after the UI is closed. Expected behavior: internal PowerShell commands should run without visible console windows, and all Codex-related background processes should stop when Codex is closed. ---
**Author:** ![EricGT](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/ericgt/32/20571_2.png) [@EricGT](https://community.openai.com/u/EricGT)\ **Post date:** [August 4, 2026, 12:49pm UTC](https://community.openai.com/t/codex-for-windows-recurring-visible-powershell-windows-including-after-closing-the-app/1389052/2 "2026-08-04T12:49:48Z")
Welcome to the forum! You are welcome to discuss Codex issues on the forum, however the official place to report and track them is the GitHub issue tracker for [OpenAI Codex](https://github.com/openai/codex/issues). I had ChatGPT look for the closest related issue and it identified: > > > \# Bug report: Codex Desktop on Windows flashes visible PowerShell/console window…s 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 > powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; Get-CimInstance Win32\_Process | Select-Object ProcessId,ParentProcessId | ConvertTo-Json -Depth 2" > \`\`\` > > and: > > \`\`\`powershell > 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: > > \`\`\`text > ParentProcessId: 14100 > Parent: Codex.exe > \`\`\` > > Observed event timing: > > \`\`\`text > 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. If that issue matches your problem, consider adding a 👍 reaction on the GitHub issue page itself, not just on the forum topic, as reactions on GitHub help the developers gauge impact and prioritize work. If it is not the same issue, try searching the existing GitHub issues for a closer match. If you cannot find one, then open a new issue with as much detail as possible. ---
**Author:** ![OpenAI\_Support](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/openai_support/32/561845_2.png) [@OpenAI\_Support](https://community.openai.com/u/OpenAI_Support)\ **Post date:** [October 9, 2026, 4:58pm UTC](https://community.openai.com/t/codex-for-windows-recurring-visible-powershell-windows-including-after-closing-the-app/1389052/3 "2026-10-09T16:58:47Z")
Hi @Jozso72, Sorry for the delayed response. If you're still experiencing the recurring PowerShell windows, could you please try the following troubleshooting steps? 1. **Update the app:** Open the Microsoft Store and check for updates to the ChatGPT/Codex Windows app. Please note that similar behavior has also been reported on newer versions, so updating may not fully resolve the issue. 2. **Fully quit the app:** Press `Ctrl + Q` to quit the app completely instead of simply closing its window. Then open Windows Task Manager and check whether any `ChatGPT.exe`, `Codex.exe`, or `codex.exe` processes are still running. If any remain, end those processes and check whether the PowerShell windows stop appearing. 3. **Try an alternative:** If the issue continues, you can temporarily use Codex CLI through Windows Subsystem for Linux (WSL2), if available, while keeping the desktop app fully closed. Please let me know whether these steps help or if the issue persists. -Aish