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

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?

Start Codex Desktop on Windows.
Work in another desktop application or another terminal tab/window.
Leave Codex Desktop running for a short while.
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.

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

Windows desktop freezes while electron-sampler fails WMI process snapshots in sandbox #22912

Powered by Codex Action

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.

same on my pc

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

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.

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.

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.

Windows desktop app intermittently flashes a console window during idle GitHub polling

Summary

The Codex experience in the ChatGPT desktop app for Windows intermittently opens a visible Windows Terminal/console window for a fraction of a second and immediately closes it.

This also happens while the app is idle and no Codex tasks are running. Process monitoring shows that the flash is associated with background GitHub CLI activity initiated by ChatGPT.exe. A nested gh.exe invocation starts tzutil.exe, which receives a console host; Windows then briefly starts OpenConsole.exe and WindowsTerminal.exe.

Environment

Codex/ChatGPT Windows desktop package: OpenAI.Codex 26.908.9136.0 (x64)
Codex agent binary build directory: 12219cbfbcbddde7
Agent environment: Windows native
Windows: 25H2, build 26200.9457, x64
GitHub CLI: 2.92.0
Git for Windows: 2.54.0.windows.1
tzutil.exe: 10.0.26100.2161
Windows Terminal is the active console host

Steps to reproduce

Open the ChatGPT desktop app on Windows and use the Codex section with local Git projects and GitHub CLI available.
Leave the app running.
Ensure no Codex task is active.
Wait for the app's background Git/GitHub refresh or polling activity.
Observe that a console/Windows Terminal window intermittently appears for roughly 300–500 ms and closes again.

The issue is intermittent rather than tied to a simple fixed interval.

Expected behavior

Background Git and GitHub CLI operations should run without creating or showing a console window. The desktop should remain visually undisturbed while Codex is idle.

Actual behavior

A Windows Terminal/console window visibly flashes on screen and immediately closes. This is distracting and can occur even when the user has not started a Codex task.

Captured process timeline

One clean idle reproduction occurred on 2026-09-21 at 06:29:17 local time:

Local time	Event
`06:29:16.589`	`ChatGPT.exe` starts `gh.exe`
`06:29:17.819`	`gh.exe` starts a nested `gh.exe`
`06:29:17.824`	Nested `gh.exe` starts `tzutil.exe`
`06:29:17.830`	`tzutil.exe` starts/receives `conhost.exe`
`06:29:17.898`	Windows starts `OpenConsole.exe`
`06:29:17.903`	Windows starts `WindowsTerminal.exe`
`06:29:18.145`	`OpenConsole.exe` exits
`06:29:18.207`	`WindowsTerminal.exe` exits
`06:29:18.533`	Nested `gh.exe` exits

The observed chain was:

ChatGPT.exe
  -> gh.exe
     -> gh.exe
        -> tzutil.exe
           -> conhost.exe

Console activation:
svchost.exe
  -> OpenConsole.exe
  -> WindowsTerminal.exe

The WindowsTerminal.exe process lived for approximately 304 ms, matching the visible flash.

Recurrence evidence

During one approximately 21-hour capture:

274 direct ChatGPT.exe -> gh.exe process starts were observed.
102 gh.exe -> tzutil.exe process starts were observed.
Four brief Windows Terminal launches were captured:
- 2026-09-20 13:20:56.511
- 2026-09-20 17:16:49.045
- 2026-09-21 06:28:57.189
- 2026-09-21 06:29:17.903
A separate earlier monitoring session captured the same process pattern on 2026-09-19 at approximately 04:19:58.

The reproductions originated from the ChatGPT/Codex desktop process, including the idle reproduction above.

Likely cause

The desktop app appears to launch one or more background GitHub CLI commands without fully suppressing console allocation. A nested GitHub CLI process invokes tzutil.exe; under the configured Windows console host, this activates OpenConsole.exe/WindowsTerminal.exe and briefly displays a window.

The intermittent nature suggests that only certain GitHub refresh paths or subprocess combinations reach the console-allocation path.

Suggested fix

Launch all non-interactive background Git/GitHub subprocesses—and their nested console utilities—with Windows no-window semantics. For example, ensure the applicable process-creation layer uses CREATE_NO_WINDOW and does not request a new console for background polling. The suppression needs to cover nested gh.exe/tzutil.exe invocations, not only the initial process.

It would also be useful to add a Windows regression test that performs an idle GitHub refresh and asserts that no visible top-level console/Windows Terminal window is created.

User impact

The repeated flash is distracting, looks like an unexpected command prompt opening, and gives no indication of what initiated it. More seriously, the console grabs focus and becomes the topmost window. If the user is typing when this happens, approximately 2–3 characters of their input are lost because those keystrokes are redirected away from the application they were using. Because the flash also occurs with no active task, users cannot reliably avoid it except by fully quitting the desktop app.

Navigation Menu

Repository navigation

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

What version of the Codex App are you using?

What operating system are you using?

What steps can reproduce the bug?

What is the expected behavior?

What happens instead?

Additional context

Environment

Visible-window evidence

Correlated process activity

Environment

User-visible behavior

Installed-code check

Windows desktop app intermittently flashes a console window during idle GitHub polling

Summary

Environment

Steps to reproduce

Expected behavior

Actual behavior

Captured process timeline

Recurrence evidence

Likely cause

Suggested fix

User impact

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of the Codex App are you using?

What operating system are you using?

What steps can reproduce the bug?

What is the expected behavior?

What happens instead?

Additional context

Activity

github-actions commented on May 21, 2026

XLGXB commented on May 25, 2026

neavo commented on May 26, 2026

rwang23 commented on Jul 16, 2026

ShienYou commented on Aug 3, 2026

Environment

Visible-window evidence

Correlated process activity

herrinx commented on Aug 4, 2026

Environment

User-visible behavior

Installed-code check

RonnieBalle commented on Sep 21, 2026

Windows desktop app intermittently flashes a console window during idle GitHub polling

Summary

Environment

Steps to reproduce

Expected behavior

Actual behavior

Captured process timeline

Recurrence evidence

Likely cause

Suggested fix

User impact

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions