Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#141 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
node.js, typescript
Ambito
cli, devtools, operating-systems

Direzione di ricerca

Inizia riproducendo l’accumulo di processi Windows con Get-CimInstance Win32_Process, quindi leggi components/codegraph/src/hook.ts, components/bootstrap/src/hook.ts e i percorsi di spawning di components/lsp-daemon/. Confronta il numero di helper tra sessioni sequenziali e verifica che il teardown o il riutilizzo mantengano i conteggi entro limiti, mentre CodeGraph, git-bash-mcp e lsp-daemon continuano a funzionare nelle conversazioni attive.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
TypeScript
Stelle
3.8k
Fork
246
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di code-yeongyu/lazycodex

Tutte le issue di code-yeongyu/lazycodex

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.