Bridge process leak: every turn spawns new bridge.cjs, 4+ processes accumulated

[haojiajieyangde03-ctrl]

Bridge process leak: every turn spawns new bridge.cts, 4+ processes accumulated

Environment

• @memtensor/memos-local-plugin v2.0 (Hermes adapter)
• Hermes Agent v0.16.0, macOS 26.5.1
• Config: skillInjectionMode=full, embedding=local, LLM=deepseek-chat

Problem

Every conversation turn spawns a new bridge.cjs --agent=hermes --no-viewer process. Old processes are not cleaned up. Over a session, 4+ bridge processes accumulate:

$ ps aux | grep bridge.cjs
cctv  509  0.0%  ~70MB  bridge.cjs --agent=hermes --daemon
cctv  2018 0.0%  ~92MB  bridge.cjs --agent=hermes --no-viewer
cctv  2058 0.0%  ~99MB  bridge.cjs --agent=hermes --no-viewer
cctv  6550 0.0%  ~343MB bridge.cjs --agent=hermes --no-viewer  ← 343MB!

The newest process has grown to 343MB RSS. Over longer sessions with many turns, this would lead to significant memory pressure (especially on 16GB macOS devices already constrained by 26.5.1 resource limits).

Expected behavior

Bridge should be initialized once per session, with subsequent turns reusing the existing connection. Or at minimum, old bridge processes should be cleaned up when a new one spawns.

Note

This may be related to NousResearch/hermes-agent#20939 which reports the same symptom from the Hermes side: "MemOS memory provider spawns new bridge.cts process on every single turn."

Impact

• Memory leak: each process consumes 70-340MB RSS
• On long-running sessions (50+ turns), this could consume 3-10GB of RAM
• macOS 26.5.1 already imposes disk write limits; memory pressure from leaked processes compounds this

[fancyboi999]

I've reproduced this locally and traced the root cause — claiming this one, fix PR incoming.

TL;DR: accumulation of live --no-viewer bridges = multiple live MemosBridgeClient instances in the Hermes host process. Two compounding sides:

1. Host side (hermes-agent): before fix(run_agent): isolate background review fork from external memory plugins NousResearch/hermes-agent#27190, background review / delegate forks rebuilt the memory provider per fork (load_memory_provider() constructs a fresh MemTensorProvider on every call — module is cached, instance is not), and the abandoned fork never calls shutdown(). oneshot.py still lacks skip_memory=True today.
2. Adapter side (this repo): the bridge subprocess is owned per provider instance with nothing enforcing the one-bridge-per-process invariant, and three reference legs make abandoned instances immortal: (a) bound-method hooks appended to the host's global plugin manager and never removed, (b) a per-instance keepalive thread that never stops — and even resurrects the bridge if you kill -9 it (verified: killed pid, new bridge respawned within one 5s cycle), (c) reader thread ↔ Popen stdin pipe pinning each other so GC can never trigger stdin-EOF exit. Also initialize() doesn't close an existing self._bridge, so re-init leaks too.

Deterministic repro (real unmodified adapter, stub bridge with identical lifecycle semantics): 3 abandoned provider instances → exactly 4 live --no-viewer processes, matching the ps output in this report.

Fix direction (defense on the adapter side, independent of host behavior): promote the bridge client to a process-wide shared resource (refcounted module-level singleton — the JSON-RPC protocol is already multi-session), single keepalive bound to the shared client, hook registration deduped at process level and unregistered on shutdown, idempotent initialize().

[Memtensor-AI]

🤖 AutoDev has picked up this issue and started working on it.

Task ID: dba10126f96caab2
Working branch: bugfix/autodev-1910
Target branch: latest dev* branch
Workflow: opsp (analysis → coding → testing → PR)

I will post the PR link here once done. If I need more information, I will ask in the comments.