Best possible solution:

Use #78266 as the canonical fix path for #78159, preserving its test assertions and changelog entry, then close the linked issue after that maintainer PR lands.

Do we have a high-confidence way to reproduce the issue?

Yes for the source-level root cause: current main reaches execFileSync for shell-env fallback without windowsHide, and the linked issue plus this PR body provide matching Windows observations. I did not run a Windows GUI gateway startup locally, so this remains source-reproducible rather than locally reproduced here.

Is this the best way to solve the issue?

No as the merge vehicle: the code direction is correct, but #78266 is the better canonical path because it covers the same fix with regression assertions and maintainer ownership. Closing this duplicate preserves the useful Windows proof while avoiding competing PRs for the same line.

Security review:

Security review cleared: The diff only adds a supported child-process display-suppression option and changelog text; it does not add dependencies, permissions, secret handling, downloads, or new execution paths.

What I checked:

• Current main gap: execLoginShellEnvZero still passes encoding, timeout, maxBuffer, env, and stdio to params.exec(...) without windowsHide on the reviewed checkout. (src/infra/shell-env.ts:90, 8e533490ab0a)
• Runtime path: Config loading can call loadShellEnvFallback, which reaches the login-shell env probe when shell-env fallback is enabled. (src/config/io.ts:1241, 8e533490ab0a)
• This PR diff: The PR adds windowsHide: true to src/infra/shell-env.ts and one changelog bullet, with no test changes. (src/infra/shell-env.ts:95, d2693c2c7717)
• Canonical open maintainer PR: PR fix(shell-env): hide Windows login shell probe #78266 is open, maintainer-labeled, fixes [Windows] execLoginShellEnvZero missing windowsHide:true — console flash on login shell env detection (2026.5.4) #78159, and covers the same shell-env option while also updating two shell-env test assertions and the changelog. (src/infra/shell-env.test.ts:113, 5527f4d47e9b)
• Dependency contract: Node v22 child_process docs define windowsHide as a boolean option that hides the subprocess console window normally created on Windows, defaulting to false.
• PR state: Live PR metadata reports this PR open, unmerged, mergeable=false, rebaseable=false, and mergeable_state=dirty, while the maintainer PR remains the protected canonical path. (d2693c2c7717)

Likely related people:

• @BradGroux: Authored the open maintainer-labeled PR fix(shell-env): hide Windows login shell probe #78266 that tracks the same [Windows] execLoginShellEnvZero missing windowsHide:true — console flash on login shell env detection (2026.5.4) #78159 shell-env Windows console-flash fix with tests and changelog coverage. (role: canonical follow-up owner; confidence: medium; commits: 5527f4d47e9b; files: src/infra/shell-env.ts, src/infra/shell-env.test.ts, CHANGELOG.md)
• @steipete: Local history shows the shared shell-env helper and tests were introduced in commit 44da6d2, which added src/infra/shell-env.ts and src/infra/shell-env.test.ts. (role: introduced behavior; confidence: high; commits: 44da6d2e9067; files: src/infra/shell-env.ts, src/infra/shell-env.test.ts)
• @vincentkoc: Current-main blame for the shell-env helper area points to recent maintenance around src/infra/shell-env.ts, making this a plausible routing contact for adjacent shell-env behavior. (role: recent adjacent maintainer; confidence: medium; commits: c5ea7c4d0fa4; files: src/infra/shell-env.ts, src/infra/shell-env.test.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 8e533490ab0a.