Bug Report: Gateway Memory Bloat on macOS
Environment
- OpenClaw version: 2026.4.20 (upgraded from 2026.4.15)
- macOS: Darwin 24.6.0 (macOS 26 on MacBook Air)
- RAM: 8GB MacBook Air
- Node: v22.22.0
Problem
The openclaw-gateway process RSS grows to 900MB+ within minutes of a fresh restart, regardless of session count or dreaming state.
Timeline of Testing (2026-04-21)
| State |
RSS |
CPU |
| 136 sessions, dreaming ON |
1,128 MB |
170% |
| Pruned to 3 sessions, dreaming ON |
573 MB → 901 MB |
climbing |
| 3 sessions, dreaming OFF |
526 MB (cold) → 908 MB (2 min later) |
52% |
| Just this Discord session (5.7MB jsonl) |
still 900MB+ |
still high |
What We Tried
- Aggressive session prune — reduced from 136 to 3 sessions, archived 129 jsonl files. Helped briefly (526MB cold) but climbed right back to 900MB.
- Disabled memory-core dreaming — no sustained improvement. Gateway still bloats to 900MB within minutes.
- Moved archive outside sessions dir — ensured no stale file scanning.
- openclaw doctor — killed by macOS OOM before it could complete (3 attempts).
- Multiple gateway restarts — same pattern each time: cold start ~500MB, climbs to 900MB+ within minutes.
2026.4.20 Fixes That Should Have Helped
Sessions/Maintenance: enforce the built-in entry cap and age prune by default, and prune oversized stores at load time so accumulated cron/executor session backlogs cannot OOM the gateway before the write path runs. (#69404)Memory-core/dreaming: normalize sweep timestamps and reuse hashed narrative session keys for fallback cleanup so Dreaming narrative sub-sessions stop leaking. (#67023)
Despite these fixes, the gateway still bloats rapidly.
Active Plugins
- memory-core (dreaming disabled during test)
- memory-wiki (enabled, 7 syntheses, minimal data)
- discord, telegram, voice-call
- zai, google, stepfun, openai, kimi (disabled)
Impact
On an 8GB MacBook Air, 900MB+ RSS causes:
- macOS killing child processes (openclaw doctor killed 3 times)
- Gateway becomes unresponsive / control UI goes down
- Memory watchdog triggers restarts, creating instability cycle
Expected Behavior
Gateway RSS should stabilize well under 750MB on a machine with only 3 active sessions and dreaming disabled.
Reproduction
- Fresh install of OpenClaw 2026.4.20 on macOS MacBook Air (8GB)
- Start gateway
- Observe RSS climb from ~500MB to 900MB+ within 2-5 minutes
- Continue using normally — RSS does not stabilize
Bug Report: Gateway Memory Bloat on macOS
Environment
Problem
The openclaw-gateway process RSS grows to 900MB+ within minutes of a fresh restart, regardless of session count or dreaming state.
Timeline of Testing (2026-04-21)
What We Tried
2026.4.20 Fixes That Should Have Helped
Sessions/Maintenance: enforce the built-in entry cap and age prune by default, and prune oversized stores at load time so accumulated cron/executor session backlogs cannot OOM the gateway before the write path runs. (#69404)Memory-core/dreaming: normalize sweep timestamps and reuse hashed narrative session keys for fallback cleanup so Dreaming narrative sub-sessions stop leaking. (#67023)Despite these fixes, the gateway still bloats rapidly.
Active Plugins
Impact
On an 8GB MacBook Air, 900MB+ RSS causes:
Expected Behavior
Gateway RSS should stabilize well under 750MB on a machine with only 3 active sessions and dreaming disabled.
Reproduction