Say when windowsHide is the wrong flag, and hold main.js to it

[juanmaguitar]

Closes #202. Closes #203.

Two halves of the same question, so one PR.

The rule was written for one kind of child

The Windows section of the review standard said the flag flatly:

windowsHide: true keeps console windows from flashing

True for a console child, misleading for a GUI one — and that gap is what produced #181. The editor spawn carried the flag, the editor honored the "start hidden" it puts in STARTUPINFO, and it launched with no window while the spawn still reported success. Left as it was, the rule hands the same advice to the next GUI process someone spawns.

It now turns on the child's subsystem rather than on whether anyone reads the child's output. That distinction matters for more than the editor: src/kill-tree.js sets the flag on taskkill, whose output nobody reads, and an "only if you read its output" rule would have made that line look wrong.

Nothing stopped main from applying the patch

patchChildProcess is deliberately blunt — every child_process entry point, overriding even an explicit windowsHide: false. That is safe today only because the four runners call it and main.js does not, which nothing said and nothing checked.

"Hide the console flashes everywhere, do it once at startup" is the plausible-looking change that reinstates #181 in silence. test/editor-launch.test.cjs injects its own spawn, so it never sees the real module; test/runner-wiring.test.cjs only asserts that the runners do call it.

So the module header now names who must not call it, and test/ipc-wiring.test.cjs asserts main.js does not.

On the test

It watches for a call that does not happen rather than reading the flag off the real child_process. patchChildProcess is a no-op off Windows, so the flag-reading version would be green on macOS whatever main.js did — the "green while proving nothing" shape the standard already names.

Scoped to module evaluation, which is where "once at startup" lands. A call made lazily inside a handler would slip past it; that is a less likely shape, and the module header carries the rule for it.

Testing

• npm test — 610 pass, 0 fail.
• npm run lint — clean.
• Mutation-checked: prepending require('./hide-child-windows').hideChildWindows(); to src/main.js fails the new test, and only that test.
• No runtime behaviour changes — the diff is one document, one comment, one test.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

.github/instructions/code-review.instructions.md:206

• The phrase “turns on the child's subsystem” reads like windowsHide changes the PE subsystem of the spawned binary, which it can’t; the actual point is that the flag’s effect depends on whether the child is a console vs GUI app. Rewording this sentence would avoid confusing future readers.

**`windowsHide: true` turns on the child's subsystem, not on whether anyone reads its output.**

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.