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

# 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 --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 >
└─ 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.