Description

The openclaw-gateway process leaks memory steadily over multi-day uptime, growing from ~389MB at startup to 14.7GB (58% of 24GB RAM on Mac Mini) after approximately 4 days of continuous operation.

Environment

• OpenClaw: 2026.3.13 → 2026.3.23-2 (observed on both)
• OS: macOS 15.7.4 (arm64), Mac Mini M-series, 24GB RAM
• Node: v25.6.1
• Primary model: Local GLM-4.7 via llama.cpp (openai-completions API on LAN)
• Fallback model: Anthropic Claude Opus 4.6
• Memory search: Local embeddings via node-llama-cpp (Qwen3-Embedding-4B)
• Channels: Signal (single DM peer)
• Cron jobs: 1 active (SDN submodule sync, every 6h)
• Tools profile: coding

Observed behavior

1. Gateway starts at ~389MB RSS
2. Over 4 days, RSS grows to 14.7GB without returning memory
3. Session JSONL files grow to 1.5–6.5MB each on disk
4. compaction.mode: "safeguard" with maxHistoryShare: 0.5 and 131K context window means sessions can accumulate ~65K tokens before compaction triggers
5. Context pruning (cache-ttl, TTL 6h) does not appear to reclaim in-process memory after pruning
6. After the process is killed and restarted, memory returns to ~389MB immediately

Likely contributing factors

• Session history held in memory grows proportional to JSONL on disk — 72 session files totaling 44MB were accumulated
• structuredClone in session store cache may be related (see perf: structuredClone in session store cache causes native memory leak (~1GB/min) #45438)
• seqByRun Map growth (see Memory leak: seqByRun Map in agent-events.ts grows unbounded #51819) may compound this
• Subagent sessions spawned for cron jobs and chat remain resident after completion
• The embedding model (4GB GGUF loaded via node-llama-cpp) adds constant overhead but is not the leak source — growth is proportional to session count and size

Steps to reproduce

1. Configure gateway with a local model (131K context), Signal channel, and 1+ cron jobs
2. Let it run for 3-4 days with periodic Signal messages and cron execution
3. Monitor RSS: ps aux | grep openclaw-gateway | awk '{print $6/1024 "MB"}'
4. Observe steady growth without plateau

Workaround

We implemented a daily maintenance LaunchAgent that:

• Kills the gateway at 4 AM (auto-restarts via LaunchAgent service)
• Resets any session JSONL files > 500KB
• Deletes old .reset.* files > 3 days
• Tightened compaction: maxHistoryShare: 0.3, pruning TTL 2h, keepLastAssistants: 2

This keeps memory under control but doesn't fix the underlying leak.

Expected behavior

Gateway RSS should plateau or return memory after session compaction/pruning, not grow unboundedly. Completed subagent sessions should be evicted from memory.