Skip to content

MCP servers spawn 2-4 duplicate processes per server on startup, causing TasksMax exhaustion and EAGAIN errors #31554

Open
Open
MCP servers spawn 2-4 duplicate processes per server on startup, causing TasksMax exhaustion and EAGAIN errors#31554
Assignees
nexxeln

Description

@cgartlab
cgartlab
opened on Jun 9, 2026

Bug Description

On Linux (Ubuntu), opencode-web spawns 2–4 duplicate processes per MCP server on startup instead of one. With 10 MCP servers configured, this produces 36 processes instead of ~10–20. The duplicate processes are not cleaned up on restart — they accumulate.

This causes EAGAIN: resource temporarily unavailable, posix_spawn errors when the system approaches the TasksMax limit, making MCP servers appear as "failed" in opencode mcp list.

Environment

  • OS: Linux (Ubuntu, systemd)
  • opencode version: latest (headless server mode via opencode web)
  • MCP servers configured: 10 local stdio-type servers (github, memory, time, sequential-thinking, fetch, context7, ast_grep, grep_app, websearch, searxng)
  • Systemd config: TasksMax=200 (raised to 500 during debugging)
  • Initial state: TasksCurrent ≈ 190/200 → spawns fail with EAGAIN

Evidence

Process duplication

After a single opencode-web restart, ps aux shows each MCP server has 2–4 instances running simultaneously:

github:       2x sh + node (via npx)
memory:       2x sh + node (via npx)
time:         2x uv tool uvx + 2x uv cache python
sequential:  2x npm exec + 2x sh + node
fetch:        2x uv tool uvx + 2x uv cache python
context7:     2x npm exec + 2x sh + node
websearch:    2x npm exec + 2x sh + node
searxng:      2x python3 direct
Total:        36 processes for 10 MCP servers

EAGAIN errors

When TasksCurrent approaches TasksMax (190/200), all MCP servers report:

EAGAIN: resource temporarily unavailable, posix_spawn
MCP error -32000: Connection closed

The processes exist but opencode cannot communicate with them.

Memory impact

  • Duplicate processes consume ~660MB extra memory beyond the expected ~17 processes
  • System had 1.3GB+ headroom but spawns still failed due to TasksMax limit

Root Cause (Preliminary)

The duplication appears to be triggered by opencode's startup sequence spawning MCP servers via multiple mechanisms simultaneously:

  1. npm exec (npx wrapper)
  2. sh -c "command" + node binary
  3. uv tool uvx (for Python servers)
  4. python3 direct invocation

All mechanisms succeed, leaving multiple process trees running in parallel.

Related Issues

Expected Behavior

  1. Each MCP server should spawn exactly one process tree (not multiple parallel trees)
  2. Duplicate processes from a previous restart should be cleaned up before starting fresh
  3. When system resources are constrained, opencode should handle this gracefully instead of spawning in a way that guarantees EAGAIN

Workaround

Raising TasksMax from 200 → 500 in systemd mitigates the EAGAIN trigger, but does not fix the duplication.

Impact

  • Wastes ~660MB RAM per restart
  • Triggers EAGAIN errors under normal load (TasksMax 200 → 190 used before any MCP spawns)
  • Makes MCP servers appear failed even though processes are running and functional via direct stdio
  • Accumulated duplicates across restarts could eventually exhaust memory

Activity

  1. github-actions
    assigned
    nexxeln
    on Jun 9, 2026

  2. github-actions commented on Jun 9, 2026

    @github-actions
    github-actionsBot
    on Jun 9, 2026 – with GitHub Actions
    Contributor

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

  3. Ruslanastro commented on Aug 8, 2026

    @Ruslanastro
    Ruslanastro
    on Aug 8, 2026

    Same bug reproduced on the Windows desktop app (Electron, @opencode-aidesktop, v1.18.15), 2/2 restarts.

    Evidence after a fresh app restart (all timestamps same boot, every local stdio MCP server spawned twice ~5s apart, both copies children of the same app utility process):

    OpenCode.exe (main 20748) 0:06:42
 └─ utility node 6588
     ├─ github-mcp-server 25496  0:06:48   (WAVE 1)
     ├─ github-mcp-server 21820  0:06:53   (WAVE 2)
     ├─ npx @playwright/mcp@0.0.79 → cli.js ×2
     ├─ npx server-filesystem      → index.js ×2
     ├─ npx server-sequential-thinking → dist/index.js ×2
     └─ uvx mcp-pandoc ×2 (22620, 23732)
    • Impact: ~200–300 MB extra memory; stateful stdio servers (memory stores writing JSONL/SQLite) get two live writers → race/corruption risk.
    • Confirmed it is not config-related: no mcp.*.enabled toggle or command shape affects it.
    • Prior desktop session on 1.18.10 showed the identical two-wave pattern.

    Original report (now closed as duplicate): #41331.

  4. liudongyan13701205717-source commented on Aug 21, 2026

    @liudongyan13701205717-source
    liudongyan13701205717-source
    on Aug 21, 2026

    +1; this likely contributes to the "MCP fails to load on startup" reports on Desktop (#40516) and the stale-state issue (#35285). Duplicate spawns competing for CPU at startup would also explain intermittent startup timeouts. Tracking together.

  5. neriousy
    marked Local MCP server spawned twice (duplicate process) on every Desktop restart #42190 as a duplicate of this issue on Oct 1, 2026

  6. sajjad-rabby commented on Oct 14, 2026

    @sajjad-rabby
    sajjad-rabby
    on Oct 14, 2026

    Related Windows reproduction: duplicate MCP process starts under OpenWork 0.18.58.0 / OpenCode engine 1.18.30

    I'm reporting a related symptom to the Linux reproduction in this issue and the existing Windows Desktop report.

    Environment: Windows, OpenWork 0.18.58.0, bundled OpenCode engine 1.18.30. The running engine version was identified using the bundled version manifest and a SHA-256 match against the running binary. The binary's PE FileVersion field disagrees with that version and was not used as the version authority.

    Observed process creation: In one captured engine lifetime, the primary engine started at 08:53:03 UTC. Eighteen direct engine children appeared in four process-start clusters:

    • 08:53:15 UTC — 5 children
    • 08:53:16 UTC — 3 children
    • 08:53:20 UTC — 4 children
    • 08:53:27 UTC — 6 children

    Process ancestry associated the resulting server process trees with the same live engine; no engine restart occurred during this observation. Six local-server families ended up with four apparently identical instances each, while four other observed families had one instance each. The Firebase server was configured but absent from the captured process population.

    These are observed process-start clusters, not confirmed MCP initialization cycles. The underlying trigger remains unknown.

    Memory measurements: From the same idle snapshot, the engine-managed local MCP process population, including local mcp-remote bridges, measured approximately:

    • Private working set: 303 MB
    • Total working set: 1.50 GB
    • Private committed memory: 4.62 GB

    These are different memory metrics and should not be interpreted interchangeably. The committed footprint is substantially larger than resident-private memory; system-wide commit-limit pressure was not established. Savings from reducing instances have not been tested.

    Two older same-name AgentMemory processes were excluded after investigation showed that they belong to a separately managed standalone daemon, rather than the current engine's MCP process population.

    Root cause remains unconfirmed. The captured configuration defines one agent and the runtime state identifies one primary engine. The observation does not establish that project, session, or agent lifecycle behavior is responsible, nor does it prove that Windows process-tree cleanup is causing the repeated starts. The current INFO-level engine logs did not reveal the trigger.

    This appears related at the symptom level to #26336 and #29939, but the trigger in this environment remains undetermined.

    This differs from the 1.18.15 desktop report above (two waves, stock Desktop app): ours is four clusters under the OpenWork host on engine 1.18.30.

    I can provide appropriately redacted process ancestry, server counts, and configuration structure if needed. No credentials, private state, or diagnostic file uploads are included.

  7. Running-Lag commented on Oct 15, 2026

    @Running-Lag
    Running-Lag
    on Oct 15, 2026

    I am having the same issue.
    The MCP server I am using (https://github.com/browsermcp/mcp) is unable to handle multiple instances of it running at the same time.
    This causes the second one to kill the first one and results in errors:
    Image

  8. VariableVince commented on Oct 23, 2026

    @VariableVince
    VariableVince
    on Oct 23, 2026

    Could be fixed now by the PR that closed #52741

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