›_ Codex Issues
Codex Issues / #23892

Codex Desktop on Windows periodically spawns visible PowerShell/conhost probe that steals focus

Open 💬 6 comments Opened May 21, 2026 by Divine-Shadow
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex Desktop for Windows, installed package observed as OpenAI.Codex_26.519.2081.0_x64__2p2nqsd0c76g0 with Electron crashpad annotation version 26.519.21041.

What operating system are you using?

Windows with Codex configured to run in WSL (runCodexInWindowsSubsystemForLinux = true).

What steps can reproduce the bug?

  1. Start Codex Desktop on Windows.
  2. Work in another desktop application or another terminal tab/window.
  3. Leave Codex Desktop running for a short while.
  4. Observe intermittent flashes of a terminal/console window or tab opening and immediately closing.

I confirmed this by watching Windows process creation. Codex Desktop periodically launches a short-lived PowerShell process similar to:

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 | Select-Object ProcessId,ParentProcessId,CommandLine,WorkingSetSize,@{Name='CpuPercent';Expression={$cpuByPid[[int]$_.ProcessId]}},@{Name='AgeSeconds';Expression={[int]((Get-Date) - $_.CreationDate).TotalSeconds}} | ConvertTo-Json -Depth 2"

The parent process is Codex.exe. Each probe also creates a transient conhost.exe, which appears to be the visible flash/focus-stealing window.

What is the expected behavior?

Background process/resource probes should run without surfacing a console window and without stealing focus from other applications or terminal tabs. On Windows this likely means launching the child process hidden / with no console window, or using a non-console process collection path.

What happens instead?

A console window flashes briefly and steals focus. This interrupts typing in other desktop applications and other terminal tabs, making the Desktop app difficult to leave running while working.

Additional context

This does not appear to be caused by user tmux hooks, cron jobs, or devkit shell launchers. In the observed process tree, the repeating powershell.exe probe is a direct child of Codex.exe.

A CLI-only Codex session does not appear to trigger the same visible Windows console flash in my testing, so this seems specific to Codex Desktop on Windows.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

  • #22912

Powered by Codex Action

XLGXB · 3 months ago

I can reproduce a related Windows trigger with command hooks enabled, separately from the periodic background probe in the original report.

Observed process chain during a visible flash:

  • Codex.exe -> codex.exe -> pwsh.exe -NoProfile -Command "context-mode hook codex userpromptsubmit"
  • Codex.exe -> codex.exe -> pwsh.exe -NoProfile -Command "context-mode hook codex stop"

This suggests changing a hook's command / commandWindows value cannot fully fix the flash: the outer shell process is already created by Codex before the hook command runs.

Source check on current main:

  • codex-rs/core/src/session/mod.rs: build_hooks_for_config() derives hook execution via user_shell.derive_exec_args("", false).
  • codex-rs/core/src/shell.rs: on Windows, PowerShell commands become pwsh.exe -NoProfile -Command ....
  • codex-rs/hooks/src/engine/command_runner.rs: the hook Command is spawned after stdio piping, without an apparent Windows no-console creation flag.

Potential minimal fix: on Windows, set CREATE_NO_WINDOW (0x08000000) on the hook process before command.spawn(), since hooks already communicate through piped stdio and are non-interactive. This should preserve hook functionality while preventing transient PowerShell/conhost windows.

I did not include local logs or user paths here, but can provide sanitized process-capture details if useful.

neavo · 3 months ago

same on my pc

rwang23 · 1 month ago

I found a separate, adjacent presentation path that may help distinguish Windows reports.

When the Windows default-terminal setting is Automatic, some otherwise-unbound Codex console UI can be brokered through WindowsTerminal.exe / OpenConsole.exe. Those CASCADIA_HOSTING_WINDOW_CLASS windows can be service-owned rather than descendants of the Codex process, so an ancestry-only guard cannot safely target them without risking a user's own terminal.

On one Windows test system, explicitly selecting Windows Console Host for the current user's default-terminal delegation stopped that brokered Terminal-flash class. I documented a reversible local mitigation, including its limits, here:
https://github.com/rwang23/codex-windows-console-guard

This does not explain or fix the direct Codex.exe -> powershell.exe -> conhost.exe probe reported here; an upstream no-window/native-helper change remains necessary for that direct process path.

ShienYou · 25 days ago

I can reproduce this on a newer Codex Desktop build, and I captured an additional process path that may help narrow down the Windows-specific cause.

Environment

  • Windows 11 Home, build 26200
  • Codex Desktop package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
  • The flashes are most frequent when Codex is focused, especially during startup and task/thread switching.

Visible-window evidence

A lightweight monitor recorded a real top-level WindowsTerminal.exe window with class CASCADIA_HOSTING_WINDOW_CLASS becoming visible and, in several cases, becoming the foreground window before focus returned to ChatGPT.exe.

Observed visible durations were approximately 60–205 ms. During one 14-second interval, the monitor captured at least four flashes (74 ms, 108 ms, 60 ms, and 124 ms). The user visibly observed more rapid consecutive flashes than the poller captured, so this is a lower bound.

The Terminal window title was sometimes:

C:\Windows\System32\tzutil.exe

The focus transition was recorded as:

ChatGPT -> Windows Terminal / CASCADIA_HOSTING_WINDOW_CLASS -> ChatGPT

This interrupts typing.

Correlated process activity

The additional process chains observed around the flashes include:

  • ChatGPT.exe -> gh.exe -> [nested gh.exe] -> tzutil.exe -> conhost.exe
  • ChatGPT.exe -> gh.exe -> git.exe -> git.exe
  • ChatGPT.exe -> taskkill.exe -> conhost.exe
  • ChatGPT.exe -> powershell.exe -> conhost.exe

In one three-minute capture window, the monitor recorded:

  • 159 × ChatGPT.exe -> gh.exe
  • 187 × gh.exe -> git.exe
  • 63 × gh.exe -> tzutil.exe
  • 177 × ChatGPT.exe -> taskkill.exe
  • 46 × ChatGPT.exe -> powershell.exe

The Windows Terminal host can be brokered/service-owned, so it is not always a direct descendant of the short-lived command process. The correlation above is based on matching timestamps, the Terminal window title, window class, and foreground transitions.

All observed executables resolved to the expected Microsoft, GitHub CLI, or Git for Windows locations/signatures. This looks like a Codex background-process/console-window handling bug rather than an unknown executable.

I can provide sanitized JSONL capture details if useful.

herrinx · 23 days ago

Independent confirmation on a current Windows Codex Desktop build.

Environment

  • Codex Desktop MSIX: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
  • Windows x64
  • Windows default-terminal delegation: Automatic (DelegationConsole and DelegationTerminal both all-zero GUIDs)

User-visible behavior

Short-lived black command windows flash repeatedly. The user also observed the flashes while Codex remained open with zero active chats/tasks, independently confirming the idle/background condition reported in #34266.

During an interactive diagnostic, user-reported flashes aligned with new Codex-owned process families. Two same-second examples captured:

ChatGPT.exe
  -> powershell.exe -NoProfile -NonInteractive -Command ...
       Get-CimInstance Win32_PerfFormattedData_PerfProc_Process
       Get-CimInstance Win32_Process ...
  -> conhost.exe

The PowerShell commands collected process ID, parent PID, command line, working set, CPU percentage, and process age, then serialized the result as JSON.

A separate 10 ms native process-table sampler subsequently captured these additional Codex-owned chains:

ChatGPT.exe -> powershell.exe -> conhost.exe
ChatGPT.exe -> git.exe -> git.exe
ChatGPT.exe -> gh.exe

The Git command observed was repository-discovery/status work. This supports the multiple adjacent console-allocation paths described in this issue and #34266, rather than a third-party startup utility.

Installed-code check

Read-only inspection of the packaged app.asar found the exact WMI snapshot commands. The Electron/Node execFile calls already specify windowsHide: true, yet transient conhost.exe children are still created and the flashes remain user-visible. This suggests the current regression may involve more than simply adding -NoProfile -NonInteractive; brokered/default-terminal behavior or another child-process path may also be involved.

A hidden native watcher remains active to distinguish a direct conhost.exe surface from a brokered WindowsTerminal.exe / CASCADIA_HOSTING_WINDOW_CLASS surface on the next observed flash.

This evidence is sanitized: no account identifiers, task/thread contents, machine name, repository names, or user paths are included.