wiki-worker spawns a headless `claude -p` per capture event: flashing console windows on Windows, ~5x process churn, continuous background API calls

この issue は bundle/capture.js と bundle/wiki-worker.js にあります。まず、headless Claude プロセスを起動する wiki-worker.js の spawn ロジックを調べてください。Node.js の child_process.spawn 呼び出しを探し、Windows でコンソールウィンドウを非表示にするために windowsHide: true の追加を検討してください。また、プロセスの頻繁な生成を減らすため、capture イベントのバッチ処理またはデバウンスも調査してください。プラグインを実行し、tool activity に伴うプロセス生成を観察してテストしてください。

Bug report: wiki-worker spawns a headless Claude Code process per capture event, flashing console windows on Windows

Component: @deeplake/hivemind Claude Code plugin
Affected versions: 0.7.131 and 0.7.142 (spawn logic identical in both)
Platform: Windows 11 Home 26200 (behavior is Windows-specific in its visible symptom; the underlying spawn cost is cross-platform)
Severity: Medium. Not data-losing, but continuously disruptive, and it consumes CPU and model API calls in the background.

---

Summary

While a Claude Code session is doing any tool work, bundle/capture.js launches bundle/wiki-worker.js, and that worker launches a complete headless Claude Code process (claude -p --model <model> --permission-mode bypassPermissions) on a repeating basis.

On Windows, each of those child processes allocates a console, which Windows hands to WindowsTerminal.exe. The result is a black terminal window that appears on screen and takes focus roughly every 5 to 6 seconds for as long as the user is working.

The visible window is Claude Code's own IDE-detection probe, not hivemind code. But hivemind is what causes it to run on a loop, so the two are only a problem in combination.

---

Root cause: observed process ancestry

Captured with a WMI __InstanceCreationEvent subscription (WITHIN 0.05), resolving each new process's ancestor chain at creation time. Polling-based sampling misses these; they live well under 250ms.

node.exe   .../hivemind/0.7.131/bundle/wiki-worker.js  <tempfile deeplake-wiki-<session-id>>
  └─ cmd.exe  /d /s /c "…\npm\claude.cmd -p --no-session-persistence
                        --model haiku --permission-mode bypassPermissions"
       └─ claude.exe   (headless Claude Code)
            └─ cmd.exe /d /s /c "tasklist | findstr /I "Code.exe Cursor.exe Windsurf.exe
                                 Devin.exe idea64.exe pycharm64.exe webstorm64.exe
                                 phpstorm64.exe rubymine64.exe clion64.exe goland64.exe
                                 rider64.exe datagrip64.exe appcode.exe dataspell64.exe
                                 aqua64.exe gateway64.exe fleet.exe studio64.exe""
                 └─ tasklist.exe  +  findstr.exe
                      └─ svchost → WindowsTerminal.exe -Embedding   ← the visible window

Every level of that chain repeats on each capture event. capture.js is registered on UserPromptSubmit, PostToolUse, Stop, and SubagentStop, so ordinary tool traffic drives it.

---

Measurements

Two 45-second windows, comparable Claude Code tool activity in each (roughly 10 tool calls), same machine, same session type. Only enabledPlugins."hivemind@hivemind" differed.

Processes created per 45s	hivemind enabled	hivemind disabled
WindowsTerminal.exe (visible window)	6 to 7	0
tasklist.exe / findstr.exe	6 to 7 each	0
headless claude.exe spawned	17 to 20	0
node.exe	25 to 31	8
conhost.exe	81 to 108	15
bash.exe	55 to 70	25
total process creations	~250	~55

Disabling the plugin removes the visible windows entirely and cuts total process creation by roughly 5x.

---

Version comparison: 0.7.131 vs 0.7.142

Updating did not change the behavior. The relevant logic is identical:

	0.7.131	0.7.142
bundle/wiki-worker.js present	yes	yes
capture.js references to wiki-worker	3	3
spawns headless claude -p	yes	yes
--no-session-persistence	yes	yes
--permission-mode bypassPermissions	yes	yes

Confirmed by direct user observation on 0.7.142 after a clean plugin update via claude plugin update hivemind@hivemind.

---

Secondary impact

Defender CPU. Windows Defender real-time protection scans each process image at creation. At roughly 5.5 process creations per second sustained, MsMpEng.exe (Antimalware Service Executable) was observed holding around 19.6% CPU for the duration of active work. This disappears when the plugin is disabled.

Model API consumption. Each spawn is a real claude -p invocation against the configured model. At the observed rate this runs continuously in the background, invisible to the user, and is not obviously disclosed.

Permission posture. The spawned processes run with --permission-mode bypassPermissions. Given the spawn rate, users may not realize how many unattended agent processes are running under bypassed permissions.

---

Reproduction

1. Windows 11, Claude Code desktop, hivemind plugin enabled.
2. Start a session and give it continuous tool work for about a minute.
3. Observe a console window appearing and taking focus every 5 to 6 seconds.
4. Set "hivemind@hivemind": false in ~/.claude/settings.json. This takes effect immediately, no restart required, since hook config is re-read per event.
5. Repeat step 2. The windows stop.

To capture the ancestry rather than eyeball it, subscribe to WMI __InstanceCreationEvent WITHIN 0.05 for Win32_Process and resolve ParentProcessId at event time. Snapshot polling at 250ms intervals misses these entirely and produces a false negative.

---

Notes on what did not fix it

• Setting Default terminal application to Windows Console Host (Settings > System > Advanced > Terminal). Measured before and after: no change, 6 to 7 WindowsTerminal.exe launches in both. The handoff still occurs.
• Updating the plugin 0.7.131 to 0.7.142.

---

Suggested fixes, roughly in order of preference

1. Do not spawn a full Claude Code process per capture event. Batch, debounce, or defer wiki generation to session end. This is the fix that addresses CPU, API consumption, and the window flashing at once.
2. Reuse a single long-lived worker instead of a new process per event.
3. Pass CREATE_NO_WINDOW (or equivalent windowsHide: true on the Node spawn options) down the whole chain, so any console the children allocate is never shown. This addresses the visible symptom even if the spawn rate stays as-is.
4. Expose a documented off switch for the wiki worker specifically. Env vars such as HIVEMIND_WIKI_WORKER and HIVEMIND_GRAPH_ON_STOP appear in the bundle but their semantics are not documented, so today the only reliable remedy is disabling the entire plugin and losing memory capture along with it.

Point 3 may belong upstream with Claude Code as well, since the IDE-detection probe (tasklist | findstr) is Claude Code's own startup behavior and it allocates a visible console on Windows. It is only noticeable because hivemind runs it hundreds of times per hour.

---

Current workaround

"hivemind@hivemind": false in ~/.claude/settings.json. Effective immediately, no restart. Costs all cross-session memory capture and recall.