Windows: Daemon process creates flashing black console windows

[hukangping]

After upgrading to v0.9.5/v0.9.6 on Windows, the new shared daemon process repeatedly opens and closes blank console windows, which is very disruptive. Setting CODEGRAPH_NO_DAEMON=1 works as a temporary fix. It would be great if the daemon could run completely hidden on Windows by default.

[neavo]

same issue

[AlexChim1231]

same issue, CODEGRAPH_NO_DAEMON=1 is not work for me,

[seeblog]

same issue

[wrong7]

Same issue

[linpeilie]

same issue

[neavo]

same issue, CODEGRAPH_NO_DAEMON=1 is not work for me,

not work for me too

[thismilktea]

Based on a code-path review of the Windows startup flow in v0.9.5/v0.9.6, it doesn’t look definitive that the detached
shared-daemon child itself is the visible process users are seeing.

One notable detail is that the actual daemon spawn in src/mcp/index.ts already uses windowsHide: true, so the detached
daemon child may not be the primary source of the blank console windows.

A more likely suspect is the outer startup / relaunch path around daemon mode. In particular,
src/extraction/wasm-runtime-flags.ts does an early:

spawnSync(process.execPath, argv, {
stdio: 'inherit',
env: { ...process.env, ... },
});

and that spawnSync(...) does not currently set windowsHide: true.

So from the current code, a plausible explanation is that Windows users are seeing one or more outer console processes
in the daemon-mode startup chain / wasm relaunch path, rather than the detached daemon child itself.

This may also explain why CODEGRAPH_NO_DAEMON=1 helps some users but not others: it disables shared-daemon mode, but
it does not bypass the earlier relaunch path.

I’m not claiming this is a confirmed root cause yet, but it seems like the most promising place to investigate first:

• add windowsHide: true to the relaunch spawnSync(...) in src/extraction/wasm-runtime-flags.ts
• if needed, audit the MCP startup path (src/bin/codegraph.ts, src/extraction/wasm-runtime-flags.ts, src/mcp/index.ts)
  before making broader subprocess changes elsewhere

[AlexChim1231]

@thismilktea thanks for your help, this is happen when the code save, i tried to record the pop up console processes via shift+win+r, but seem my computer is not good enough, it cannot clearly to show what program run actually because they close very fast, i can only see there are 3 console pop, and one of them is git. hope this may help you!

[thismilktea]

@thismilktea thanks for your help, this is happen when the code save, i tried to record the pop up console processes via shift+win+r, but seem my computer is not good enough, it cannot clearly to show what program run actually because they close very fast, i can only see there are 3 console pop, and one of them is git. hope this may help you!

Thanks. Based on the details you shared, this looks most likely related to one or more background sync subprocesses not setting windowsHide: true on Windows. A PR has already been opened to investigate/address that path.

[yushengruohui]

Tracked this down — opened #505 with the fix.

Root cause: The daemon shells out to git via execFileSync at 7 call sites in src/extraction/index.ts, src/sync/worktree.ts, and src/sync/git-hooks.ts, and none of them pass windowsHide: true. Node defaults that option to false. The daemon itself is started with detached: true (mcp/index.ts), so it has no parent console — and on Windows, any Console-subsystem child of a console-less parent gets a freshly allocated console window unless CREATE_NO_WINDOW is set. windowsHide: true maps to CREATE_NO_WINDOW. Each short-lived git invocation therefore opens and immediately closes its own window, which is the "flicker."

The daemon launcher itself already passes windowsHide: true — these git call sites were just missed.

Workaround on v0.9.6 without the patch: CODEGRAPH_NO_DAEMON=1 as @hukangping noted, or hand-patch the 7 call sites in %LocalAppData%\codegraph\current\lib\dist\ and kill the PID in .codegraph\daemon.pid to respawn.

The fix in #505 is a one-line addition per call site and is a no-op on macOS/Linux.