Windows: OMO helper node processes accumulate far beyond active conversation count

[RuszLi]

Summary

On Windows, OMO helper Node processes accumulate far beyond the number of active conversations when running Codex Desktop with the bundled OMO plugin. With only 3 active conversations, I observed 27 repeated helper bundles (codegraph, git-bash-mcp, lsp-daemon) still resident for hours, causing heavy memory usage and UI lag.

Environment

• LazyCodex / OMO plugin version: sisyphuslabs/omo 4.19.0 from the local Codex plugin cache
• Codex version: codex-cli 0.145.0
• OS: Windows
• Install method: Codex Desktop with marketplace/plugin cache under C:\Users\Rusz\.codex\plugins\cache\sisyphuslabs\omo\4.19.0
• Relevant config: OMO enabled; only 3 active conversations during observation

Repository Decision

• Target repository: code-yeongyu/lazycodex
• Why this belongs there: the repeated helper trees originate from OMO plugin components, not only from generic Codex processes.
• LazyCodex evidence (runtime + local installed source):
  • Repeated command lines all point into C:\Users\Rusz\.codex\plugins\cache\sisyphuslabs\omo\4.19.0\...
  • Observed repeats:
    • 27 x components/codegraph/dist/serve.js
    • 27 x components/git-bash-mcp/dist/cli.js mcp
    • 27 x components/lsp-daemon/dist/cli.js mcp
    • 27 x codegraph npm-shim
    • 27 x codegraph-win32-x64 ... serve --mcp
  • components/codegraph/src/hook.ts spawns a detached background worker on every eligible SessionStart.
  • components/bootstrap/src/hook.ts also spawns a detached background worker.
  • components/lsp-daemon/dist/ensure-daemon.js / dist/cli.js spawn a detached daemon process.
• Upstream Codex evidence:
  • openai/codex already has similar Windows MCP leak issues open, including #28361, #30408, #31499, #32797, #34614, #34704.
  • That suggests a nearby ownership boundary, but this specific helper bundle is OMO-owned because the repeated commands and paths are all under the OMO plugin cache.

Reproduction

1. Run Codex Desktop on Windows with the bundled OMO plugin enabled.
2. Open and use a few conversations over time. In my case there were only 3 active conversations.
3. Inspect running processes in Task Manager or with Get-CimInstance Win32_Process.
4. Group by command line and observe repeated OMO helper bundles remaining resident long after the conversations that likely spawned them.

Expected Behavior

Helper processes should be shared where possible and should be reaped when the owning conversation or session ends. Process count should stay roughly proportional to active work.

Actual Behavior

Helper bundles accumulate over time and remain resident well beyond the active conversation count. The machine becomes noticeably laggy, and dozens of node.exe processes remain alive.

Evidence

• Runtime grouping from Get-CimInstance Win32_Process | Group-Object CommandLine:
  • 27 x codegraph/dist/serve.js
  • 27 x git-bash-mcp/dist/cli.js mcp
  • 27 x lsp-daemon/dist/cli.js mcp
• Old roots still resident:
  • opencode.exe pid=25024 started 2026-07-25 16:16:43
  • opencode.exe pid=35736 started 2026-07-25 16:18:43
• Codex root also retained many historical children under codex.exe pid=22096, with child start times spanning 2026-07-24 23:55 to 2026-07-25 17:42
• Repeated helper chain shape:
  • node.exe codegraph/dist/serve.js
  • npm-shim.js serve --mcp
  • codegraph-win32-x64 ... serve --mcp
  • watchdog node.exe -e "..."
  • sibling git-bash-mcp
  • sibling lsp-daemon
• Listener footprint was small, which suggests these are mostly lingering stdio/helper workers rather than legitimate long-lived listening services:
  • only one obvious node listener was observed: 127.0.0.1:19825 from opencli daemon.js

Root Cause

The strongest current evidence is a lifecycle gap in OMO-managed helper processes on Windows:

• components/codegraph/src/hook.ts uses spawn(..., { detached: true, stdio: "ignore" }) plus child.unref() for the SessionStart worker.
• components/bootstrap/src/hook.ts does the same for bootstrap work.
• lsp-daemon also uses detached daemon spawning.

That pattern is valid for background work, but with only 3 active conversations it should not leave 27 repeated helper bundles alive for hours. The observed process trees suggest one of these is happening:

• helper trees are not being reaped after the owning session ends
• helper suites are started per historical session instead of being reused/shared
• Windows termination does not reach the full helper subtree consistently

Proposed Fix

• Audit helper lifecycle ownership for:
  • components/codegraph/src/hook.ts
  • components/bootstrap/src/hook.ts
  • components/lsp-daemon/*
• Add explicit ownership and teardown for Windows helper trees, instead of relying on detached background workers to disappear naturally.
• Consider a shared process model for git-bash-mcp, lsp-daemon, and CodeGraph MCP helpers so they are reused across sessions instead of spawned per session.
• Add regression coverage that opens multiple sessions sequentially and asserts helper count remains bounded after session close.

Verification Plan

• Reproduce on Windows with 3 active conversations and record helper counts by command line before the fix.
• Apply the lifecycle fix and repeat the same workflow.
• Confirm that historical helper bundles are reaped after session end or reused instead of duplicated.
• Confirm that CodeGraph, git-bash-mcp, and lsp-daemon still function normally in active conversations.

---

This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated