›_ Codex Issues
Codex Issues / #33891

[Bug] Windows desktop flashes visible PowerShell window during background command monitoring

Open 💬 2 comments Opened Jul 17, 2026 by tylor-bennett
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex app version

26.715.2305.0 (Microsoft Store; no newer update currently offered)

Platform

  • Microsoft Windows 11 Home
  • Version 10.0.26200, build 26200
  • ARM64

What issue are you seeing?

While Codex Desktop is open and agents are performing background work, a visible PowerShell console window repeatedly appears and disappears. This can happen every few minutes during active multi-threaded/background agent work and interrupts normal desktop use.

Process inspection during an occurrence showed:

  • powershell.exe launched with -NoProfile -NonInteractive -Command ...
  • Parent process: ChatGPT.exe
  • A corresponding conhost.exe was created for the PowerShell process
  • The PowerShell command appears to collect process/CPU information using Win32_PerfFormattedData_PerfProc_Process

The full command body is intentionally omitted because it contains verbose local process details, but I can provide a redacted copy if useful.

This is not an Armatus/project scheduled task: the relevant Windows Task Scheduler job already uses -WindowStyle Hidden. A separate long-lived Codex PowerShell command-safety helper had no window handle. Codex's process registry showed 200 historical records but zero commands with a live OS PID, so no orphaned background command was present.

Steps to reproduce

  1. Open Codex Desktop on Windows.
  2. Run persistent/background agent tasks that execute local commands.
  3. Continue using the desktop while those tasks run.
  4. Observe a PowerShell window briefly appear and disappear periodically.

The frequency increases during active background-agent command execution. The issue began becoming obvious after configuring multiple persistent role tasks, but it is the Codex Desktop process—not the project scripts—that launches the visible PowerShell process.

Expected behavior

All noninteractive PowerShell processes used for command execution or process monitoring should launch without a visible console window (for example using the appropriate Windows no-window creation flag). Background agent work should not flash or focus a console window.

Actual behavior

ChatGPT.exe launches a short-lived PowerShell process with a console host, producing a visible window that repeatedly flashes on screen.

Related issue

Possibly related to #17208, which reports Codex launching an encoded, noninteractive PowerShell process behind ordinary commands on Windows. This report is specifically about the resulting visible recurring console window in Codex Desktop.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33875

Powered by Codex Action

luisfiliperjo-code · 1 month ago

I can confirm that this issue still occurs on a newer Windows x64 build.

Environment

  • Codex Desktop: 26.721.3404.0
  • Installation: Microsoft Store / MSIX
  • Previous installed version: 26.715.10079.0
  • OS: Windows 11 Home Single Language
  • Windows version/build: 10.0.26200
  • Architecture: x64

The visible PowerShell windows became noticeable after the Codex Desktop update.

Observed behavior

While Codex is executing local tasks, multiple short-lived PowerShell console windows appear and disappear. The frequency increases when the task performs several local tool or shell calls.

A live process-tree inspection showed two distinct paths:

  1. The actual Codex local shell:
codex.exe
└─ pwsh.exe
  1. A separate Desktop process-monitoring path:
ChatGPT.exe
└─ powershell.exe
   └─ conhost.exe

The second powershell.exe was launched non-interactively and contained process/CPU inspection commands involving:

Get-CimInstance Win32_Process
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process

This matches the WMI sampling behavior discussed in #33875.

I also performed a read-only inspection of the installed resources/app.asar. The Windows child-process sampler appears to request:

windowsHide: true

Despite that, Windows still creates a corresponding conhost.exe, and a console window can visibly flash before the short-lived process exits.

Configuration checks

I found no local configuration that would intentionally enable console windows:

  • No custom Windows console delegation override.
  • No unified_exec, shell_tool, or shell_snapshot override in the user Codex configuration.
  • The spawned PowerShell process is a direct child of ChatGPT.exe, not a scheduled task or project script.

Steps to reproduce

  1. Launch Codex Desktop on Windows.
  2. Open a local Codex task.
  3. Ask Codex to perform work requiring several local shell/tool calls.
  4. Continue using the desktop while the task runs.
  5. Observe PowerShell windows briefly appearing and disappearing.
  6. Inspect the process tree during an occurrence and observe the ChatGPT.exe → powershell.exe → conhost.exe chain.

Expected behavior

All noninteractive PowerShell processes used for background process monitoring should run without creating or focusing a visible console window.

Actual behavior

Short-lived PowerShell/conhost windows repeatedly flash while Codex is working, interrupting normal desktop use.

Questions for the maintainers

Could someone from OpenAI confirm whether this behavior is currently triaged or tracked internally?

In particular:

  1. Is the visible console flash caused by the Windows child-process/CPU sampler?
  2. Is this considered part of the same underlying problem as #33875?
  3. Is a fix planned to avoid spawning a console host, or to replace/reduce the repeated WMI process snapshots?
  4. Is there a supported temporary setting to disable this sampler on Windows while retaining normal Git and shell functionality?

I can collect an additional sanitized process-lifecycle trace if the team specifies the preferred Windows providers and fields.