[Bug]: [Windows] Console windows flash constantly — git.exe spawned without windowsHide #32718

Checked on main at a9e709f15f and on the v0.1.7 tag. T3 Code starts git through Effect's Node spawner, which passes windowsHide: true on Windows with stdin, stdout and stderr all piped, so Node creates the process with CREATE_NO_WINDOW. Printing the spawn options the server builds on win32 for git status --porcelain=v2 --branch, git rev-parse --show-toplevel and git fetch --quiet origin gives windowsHide: true with stdio: ["pipe","pipe","pipe"] for all three. The Claude process is spawned with windowsHide: true as well.

A conhost.exe 0xffffffff -ForceV1 for each git.exe is expected even when no window is shown: Windows starts a console host for every console program, windowless ones included. So the 4688 counts show how often git runs, but not which process puts a window on screen.

To find what is flashing, could you share:

1. The command lines of a few of those git.exe events (turn on "Include command line in process creation events" under Computer Configuration > Administrative Templates > System > Audit Process Creation), plus any process whose parent is one of them.
2. The process that owns a flashing window: Process Explorer's "Find Window's Process" crosshair, or Process Monitor filtered on Process Create, will show it.
3. The output of where git and git config --show-origin --get-regexp "core.fsmonitor|credential.helper|core.hookspath" in a project you have open in T3 Code.
4. Whether the flashing continues with no thread running and the integrated terminal closed.

[GPT-6.1 Sol][Codex] on behalf of shivam.

I tested the official signed T3-Code-0.1.7-arm64.exe, source commit 322f6544dfad0a3c8a0c8cbecf2c7f7874b14268, in the Windows desktop app on Windows 11 Pro 25H2 build 26200.9711 ARM64 with Git 2.56.0.windows.4. With the terminal closed and no agent turn running, I opened the diff and refreshed it three times. Across two desktop captures totaling 100 seconds, Git Trace2 recorded 187 Git starts. No console flash appeared, the app kept focus in all 2,000 window samples, and the window-event hook recorded no visible show event. This does not rule out your reported behavior.

This test used an isolated Git configuration with no fsmonitor, credential helper, or hooksPath entries. Your Windows 26H2, Git .windows.2, architecture, and active-provider behavior remain untested. Separately, tracing the Git and Claude launch code on v0.1.7 and main a9e709f15f825cacac1b6d665fa1920c328d68b7 confirms that these paths already set windowsHide: true with piped streams, so I have not proposed a patch that adds the same flag.

Could you share your CPU/app architecture and the flashing window's owning process, command lines, Git path/configuration, and idle-versus-running behavior requested in https://github.com/pingdotgg/t3code/issues/32718#issuecomment-6714598827? Those details are still needed to connect the visible window to a launch path.

The 20-second excerpt shows the three diff refreshes and their outcome in the real desktop app. It is a reproduction attempt, with no code change.

https://github.com/user-attachments/assets/2a30a5d3-5c99-478c-8c7a-ee3fe91e2c77

Another Windows x64 data point. This does not reproduce here, but it rules out a few explanations.

Setup: T3 Code (Beta) 0.1.7 desktop, Windows 11 build 26300 x64, Git for Windows 2.54.0.windows.1 (C:\Program Files\Git\cmd\git.exe). The only git config hit for core.fsmonitor|credential.helper|core.hookspath is credential.helper manager (system gitconfig). Codex and Claude as active providers, with agent turns running during the active captures.

Method: a user-mode monitor (no audit policy) that records every process created under T3 Code, with command lines via WMI, and polls EnumWindows and GetForegroundWindow about every 10 ms. As a control, a visible git --version started from PowerShell was caught: a window of about 0.5 s, owned by Windows Terminal, which also took focus.

On conhost.exe 0xffffffff -ForceV1 in the report: here, every conhost started for T3's children is \??\C:\Windows\system32\conhost.exe 0x4. That held with the legacy console both on and off. I also spawned a console program from a console-less Node parent with windowsHide + piped stdio, windowsHide + inherited stderr, and no windowsHide. All three produced conhost.exe 0x4. So neither the legacy console setting nor Node's spawn flags produce the reporter's -ForceV1 form on this build. That difference may be the most useful lead toward what's special about the affected machine.

I investigated a similar intermittent terminal flash on Windows using GPT-6.1 Sol (high reasoning effort) in T3 Code, after capturing an occurrence with Sysinternals Process Monitor.

The capture showed this process chain around the reported flash:

bun.exe → gh.exe → gh.exe send-telemetry → tzutil.exe /g → conhost.exe

Immediately afterward, OpenConsole and Windows Terminal started. Windows Terminal exited about 0.67 seconds later.

My installed GitHub CLI is 2.91.0. This matches [cli/cli#13353](https://github.com/cli/cli/pull/13353), included in [v2.93.0](https://github.com/cli/cli/releases/tag/v2.93.0) as “fix(telemetry): prevent tzutil console flash on Windows.”

I’m updating GitHub CLI now and will observe whether the flashes stop. This is a strong lead for my occurrence, rather than confirmation that every flash reported here has the same cause.

Edit: I'll also turn off the telemetry for Github CLI :)

@sebascendocredi Which process owns a flashing window? Use Process Explorer's 'Find Window's Process' crosshair on one, or Process Monitor filtered on Process Create with command lines, and include the full parent chain (for example gh.exe -> tzutil.exe, or a git hook or credential helper). Please also say what gh --version prints, since GitHub CLI before 2.93.0 flashes a tzutil console from its telemetry.