fix(vscode Windows): fix native memory leak in Agent Manager git polling

[alex-alecu]

Problem

The kilo serve process grows to multiple GB of RAM within minutes when the Agent Manager is active. Users on Windows see 6–7 GB of memory consumed, making the extension unusable for longer sessions.

This is upstream Bun bug #18265 — "Memory leak in Bun.spawn with subprocess polling". It is our bug to the pixel.

The smoking-gun match

Their repro	Our situation
Polls a small subprocess every 1–2 s	Polls git subprocesses every ~1 s per worktree
stdio: ['ignore', 'pipe', 'pipe']	Same stdio shape (pipe for stdout + stderr)
RSS climbs to 1 GB over 12 hours	RSS climbs to ~2.1 MB/spawn, ~3 GB in ~25 min at our rate
Heap is flat	Heap is flat
Node's child_process.spawn doesn't leak — only Bun	We confirmed this too by switching APIs within the Bun runtime: identical leak

What Bun actually did about it

1. Issue #18265 was closed by fix(spawn): memory leak in "pipe"d stdout/stderr oven-sh/bun#18316 in March 2025, but the reporter came back one day later and said "I'm still seeing the leak" — the fix didn't cover the real case.
2. fix memory leak when pipe Bun.spawn stdio is never read repeatedly oven-sh/bun#20102 was another attempt targeting the same leak.
3. In a related open issue #21560 (Aug 2025), Bun's CEO (Jarred) confirmed the root cause is mimalloc arena retention — the Windows/Linux allocator Bun ships with holds on to freed pages and doesn't return them to the OS. He gave a workaround: MIMALLOC_PURGE_DELAY=0 as an env var.
4. Three Windows-specific pipe handle fixes (PRs #27064, #27124, #27171) landed in Feb 2026 but those fix crashes ("use-after-free in WindowsStreamingWriter", "handle_queue corruption"), not the slow memory growth. They may still help reduce retention somewhat.
5. The original reporter of #18265 ultimately gave up and rewrote their app to spawn a Go sidecar once and talk to it over gRPC, because no Bun-side fix eliminated the leak fully.

Memory debugging

This is not a JavaScript memory leak. V8 heap stays at ~130 MB the entire time. The growth is in native memory — Bun's mimalloc allocator reserves 1 GB segments for each arena and never returns them to the OS.

Initial VMMap breakdown of a real session:

Region	Size
Private Data (mimalloc)	6.5 GB (7 x ~1 GB segments)
V8 Heap	130 MB
Handle count	267 (normal)
GC freed	0 bytes

Each git subprocess call via Bun's shell template buffers the entire stdout into a native allocation, and over a polling session those buffers become the high-water marks that mimalloc keeps forever.

Memory debug (full dump analysis)

Parsed kilo.DMP (3.95 GB minidump, taken before a later VMMap snapshot):

Committed memory at dump time: 3,770 MB (vs. 1,890 MB at VMMap time — the process oscillates by ~2 GB as mimalloc grows and partially purges).

Top private allocations:

Base address	Committed	Regions	Notes
0x000003a5e0000000	1,022 MB	40	1 GB arena (1 GB aligned)
0x000003a620000000	959 MB	34	1 GB arena
0x000003a5a0000000	622 MB	66	1 GB arena
~20× 0x000001f5*	15–128 MB each		individual segments

The three 0x3a5*_00000000-aligned bases, each spaced exactly 1 GB apart, are mimalloc "huge arena" reservations — the Bun allocator grabbing 1 GB slabs from Windows and not returning them. Those three arenas alone hold 2.6 GB (74% of committed private memory).

Threads (28 at dump time, ~48 at VMMap time): all idle in ntdll!NtWaitForAlertByThreadId. Distinct stack signatures cluster into three fixed pools (10 + 7 + 4 threads) — consistent with JSC's parallel-GC / compiler / libuv pools. No evidence of per-spawn thread leaks. The 28→48 growth is additional worker slots filling in as load ramps up, not a per-request leak.

The two real sources of the retained 2.6 GB

1. High-water of transient buffers in the worktree diff path. Each poll on 3–4 worktrees spawns ~5 git processes, and for each one the old shell-template call path copied stdout through several intermediate buffers before exposing it as a string. Even at 15 s intervals this produces ~100 MB/min of churn, and mimalloc grows its arenas to absorb concurrent peaks without ever returning them.

2. Instance cache holds everything forever. The server keeps one long-lived Instance per worktree directory and never evicts it. Every directory that ever served a request keeps its LSP state, parcel-watcher subscription, snapshot state, plugin state, bus subscriptions, and DB handles resident. For several worktrees of a ~100k-file repo this easily accounts for several hundred MB that never shrinks.

Where source (1) actually comes from in the code

Drilling into source (1) above: the "~5 git processes per poll" is produced by two concurrent polling timers in the VS Code extension, both of which HTTP-call into the CLI on every tick, and each HTTP call fans out to 3 git subprocesses server-side:

flowchart TD
    A[Agent Manager panel visible] --> B[GitStatsPoller<br/>setInterval 5000ms]
    A2[Review diff panel open] --> C[WorktreeDiffController<br/>setInterval 2500ms]

    B --> D[client.worktree.diffSummary<br/>one HTTP call per worktree + main repo]
    C --> D

    D --> E[CLI route /worktree/diff-summary<br/>packages/opencode/src/server/routes/experimental.ts:382]

    E --> F[WorktreeDiff.summary<br/>packages/opencode/src/kilocode/review/worktree-diff.ts]

    F --> G1[git merge-base HEAD base<br/>cached 30s]
    F --> G2[git diff --numstat ...]
    F --> G3[git diff --name-status ...]
    F --> G4[git ls-files --others ...]

    G2 -.-> H[Bun.spawn stdio: pipe/pipe<br/>~2.1 MB leaked per call on Windows]
    G3 -.-> H
    G4 -.-> H
    G1 -.-> H

Loading

The two timers:

Timer	File:line	Interval	Fires when
GitStatsPoller.intervalMs	packages/kilo-vscode/src/agent-manager/GitStatsPoller.ts:69	5 s visible / 60 s hidden	Agent Manager panel has any worktrees OR panel is open
WorktreeDiffController.interval	packages/kilo-vscode/src/agent-manager/worktree-diff-controller.ts:201	2.5 s	Review diff sub-panel open for a session

Each tick of GitStatsPoller.fetchWorktreeStats() fans out in parallel: worktrees.map(async (wt) => ... diffSummary(wt.path, base) ...) — i.e. one HTTP call per worktree, plus one more from fetchLocalStats() for the main repo. Results are deduped by hash (unchanged data isn't re-sent to the webview), but the git subprocesses have already run and leaked by the time the hash check happens.

Inside WorktreeDiff.summary() → list(), each HTTP call runs:

1. git merge-base HEAD <base> — cached 30 s per (dir, base) in the ancestors Map, so amortized ≈ 0 spawns/tick after warmup
2. git diff --numstat --no-renames <ancestor> — in stats()
3. git diff --name-status --no-renames <ancestor> — in list()
4. git ls-files --others --exclude-standard — in list() for untracked files

So 3 spawns per summary() call, every call, no caching. With W worktrees, Agent Manager visible, main repo stats enabled, no Review panel open:

spawns/sec on CLI = (W + 1) × 3 / 5           # 5 s tick, +1 for main repo
                  ≈ (2+1) × 3 / 5 = 1.8 spawns/sec
leak rate         = 1.8 × 2.1 MB × 60 = 227 MB/min

Add a Review panel: another 3 / 2.5 = 1.2 spawns/sec → total ~3 spawns/sec, matching the ~3 GB-in-24-min burn measured with the probe. The busy flag in GitStatsPoller skips overlapping ticks when git takes >5 s under memory pressure, which is why the sustained observed rate was 0.88/s (roughly half the calculated rate).

What would fix the polling itself (if the env var isn't enough)

MIMALLOC_PURGE_DELAY=0 treats the symptom (native memory not returned to OS). The polling rate itself is untouched, so the CLI still spawns 3 git processes per tick forever. Three non-invasive follow-ups, in order of impact:

1. Adaptive backoff on GitStatsPoller — lastHash === hash is already detected; double the interval each time the hash doesn't change, reset on change. Cuts idle-workspace spawn rate by ~5×.
2. Replace WorktreeDiffController 2.5 s timer with file-watcher-driven invalidation (VS Code workspace.createFileSystemWatcher). Only fire request() when files actually change.
3. Short-TTL (3–5 s) cache inside WorktreeDiff.summary() keyed on (dir, base). Simple, caller-agnostic, catches both pollers at once.

[kilo-code-bot]

Code Review Summary

Status: 4 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	4
SUGGESTION	0

Fix these issues in Kilo Cloud

Issue Details (click to expand)

No issues on lines currently commentable in gh pr diff.

Other Observations (not in diff)

Issues found in unchanged code that cannot receive inline comments:

File	Line	Issue
packages/kilo-vscode/src/worktree-diff-client.ts	35	Revert status lookup still calls client.worktree.diffFile(), which resolves the full CLI diff-detail payload and can reintroduce large kilo serve memory spikes for oversized files.
packages/opencode/src/kilocode/review/worktree-diff.ts	232	readBefore() in the CLI worktree-diff route is still uncapped, so non-VS-Code clients can still materialize a large ancestor blob in memory when opening diff detail.
packages/opencode/src/project/instance.ts	17	Idle instance eviction remains removed, so long-lived worktree instances keep watchers, LSP state, snapshot repos, and DB handles resident until the server restarts.
packages/kilo-vscode/src/agent-manager/AgentManagerProvider.ts	810	Worktree deletion still skips client.instance.dispose({ directory: worktree.path }), leaving the removed worktree's server-side instance cached indefinitely.

Files Reviewed (2 files)

• .changeset/fix-agent-manager-memory-leak.md - 0 issues
• packages/kilo-vscode/src/agent-manager/local-diff.ts - 0 issues

---

_{Reviewed by gpt-5.4-20260305 · 1,756,931 tokens}

[alex-alecu]

Possible workarounds

Why npm packages can't fix this

Every npm spawn helper eventually calls node:child_process.spawn(). When Bun imports node:child_process, it's Bun's polyfill — it ends up in the same Zig bun.js/api/bun/spawn/* code path that leaks. That's not a limitation of any specific package, it's Bun's implementation strategy. Packages ruled out for this reason:

Package	Why it won't help
execa, nanospawn, tinyspawn, zx, dax, bun-utils	Wrappers around child_process.spawn
cross-spawn	Pre-launch argv munger, spawns via child_process
simple-git	Calls child_process.spawn under the hood
Bun's own Bun.$	Literally calls Bun.spawn with "pipe" stdio
@parcel/workers, piscina, node:worker_threads	Workers share the runtime + allocator — no help

There is no npm package that bypasses Bun's internal spawn allocator from within Bun, because it's a runtime-layer concern. The only routes that escape it are:

1. Don't use "pipe" (use files or "ignore"), OR
2. Don't run the spawn inside the Bun process (sidecar).

Four workarounds, in order of cost

flowchart TD
  Bug[Bun.spawn + pipe stdio<br/>mimalloc arena retention] --> T1
  T1[Tier 1: Bun.file redirect<br/>~2h work, low risk] -->|if not enough| T2
  T2[Tier 2: Move AM polling to<br/>extension host Node.js<br/>~1 day, VS Code only] -->|if not enough| T3
  T3[Tier 3: Long-lived<br/>Node or Go sidecar<br/>~1 week, all platforms] -->|if we want to be done forever| T4
  T4[Tier 4: Pair Tier 1 + Tier 3<br/>+ periodic sidecar recycle]

Loading

Tier 1 — Redirect stdout/stderr to temp files instead of pipes

Biggest bang for the buck. Probably fixes the leak in an afternoon.

Bun's docs explicitly support Bun.file() or a raw fd as stdout/stderr:

// From Bun's own API reference:
stdio?: [Writable, Readable, Readable]
type Readable = "pipe" | "inherit" | "ignore" | null | Bun.BunFile | number

Because the leak lives in the "pipe" readable's Buffer.concat / mimalloc retention path, redirecting to a file fd sidesteps it entirely. Pattern:

import { tmpdir } from "node:os"
import path from "node:path"
import fs from "node:fs/promises"
import { randomUUID } from "node:crypto"

async function run(cmd: string[], opts: { cwd?: string } = {}) {
  const stem = path.join(tmpdir(), `kilo-spawn-${randomUUID()}`)
  const outPath = `${stem}.out`
  const errPath = `${stem}.err`
  try {
    const proc = Bun.spawn(cmd, {
      cwd: opts.cwd,
      stdin: "ignore",
      stdout: Bun.file(outPath),
      stderr: Bun.file(errPath),
      windowsHide: true,
    })
    const code = await proc.exited
    // fs.readFile allocates a single Buffer; no streaming pipe buffers ever exist
    const [stdout, stderr] = await Promise.all([fs.readFile(outPath), fs.readFile(errPath)])
    return { code, stdout, stderr }
  } finally {
    await Promise.allSettled([fs.unlink(outPath), fs.unlink(errPath)])
  }
}

Where to apply it in Kilo:

• packages/opencode/src/kilocode/review/worktree-diff.ts — the 6 $-calls (git merge-base, git diff --numstat, git diff --name-status, git ls-files, git show, git ls-files --error-unmatch) are Kilo's actual smoking gun per PR fix(vscode Windows): fix native memory leak in Agent Manager git polling #9046. This file alone is the Agent Manager's polling hotspot.
• packages/opencode/src/kilocode/review/review.ts, kilocode/project-id.ts, kilocode/snapshot/index.ts — the three other Bun.$ users on the polling paths.
• util/process.ts — optionally add a stdout: "file" mode for the upstream Process.run helper.

Caveats / what to measure:

• Needs empirical verification. All public evidence (Jarred's own pipe-path analysis, DonIsaac's #18316 post-mortem, iitzkube's stdio: 'ignore' experiment) points to the pipe machinery as the leak site, but nobody has published a Bun.file()-stdout leak benchmark. A ~30-minute polling test would confirm it.
• Temp-file churn on Windows has its own cost (NTFS journal, antivirus scans) — keep files in %TEMP%, not the repo dir, and reuse a single pair of paths per worktree if the spawn rate gets high.
• Pathological output (gigabyte-sized git show on a binary blob) will now hit disk instead of OOMing memory — that's arguably an improvement.

Tier 2 — Move Agent Manager git polling OUT of kilo serve

The architectural shortcut. Specific to the VS Code extension path.

The leak's actual trigger (per PR #9046) is GitStatsPoller and WorktreeDiffController in packages/kilo-vscode/src/agent-manager/ HTTP-calling /worktree/diff-summary every 2.5–5s per worktree. Each call lights up 3 git subprocess spawns inside kilo serve.

But the VS Code extension host IS Node.js. It already has a non-leaky child_process.spawn. Those git reads don't need to go through kilo serve at all — they're trivial, directory-scoped operations:

// Inside packages/kilo-vscode/src/agent-manager/GitStatsPoller.ts
// Use src/util/process.ts (extension-side), NOT the CLI HTTP route.
import { exec } from "../util/process"  // already the wrapper that enforces windowsHide

async function diffSummary(dir: string, base: string) {
  const ancestor = (await exec("git", ["merge-base", "HEAD", base], { cwd: dir })).stdout.trim()
  // ...numstat, name-status, ls-files all locally
}

Then the CLI route /worktree/diff-summary only exists for non-VS-Code clients (TUI, desktop), which aren't the leaking scenario.

Pros:

• Zero new binaries. Zero new runtimes. Zero new protocols.
• Fixes the exact path in PR fix(vscode Windows): fix native memory leak in Agent Manager git polling #9046 without touching kilo serve.
• Extension-side spawns can be cancelled when the panel hides (which the HTTP path can't do cleanly).

Cons:

• Only helps the extension. TUI users still hit the leak on their own git operations.
• Duplicates a bit of logic — you end up with a Node-side worktree-diff.ts that mirrors the CLI's, or you extract the shared parsing into @opencode-ai/util.
• Violates the "thin clients over the CLI" architecture described in kilo-vscode/AGENTS.md, so it needs a design call.

Tier 3 — Long-lived Node or Go sidecar

This is the architectural answer. Has public precedent (#18265 reporter and #21560 commenter both went this route).

Design:

sequenceDiagram
  participant Bun as kilo serve (Bun)
  participant SC as kilo-spawn (Node or Go)
  participant Git as git.exe
  Note over Bun,SC: ONE long-lived pipe, drained continuously.<br/>Never accumulates.
  Bun->>+SC: spawn once at startup<br/>stdio: [pipe, pipe, inherit]
  loop for each git request
    Bun->>SC: JSON-RPC {cmd, args, cwd}
    SC->>+Git: child_process.spawn (Node) /<br/>os/exec (Go)
    Git-->>-SC: stdout/stderr/exitCode
    SC-->>Bun: JSON-RPC {code, stdout, stderr}
  end
  Note over SC: Periodically recycled<br/>(e.g. every 30 min)<br/>as belt-and-suspenders

Loading

Why this works: there's only one pipe between kilo serve and the sidecar, and it's read continuously by a loop — no per-spawn allocation bursts for Bun's readable to retain. All the per-git-call allocation lives in the sidecar's allocator (V8 on Node, Go's runtime), neither of which has the mimalloc-retention issue.

Option A — Node sidecar

• Ship a Node SEA (Node Single Executable Applications, stable since Node 22) as kilo-spawn.exe (~80 MB) alongside kilo.exe in bin/.
• Or, for the VS Code extension specifically: skip Node SEA entirely and just use the Node binary that VS Code already ships (process.execPath from the extension host gives you the path to it). Pass it to kilo serve via KILO_SPAWN_NODE env var. Zero bundle cost.
• Implementation is maybe 80 lines:

// bin/kilo-spawn.mjs
import { spawn } from "node:child_process"
import readline from "node:readline"

const rl = readline.createInterface({ input: process.stdin })
rl.on("line", async (line) => {
  const req = JSON.parse(line)
  const proc = spawn(req.cmd[0], req.cmd.slice(1), { cwd: req.cwd, windowsHide: true })
  const out = [], err = []
  proc.stdout.on("data", (c) => out.push(c))
  proc.stderr.on("data", (c) => err.push(c))
  proc.on("close", (code) => {
    process.stdout.write(JSON.stringify({
      id: req.id, code,
      stdout: Buffer.concat(out).toString("base64"),
      stderr: Buffer.concat(err).toString("base64"),
    }) + "\n")
  })
})

Option B — Go sidecar

• ~50 lines of Go, compiles to a 6–10 MB static binary per OS/arch.
• Uses os/exec and the same newline-delimited JSON protocol.
• No runtime to ship, no node_modules, starts in <10ms.
• Cross-compile in CI is trivial (GOOS=windows GOARCH=amd64 go build).
• Matches what the original #18265 reporter ended up doing (though they chose gRPC, which is overkill for this traffic pattern).

Trade-off between A and B: Node is in-ecosystem (same language as the rest of Kilo, extension devs can debug it) but ships more bytes. Go is tighter, starts faster, and has the strongest correctness story for long-running spawn loops (goroutines + bounded buffered channels), but it's a language boundary in an otherwise-TS codebase. For Kilo's current state I'd pick Node because it's ~1 person-day of work; Go if you end up with a third reason to want a spawn sidecar (e.g. tree-sitter parsing at scale).

Sidecar wrapper in Kilo:

// packages/opencode/src/util/spawn-sidecar.ts
class Sidecar {
  proc = Bun.spawn([process.env.KILO_SPAWN_BIN!], { stdin: "pipe", stdout: "pipe" })
  pending = new Map<string, (r: SpawnResult) => void>()
  // ...drain proc.stdout line-by-line, dispatch by id
  async run(cmd: string[], opts: { cwd?: string }) { /* write JSON, await reply */ }
}

And switch util/process.ts to prefer it when KILO_SPAWN_BIN is set.

Tier 4 — Combined: Tier 1 + Tier 3

Ship the Node sidecar for hot paths and use Bun.file() redirection for the odd direct Bun.spawn. Periodically recycle the sidecar (every 30 min of serve uptime, or after N git calls) as a paranoia measure. Cost: Tier 3 work + a handful of lines of bookkeeping.

[alex-alecu]

Fix

Moved the Agent Manager's diff polling out of kilo serve (Bun) and into the VS Code extension host (Node.js). The two hot-path pollers (GitStatsPoller and WorktreeDiffController) now compute diffSummary / diffFile locally via the existing GitOps child_process.spawn infrastructure — same semaphore, same abort signal, same windowsHide: true — instead of HTTP-routing to the CLI, which was triggering 3 Bun.spawn calls per tick per worktree and leaking ~2.1 MB of native memory on every spawn. The CLI diff routes remain intact for non-VS-Code clients (TUI, desktop, kilo web) and the infrequent write paths (apply/revert) still go through the SDK.

After 15 minutes, the Bun process did not increase in memory.