fix(windows): Engram Git subprocesses open transient terminal windows

[MarsSall]

Pre-flight Checks

• I searched the existing issues. Windows: console flash when Pi auto-starts engram serve (startup and subagents) #536 reports the same visible-console symptom; the relationship and additional evidence are documented below.
• I understand this issue requires status:approved before a PR can be opened.

Bug Description

Starting Pi causes several transient console or Windows Terminal windows to appear. The same behavior occurs when Pi launches subagents.

Process monitoring identified Git commands spawned by engram serve as the primary source. These subprocesses create conhost.exe, which can subsequently activate OpenConsole.exe or WindowsTerminal.exe.

Steps to Reproduce

1. Install and enable gentle-engram in Pi on native Windows.
2. Ensure no Engram daemon is currently running.
3. Start a new Pi session.
4. Observe several transient terminal windows.
5. Launch a Pi subagent.
6. Observe the windows appearing again.

Expected Behavior

Engram and its Git subprocesses should run silently in the background without creating or activating visible terminal windows.

Actual Behavior

Engram executes repository-discovery commands such as:

git rev-parse --show-toplevel
git remote get-url origin

The observed process chain was:

engram serve
└─ git.exe
   └─ conhost.exe
      └─ OpenConsole.exe / WindowsTerminal.exe

This caused multiple terminal windows to appear briefly during Pi startup and subagent creation.

Operating System

Windows

Engram Version

• Engram binary: 1.19.0
• gentle-engram Pi plugin: reproduced on 0.1.8 and still present on 0.1.10

Agent / Client

Other: Pi Coding Agent 0.80.6

The session runs on native Windows using Nushell inside WezTerm.

Relevant Logs

engram.exe
Command line: engram serve

git.exe
Parent: engram.exe
Command line:
git -C "<project>" rev-parse --show-toplevel

conhost.exe
Parent: git.exe
Command line:
\??\C:\WINDOWS\system32\conhost.exe 0x4

git.exe
Parent: engram.exe
Command line:
git -C "<project>" remote get-url origin

OpenConsole.exe
Command line:
WindowsTerminal\OpenConsole.exe -Embedding

Additional Context

Relationship to #536

#536 reports the same startup and subagent console-flash symptom and proposes a Windows-specific hidden launcher plus a cross-process startup lock. This issue adds process-monitor evidence that traces the visible windows to engram serve Git subprocesses and confirms that adding windowsHide: true to the existing detached spawn path eliminates the observed windows.

The minimal PR for this issue addresses process visibility only. If maintainers consider the startup race a separate concern, it can remain tracked in #536; otherwise, these issues can be consolidated.

Verified workaround

A local workaround was applied in:

gentle-engram/index.ts

The detached process configuration was changed to:

proc = spawn(command, [...args], {
  cwd,
  detached: true,
  stdio: "ignore",
  windowsHide: true,
});

The existing Engram daemon was then stopped and restarted so it inherited the corrected process configuration.

After applying the workaround:

• no Engram-owned Git processes produced visible consoles;
• no OpenConsole.exe or WindowsTerminal.exe processes appeared during startup;
• the user confirmed that no windows appeared visually.

Pi also runs multiple package update checks through:

pnpm view <package> version --json

Those checks were observed using cmd.exe, but they did not produce visible windows during the final verification.

The workaround currently modifies node_modules directly and is therefore overwritten by package upgrades or reinstalls. The fix should be incorporated into gentle-engram itself.

[killo3967]

Independent confirmation on a different environment, plus the exact code location in the binary.

Environment: engram 1.19.0, gentle-engram 0.1.10, Pi on PowerShell 7 inside Windows Terminal 1.24 (set as default terminal app). Captured with Process Monitor filtering Process Create: three visible windows on Pi startup, each correlating 1:1 with a Git subprocess of the already-running daemon:

10:15:03.758  engram.exe -> git.exe    git -C <project> rev-parse --show-toplevel
10:15:03.800  svchost.exe -> OpenConsole.exe         (window 1)
10:15:04.068  engram.exe -> git.exe    git -C <project> remote get-url origin
10:15:04.111  svchost.exe -> OpenConsole.exe         (window 2)
10:15:04.348  engram.exe -> git.exe    git -C <project> rev-parse --show-toplevel
10:15:04.396  svchost.exe -> OpenConsole.exe         (window 3)

The daemon had been started 13 minutes earlier by a previous Pi session, so this reproduces without the startup race tracked in #536.

Where the fix belongs in the binary: the only production Git spawns in the repo are in internal/project/detect.go:

• detect.go:282: exec.CommandContext(ctx, "git", "-C", dir, "rev-parse", "--show-toplevel")
• detect.go:381: exec.CommandContext(ctx, "git", "-C", dir, "remote", "get-url", "origin")

There is no SysProcAttr anywhere in the codebase, so every Git child gets default console behavior. engram.exe is a console-subsystem binary (PE subsystem 3) launched detached with no attached console, so each Git child forces Windows to allocate a fresh console session, and with Windows Terminal as default terminal that materializes a visible OpenConsole window.

Why the plugin-side windowsHide: true workaround also works: it sets STARTF_USESHOWWINDOW/SW_HIDE on the daemon process, and that show state propagates to the console sessions its children create. Effective, but it only protects daemons spawned by gentle-engram. Anyone starting engram serve from Task Scheduler, a service wrapper, or another agent integration hits the flash again, so the binary should defend itself.

Suggested binary-side fix, platform-gated:

//go:build windows

package project

func hideConsole(cmd *exec.Cmd) {
	cmd.SysProcAttr = &syscall.SysProcAttr{
		HideWindow:    true,
		CreationFlags: 0x08000000, // CREATE_NO_WINDOW
	}
}

//go:build !windows

package project

func hideConsole(*exec.Cmd) {}

Then call hideConsole(cmd) at both call sites in detect.go. That removes the flash regardless of how the daemon was launched.

[killo3967]

Hit this same issue on Windows 11 — every Pi prompt flashed a transient Windows Terminal window. Root cause confirmed: the daemon runs without a console, so each git child spawned from internal/project/detect.go (rev-parse --show-toplevel, remote get-url origin) allocates a new visible console.

I have a working patch: a small build-tagged internal/winhide package setting SysProcAttr{HideWindow: true, CreationFlags: CREATE_NO_WINDOW} on the four exec.Command* call sites (the two project-detection git calls, the LLM CLI runner, and the setup runCommand). Running locally on top of v1.19.0 — no more console flashes, and tests for the touched packages pass (there is one pre-existing Windows-only failure in internal/setup that also fails on the clean tag, unrelated to this change).

Happy to open a PR once this gets status:approved.