fix(pi): hide detached process windows on Windows#604
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughChangesWindows process visibility
Estimated code review effort: 2 (Simple) | ~15 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Alan-TheGentleman
left a comment
There was a problem hiding this comment.
Thanks for chasing this down — the bug in #599 is real and worth fixing.
The problem is that this fixes the wrong layer. The evidence chain in #599 is engram serve → git.exe → conhost.exe → WindowsTerminal.exe, i.e. the windows come from Go-side subprocesses, not from the Node spawn. Those live at internal/project/detect.go:282 (git -C … rev-parse --show-toplevel) and :381 (git … remote get-url origin) — the exact commands in your report. rg "HideWindow|CreationFlags|SysProcAttr" returns nothing across the repo, so no Go call site currently suppresses a console.
windowsHide on the Node spawn only suppresses the engram serve window. A console-subsystem child like git.exe launched from a console-less parent still allocates its own console, so the transient windows you're seeing would persist.
- Move the fix into Go: set
SysProcAttr{HideWindow: true}ondetect.go:282and:381behind a//go:build windowshelper. This also matches the thin-adapter rule — plugins are shims, logic belongs in core. - Keep
windowsHide: trueas a complementary plugin change if you like, but replace the source-regex test: assertingwindowsHide: true,appears beforedetached: true,breaks on any key reorder without a behavior change. - Rebase — #640 just landed and rewrote
plugin/pi/index.tssubstantially, including movingspawnDetached.
I'll get #599 labelled status:approved so this isn't blocked on process.
6211fcb to
67f66ee
Compare
Alan-TheGentleman
left a comment
There was a problem hiding this comment.
This is exactly the change I was asking for, and then some. Approving.
You moved the fix to the layer where the bug actually lives: newProjectCommandContext behind //go:build windows setting SysProcAttr{HideWindow: true}, with a plain passthrough for every other platform, wired into detectGitRootDir and detectFromGitRemote — the two git.exe call sites named in #599's engram serve → git.exe → conhost.exe chain. Keeping windowsHide: true on the Node spawn as a complementary change is right too, and you dropped the brittle source-regex test I flagged.
What I verified locally on your branch, rebased onto current main:
GOOS=windows GOARCH=amd64 go build ./...passes. Worth calling out becausecommand_windows.goand itssyscall.SysProcAttrnever compile on the maintainers' macOS machines or in the default CI job, so this file could have been broken without anyone noticing. It isn't.go build ./...and the fullgo test ./...pass, 22 packages.plugin/pisuite passes 42/42, so theindex.tschange composes cleanly with #640 which rewrote that file.TestNewProjectCommandContextPreservesDefaultProcessAttributesandTestProjectDetectionGitCommandsUsePlatformHelperboth pass.
The AST-based test is a nice touch. Asserting that each detection function calls the helper exactly once means a future contributor who reaches for a raw exec.CommandContext there gets a failing test instead of silently reintroducing the console flash. That's the right way to guard a platform behavior you can't assert on directly from CI.
Follow-up, not blocking this PR
Two other subprocess call sites are in the same bug class but outside #599's reported path, so I don't want to hold this fix for them:
internal/llm/claude.go:140(defaultRunCLI) spawns the agent CLI and will flash a console on Windows the same way.internal/setup/setup.go:36(runCommand) does too, though it runs during interactiveengram setupwhere a console window is far less surprising.
Happy to open a separate issue for those, or you can if you want to carry the work forward — the helper you built here is the obvious thing to reuse, probably lifted somewhere both packages can import.
763a6ba
into
Gentleman-Programming:main
|
Merged. Opened #641 to track the remaining call sites ( |
🔗 Linked Issue
Closes #599
🏷️ PR Type
type:bug— Bug fixtype:feature— New featuretype:docs— Documentation onlytype:refactor— Code refactoring (no behavior change)type:chore— Maintenance, dependencies, toolingtype:breaking-change— Breaking change📝 Summary
windowsHide: truespawn option.📂 Changes
plugin/pi/index.tswindowsHide: truewhen spawning detached Engram processes.plugin/pi/test/index-source.test.mjs🧪 Test Plan
go test ./...go test -tags e2e ./internal/server/...cd plugin/pi && node --test test/index-source.test.mjs(spawnDetached hides detached process windows)The targeted regression assertion passes. The test file still reports two unrelated, pre-existing
Cannot use import statement outside a modulefailures that reproduce onupstream/main.🤖 Automated Checks
These run automatically and all must pass before merge:
Closes/Fixes/Resolves #Nstatus:approvedlabeltype:*labelgo test ./...passesgo test -tags e2e ./internal/server/...passes✅ Contributor Checklist
Closes #N) (linked, awaiting maintainer approval)type:*label to this PR (awaiting maintainer permissions)go test ./...go test -tags e2e ./internal/server/...Co-Authored-Bytrailers in commits💬 Notes for Reviewers
Issue #599 is not yet labeled
status:approved, and this fork contributor cannot add repository labels. A maintainer needs to:status:approvedto fix(windows): Engram Git subprocesses open transient terminal windows #599 andtype:bugto this PR;Summary by CodeRabbit
Bug Fixes
Tests