Summary

hermes dashboard spawns tui_gateway.slash_worker subprocesses per chat turn (including turns routed in from gateway platforms like Telegram), but does not reap them after the response is delivered. Workers accumulate as idle processes holding session state.

Repro

1. Run hermes dashboard with the gateway attached to a chat platform (e.g. Telegram).
2. Send N messages through the platform. Do not open a TUI session.
3. pgrep -af tui_gateway.slash_worker → N processes, one per turn, parented to the hermes dashboard PID, all idle.

Expected

Worker exits (or returns to a bounded pool with idle eviction) after delivering its turn's response.

Actual

Worker stays resident indefinitely. Each idle worker holds ~5MB RSS + ~80MB swap of cold session state. Linear growth with chat volume.

Suspected cause

slash_worker likely awaits a follow-up message on its IPC channel that only the TUI sends. When the dashboard chat path invokes it for a one-shot turn, nothing ever closes the channel, so the worker blocks forever.

Workaround

pkill -f tui_gateway.slash_worker — safe, next turn spawns fresh.

Related

• Memory leak: Gateway accumulates ~8GB RAM in 1h with 2 active Discord sessions #18438 (gateway RAM leak, Discord)
• Bug: persistent event loops in model_tools.py never closed, resource accumulation in long-running gateway #8043 (persistent event loops in model_tools.py)
• Bug: TUI session eagerly spawns duplicate 'hermes mcp serve' children from both tui_gateway.entry and slash_worker #15275 (slash_worker spawning duplicate mcp serve)