Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#141 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
cli, devtools, operating-systems

Línea de trabajo

Comienza reproduciendo la acumulación de procesos de Windows con Get-CimInstance Win32_Process; después, lee components/codegraph/src/hook.ts, components/bootstrap/src/hook.ts y las rutas de spawning de components/lsp-daemon/. Compara el número de helpers entre sesiones secuenciales y verifica que el teardown o la reutilización mantengan acotados los recuentos, mientras CodeGraph, git-bash-mcp y lsp-daemon siguen funcionando en conversaciones activas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
TypeScript
Estrellas
3.8k
Forks
246
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de code-yeongyu/lazycodex

Todos los issues de code-yeongyu/lazycodex

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.