Skip to content

Windows Desktop starts duplicate MCP processes at idle, causing multi-GB RAM usage #46174

Closed as not planned
Closed as not planned
Windows Desktop starts duplicate MCP processes at idle, causing multi-GB RAM usage#46174
Assignees
Hona

Description

@xenstar
xenstar
opened on Aug 29, 2026

What happened

On Windows, OpenCode Desktop appears to start many duplicate local MCP server processes when the desktop app opens with several existing tabs/projects restored. This happens while idle, before sending a new request.

The duplication is much larger than expected: instead of one process per configured local MCP server, the same servers appeared roughly 10 times each. This caused several gigabytes of RAM usage immediately after opening the app.

Environment

  • OpenCode Desktop: 1.18.25
  • OS: Windows
  • Multiple existing tabs/projects restored on startup
  • No active model request when the process snapshot was taken

Observed process breakdown

In one idle snapshot, the OpenCode embedded NodeService owned approximately:

  • 10 GSD MCP server processes
  • 10 OpenViking MCP proxy processes
  • 10 Dida365 MCP server processes
  • 10 grep-app MCP server processes
  • 10 CodeGraph server processes
  • 20 cmd.exe wrappers
  • 55 conhost.exe processes

The OpenCode process tree contained about 147 descendants. Across the system, six OpenCode desktop processes were present. The OpenCode-owned Node workers used roughly 4 GB of working memory, with the OpenCode desktop/WebView processes adding several more GB.

The duplication was visible even though the app was idle. Some CodeGraph processes corresponded to previously opened projects, so restored tabs/projects may be involved, but the repeated tenfold launch of the same MCP servers seems excessive.

Expected behavior

Each configured local MCP server should have at most one active process per required OpenCode instance/session, with terminated or replaced processes cleaned up reliably. Restoring tabs or reconnecting the desktop UI should not multiply every local MCP server by approximately 10.

Related reports

This appears related to #26336, #42270, #43845, #46035, and #31554. The older #26336 report is closed, so this report provides updated data from OpenCode Desktop 1.18.25.

Please let me know if a diagnostic command or process dump would help. The measurements above intentionally omit personal paths, project names, account information, and credentials.

Activity

  1. github-actions
    assigned
    Hona
    on Aug 29, 2026

  2. github-actions commented on Aug 29, 2026

    @github-actions
    github-actionsBot
    on Aug 29, 2026 – with GitHub Actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

    If your issue is distinct (e.g., the Windows-specific scale of ~10x duplication tied to restored tabs), feel free to keep it open and a maintainer will triage.

  3. Bbk1AtJJF8 commented on Aug 29, 2026

    @Bbk1AtJJF8
    Bbk1AtJJF8
    on Aug 29, 2026

    The NodeService in 1.18.25 is launching ten GSD MCP and ten CodeGraph instances each during idle restore of multiple tabs, which tracks with the 20 cmd.exe wrappers and 147 descendants even before any request.

  4. Tyxiel commented on Sep 29, 2026

    @Tyxiel
    Tyxiel
    on Sep 29, 2026

    Confirming this on Windows, and I think the trigger may be different from what the report describes — the duplication here happens in a reconnect loop, with no desktop restart, no tab/project restore, and no config change.

    The distinguishing measurement is the connect/disconnect accounting across my whole log:

    mcp connected server=codegraph : 132
mcp disconnected               :   2

    ~66 reconnects per disconnect. There is no teardown path firing at all, so every reconnect stacks another complete tree on top of the previous ones.

    Reconnect timestamps, last 12:

    10:44:35  10:46:04  10:48:48  11:08:10  11:12:00  11:25:08
11:25:59  11:30:10  11:33:07  11:33:31  11:35:11  11:35:17

    All from a single server instance (run=4482db38), which means this is server-side and autonomous — it does not require opening tabs or restoring projects.

    Process census at one point in time. Every parent is still alive, so the OS never reclaims them:

    PID 35188  parent=Command Code  started 10:29:34  age=4034s
PID  1832  parent=opencode      started 10:48:48  age=2881s
PID 39832  parent=opencode      started 11:08:10  age=1720s
PID 35372  parent=opencode      started 11:12:00  age=1489s
PID 28348  parent=opencode      started 11:25:08  age= 701s
PID 29296  parent=opencode      started 11:30:10  age= 400s
PID  6556  parent=opencode      started 11:33:07  age= 222s

    Each root expands to 4 processes:

    cmd.exe  (npm shim)
 └─ node.exe  ...\npm-shim.js serve --mcp
     └─ node.exe  --liftoff-only ... codegraph.js serve --mcp
         └─ node.exe -e "<watchdog> <pid> 60000 600000"

    That last one is a self-watchdog embedded in the codegraph CLI. Its command line is:

    function kill(extra) { /* "[CodeGraph] Main thread unresponsive for ~Ns" */ process.kill(parentPid, 'SIGKILL'); }

    with timeoutMs=60000 and a capMs=600000 hard cap. Its presence suggests the main codegraph thread is being detected as wedged, something kills or restarts it, and the client reconnects — while the previous tree is never disposed.

    Measured growth over 8 minutes of active reconnects, with no user action beyond leaving the session open:

    1.478 GB / 16 processes
  → 2.811 GB / 30 processes

    ~370 MB per reconnect at a 3–5 minute cadence. Two fresh trees were observed appearing during a single verification pass, one only 21 seconds old when sampled.

    Reproduction

    1. Configure the codegraph local MCP server (type: "local", command: ["codegraph", "serve", "--mcp"]).
    2. Start opencode and leave the session open. Do not open new tabs, do not edit config.
    3. Poll for new processes, or watch Task Manager / Process Explorer.
    4. Count processes whose command line contains codegraph. It only goes up.

    A short observation window can easily land between reconnects and make this look like it has stopped — I initially measured a flat 3-minute window and got a false negative. Sampling over 8+ minutes shows the trend.

    Environment

    • opencode version: 2.0.19 (npm standalone)
    • OS: Microsoft Windows NT 10.0.26200.0 (Windows 11, build 26200, x64)
    • Also occurs under a GUI host: OpenChamber 2.0.4.0, which bundles opencode-cli 1.4.2
    • @colbymchenry/codegraph resolves to an npm shim (codegraph.cmd → node .../npm-shim.js), which adds the cmd.exe layer and a conhost.exe on top

    Workaround

    Setting mcp.codegraph.enabled to false stops the cycle immediately, at the cost of the codegraph tool.

    One more data point that may help triage: this is very likely not purely opencode-side. The watchdog exists because codegraph's main thread genuinely stops responding, and the reconnect cascade follows from that. Both halves may need fixing — the watchdog-induced death and the missing dispose on reconnect.

  5. thdxr commented on Oct 11, 2026

    @thdxr
    thdxr
    on Oct 11, 2026
    Member

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  6. thdxr
    closed this as not plannedon Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions