Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Bug report draft: OpenClaw repeatedly spawns duplicate link-cli --mcp child processes and leaks memory

Summary

When mcp.servers.link-cli is enabled in openclaw.json, openclaw-gateway repeatedly accumulates duplicate node /data/.local/bin/link-cli --mcp child processes instead of reusing or reaping them. Over time this drives memory into multi-GB territory and destabilizes the container.

This appears to be an OpenClaw MCP server lifecycle issue, not a Link CLI standalone-process issue.

Environment

• OpenClaw version observed: 2026.4.21
• Runtime: Docker/containerized Hostinger setup
• Gateway behavior: in-process restart mode (OPENCLAW_NO_RESPAWN)
• Link MCP config used:

{
  "servers": {
    "link-cli": {
      "command": "/data/.local/bin/link-cli",
      "args": ["--mcp"],
      "cwd": "/data/.openclaw/workspace/clarity-agent"
    }
  }
}

Symptoms

• openclaw-gateway accumulates many child processes:
  • node /data/.local/bin/link-cli --mcp
• Child count grows over time instead of staying at 1.
• In the observed run, the pattern became approximately one new child every ~60 seconds / run boundary.
• Combined RSS reached roughly 5 GB when gateway + Link MCP children were all present.
• Example observed sizes:
  • openclaw-gateway: ~746 MB to ~1.1 GB RSS
  • each link-cli --mcp: ~121–127 MB RSS

Evidence

1. Only one MCP config entry exists

{
  "servers": {
    "link-cli": {
      "command": "/data/.local/bin/link-cli",
      "args": ["--mcp"],
      "cwd": "/data/.openclaw/workspace/clarity-agent"
    }
  }
}

2. Many duplicate child processes under a single gateway PID

Observed under one openclaw-gateway PID (109 in this run):

openclaw-gateway,109
  |-node,258 /data/.local/bin/link-cli --mcp
  |-node,425 /data/.local/bin/link-cli --mcp
  |-node,477 /data/.local/bin/link-cli --mcp
  |-node,539 /data/.local/bin/link-cli --mcp
  ... many more ...

3. Spawn cadence settled into ~60 second intervals

Sample observed deltas between link-cli --mcp process start times:

... delta_s= 60
... delta_s= 61
... delta_s= 59
... delta_s= 61
... delta_s= 60

4. Combined memory impact was severe

Observed combined RSS for gateway + link-cli --mcp children:

TOTAL_RSS_KB 5138112 TOTAL_RSS_MB 5017.69

Reproduction

1. Add mcp.servers.link-cli to openclaw.json.
2. Let OpenClaw continue normal operation with isolated cron/session activity.
3. Observe openclaw-gateway child processes over time:

pgrep -af 'node /data/.local/bin/link-cli --mcp'
ps -eo pid,ppid,lstart,etime,rss,cmd | egrep 'openclaw-gateway|node /data/.local/bin/link-cli --mcp'

1. Child count increases over time instead of remaining stable.

Important nuance

Merely editing openclaw.json did not immediately respawn children. Gateway logs showed that changes to mcp.servers.link-cli require a gateway restart/reload:

config change detected; evaluating reload (mcp.servers.link-cli)
config change requires gateway restart (mcp.servers.link-cli) — deferring until ...

The dangerous path appears to involve gateway restart/reload plus subsequent run/session activity.

Related observed logs

2026-05-01T14:07:09.261-04:00 info gateway/reload config change detected; evaluating reload (mcp.servers.link-cli)
2026-05-01T14:07:09.504-04:00 warn gateway/reload config change requires gateway restart (mcp.servers.link-cli) — deferring until 2 operation(s), 1 reply(ies), 1 embedded run(s) complete
2026-05-01T14:08:06.407-04:00 info gateway received SIGUSR1; restarting
2026-05-01T14:08:06.495-04:00 info gateway restart mode: in-process restart (OPENCLAW_NO_RESPAWN)

Containment / workaround

The following reliably stopped the leak in this environment:

1. Remove/disable the MCP server config:

{
  "mcp": {
    "servers": {}
  }
}

1. Kill lingering child processes:

pgrep -f 'node /data/.local/bin/link-cli --mcp' | xargs -r kill

1. Continue using Link via direct CLI commands only, not always-on MCP.

After disabling MCP and killing the children, the duplicate link-cli --mcp herd stopped reappearing.

Expected behavior

• At most one long-lived link-cli --mcp process should exist for a single configured MCP server, or it should be reused safely across runs.
• Gateway/session activity should not spawn unbounded duplicate MCP child processes.
• MCP child processes should be reaped correctly on restart/reload.

Actual behavior

• Gateway accumulates duplicate link-cli --mcp children over time.
• Memory usage grows substantially.
• The system becomes unstable until the MCP server is disabled and child processes are killed.

Suspected area

This looks like an OpenClaw MCP server lifecycle / process supervision bug, possibly involving:

• per-run/per-session MCP server startup
• missing reuse of an already-running local MCP process
• missing cleanup during gateway reload/restart
• interaction with isolated cron/session execution

Suggested maintainer checks

• Verify whether local MCP servers are instantiated per session/run rather than per gateway/runtime.
• Verify process reuse logic for configured local MCP servers.
• Verify cleanup/reaping logic during in-process gateway restart.
• Check whether isolated cron runs or embedded runs trigger fresh MCP server spawns.

Practical impact

This makes always-on Link MCP unsafe in production for this environment. CLI fallback works as a workaround, but the intended MCP integration path appears to leak badly.

Steps to reproduce

In openclaw.json, configure exactly one local MCP server entry for Link:

{
  "mcp": {
    "servers": {
      "link-cli": {
        "command": "/.local/bin/link-cli",
        "args": ["--mcp"],
        "cwd": "/.openclaw/workspace/some-agent"
      }
    }
  }
}

1. Apply the config and force the gateway to reload/restart. In this environment, the gateway logged:

config change detected; evaluating reload (mcp.servers.link-cli)
config change requires gateway restart (mcp.servers.link-cli)

1. Allow normal OpenClaw activity to continue (observed with isolated cron/session activity present).

2. Watch for duplicate MCP child processes:

pgrep -af 'node /data/.local/bin/link-cli --mcp'
ps -eo pid,ppid,lstart,etime,rss,cmd | egrep 'openclaw-gateway|node /data/.local/bin/link-cli --mcp'

1. Observed result: multiple duplicate node /data/.local/bin/link-cli --mcp processes accumulate under a single openclaw-gateway PID instead of staying at 1.

Expected behavior

With a single configured local MCP server entry, OpenClaw should keep at most one reusable link-cli --mcp process for that server, or otherwise cleanly reap/reuse it across runs and gateway restarts. This expectation is grounded by the configuration containing exactly one mcp.servers.link-cli entry and by Link CLI’s MCP mode being intended as a server, not an ever-growing pool of duplicate children.

Actual behavior

Observed result:

openclaw-gateway accumulated many duplicate child processes:
    node /data/.local/bin/link-cli --mcp
The child count grew over time instead of staying at 1.
In the observed run, spawn cadence settled to roughly one new child every ~60 seconds / run boundary.
Combined RSS for gateway + Link MCP children reached about 5.0 GB:
    TOTAL_RSS_KB 5138112
    TOTAL_RSS_MB 5017.69
Example per-process memory observed:
    openclaw-gateway: ~746 MB to ~1.1 GB RSS
    each link-cli --mcp: ~121–127 MB RSS
Disabling the MCP entry and killing the children stopped the duplicate process accumulation.

OpenClaw version

2026.4.21

Operating system

Linux 6.8.0-110-generic

Install method

npmd

Model

Docker/containerized deployment with a Hostinger wrapper (/entrypoint.sh → node server.mjs)

Provider / routing chain

webchat / WhatsApp → local openclaw-gateway → configured OpenClaw model routing (primary openai-codex/gpt-5.4, fallbacks configured)

Additional provider/model setup details

This issue appears independent of model output and was observed as a gateway/MCP process lifecycle problem. Relevant environment/context details:

Gateway restart mode logged as: in-process restart (OPENCLAW_NO_RESPAWN)
mcp.servers.link-cli was configured as a local MCP server using /data/.local/bin/link-cli --mcp
The environment had isolated cron/session activity active during reproduction
The issue stopped when mcp.servers was emptied and lingering link-cli --mcp children were killed
No API keys or provider secrets are required to explain the repro path

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response