title: "Gateway RSS regression on 2026.4.15 — fresh cold-start baseline 700MB+ on macOS ARM64, steady climb regardless of workload"
labels: bug, regression, gateway, memory
Summary
After upgrading from 2026.4.1 to 2026.4.15, gateway RSS baseline climbed from ~400MB fresh-start to 700MB+ fresh-start, with no change in configuration, workload, or agent definitions. The leak is steady and observable regardless of subagent activity.
This appears related to #63526 (regression reported on 2026.4.9) and #13758 (long-running gateway memory accumulation), but the specific baseline jump on 2026.4.15 has not been quantified with cold-start data.
Environment
- OpenClaw: 2026.4.15 (041266a)
- Host: Mac Mini M4, macOS 26.3
- Node: v22.22.2 (via homebrew)
- Install:
/opt/homebrew/lib/node_modules/openclaw
- Service: LaunchAgent (
~/Library/LaunchAgents/ai.openclaw.gateway.plist), loopback bind
- Agents configured: 5 (main, deployer, browser, receipts, nyc311)
- Loaded plugins: 59 of 98
- Active Memory plugin: disabled (ships with 2026.4.15 but status=disabled in this config)
- Cron jobs: 14 OpenClaw + 5 system crontab
Reproducer
- Cold reboot macOS
- LaunchAgent auto-starts gateway on boot
- Measure RSS of gateway process within 2 minutes of login, before any Telegram activity, before any cron fires
Observed
Post-nightly-bounce RSS baseline: 594 MB (measured 3:45am, no workload, PID 95676)
Mid-session restart baseline: 723 MB (measured 8:00am after restart, PID 19265)
Gateway memory log excerpt from the past 24 hours (measured every 15 min via launchd, script at ~/scripts/gateway-memory-monitor.sh):
2026-04-23 03:30:00 | pid=95676 | rss=593MB
2026-04-23 03:45:00 | pid=95676 | rss=594MB
2026-04-23 04:00:00 | pid=95676 | rss=592MB
2026-04-23 05:00:00 | pid=95676 | rss=589MB
2026-04-23 05:45:00 | pid=95676 | rss=586MB
2026-04-23 06:00:00 | pid=95676 | rss=597MB
2026-04-23 06:15:00 | pid=95676 | rss=618MB
2026-04-23 07:00:00 | pid=95676 | rss=610MB
2026-04-23 08:00:00 | pid=19265 | rss=723MB ← restart, fresh baseline 723MB
2026-04-23 08:45:00 | pid=95676 | rss=651MB
2026-04-23 09:00:00 | pid=95676 | rss=650MB
2026-04-23 10:00:00 | pid=95676 | rss=642MB
2026-04-23 11:00:00 | pid=95676 | rss=646MB
2026-04-23 12:00:00 | pid=95676 | rss=650MB
2026-04-23 12:30:00 | pid=95676 | rss=673MB
2026-04-23 13:00:00 | pid=95676 | rss=714MB
2026-04-23 13:15:00 | pid=95676 | rss=734MB
2026-04-23 13:30:00 | pid=95676 | rss=745MB
2026-04-23 13:45:01 | pid=459 | rss=758MB ← reboot, fresh baseline 758MB
Yesterday's peak: 826 MB (2026-04-22 17:15, PID 56795) under normal daytime workload (digest crons + Telegram session + subagents).
Observed climb rates:
- Morning cron window (5:45am-11:00am, 8 digest crons): ~11 MB/hr
- Heavy interactive workload (12:00-13:45, multiple subagent spawns + Whisper): ~62 MB/hr
Nightly bounce (3:30am via pkill -f Chrome && launchctl kickstart -k) brought RSS from 826 MB down to 594 MB — not the ~400 MB that was baseline on 2026.4.1, suggesting the regression is in baseline allocation, not just accumulated leak.
Whisper transcription (not gateway-related, but relevant): macOS OOM killer terminated a whisper subprocess mid-transcription with ~2.4GB resident while gateway was at ~740MB and normal userland services were running. This suggests total system memory pressure from the gateway baseline is limiting headroom for legitimate coexistent workloads on this hardware (16GB Mac Mini M4).
Expected
Baseline on 2026.4.1 for this same configuration was ~400 MB fresh cold-start. Climb rate under the same morning cron load was ~14 MB/hr (per my own monitoring over the 2026.4.1 period).
Data points across versions
| Version |
Post-bounce baseline |
Restart baseline |
Climb rate (cron) |
Climb rate (heavy) |
| 2026.4.1 |
~400 MB |
~400 MB |
~14 MB/hr |
not measured |
| 2026.4.15 |
594 MB |
723 MB |
~11 MB/hr |
~62 MB/hr |
Hypothesis
Although Active Memory plugin is disabled in this configuration, the baseline jump from 400→594-723 MB suggests something else in 2026.4.15 is allocating significantly more at startup. Given that 59 of 98 plugins are loaded (vs likely fewer on 2026.4.1), plugin initialization overhead is a candidate. Given #68825 shows qmd update chains hanging at 120s on 2026.4.15, there may also be retained promise chains or uncollected async state.
Happy to disable plugins selectively and re-measure if that would be useful for bisection.
Mitigations attempted
- Nightly bounce (3:30am via
pkill -f Chrome && launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway): works but masks the underlying regression
- SOUL.md triage from 26K to 16K chars: reduced per-session context load, did not reduce baseline
- File-first exec pattern (all long commands written to temp files first): unrelated to baseline
Workaround
Currently considering rollback to 2026.4.1. Would appreciate confirmation of whether this regression is planned to be addressed, or whether 4.1 is the stable long-term line for memory-constrained hardware.
Related
title: "Gateway RSS regression on 2026.4.15 — fresh cold-start baseline 700MB+ on macOS ARM64, steady climb regardless of workload"
labels: bug, regression, gateway, memory
Summary
After upgrading from 2026.4.1 to 2026.4.15, gateway RSS baseline climbed from ~400MB fresh-start to 700MB+ fresh-start, with no change in configuration, workload, or agent definitions. The leak is steady and observable regardless of subagent activity.
This appears related to #63526 (regression reported on 2026.4.9) and #13758 (long-running gateway memory accumulation), but the specific baseline jump on 2026.4.15 has not been quantified with cold-start data.
Environment
/opt/homebrew/lib/node_modules/openclaw~/Library/LaunchAgents/ai.openclaw.gateway.plist), loopback bindReproducer
Observed
Post-nightly-bounce RSS baseline: 594 MB (measured 3:45am, no workload, PID 95676)
Mid-session restart baseline: 723 MB (measured 8:00am after restart, PID 19265)
Gateway memory log excerpt from the past 24 hours (measured every 15 min via launchd, script at
~/scripts/gateway-memory-monitor.sh):Yesterday's peak: 826 MB (2026-04-22 17:15, PID 56795) under normal daytime workload (digest crons + Telegram session + subagents).
Observed climb rates:
Nightly bounce (3:30am via
pkill -f Chrome && launchctl kickstart -k) brought RSS from 826 MB down to 594 MB — not the ~400 MB that was baseline on 2026.4.1, suggesting the regression is in baseline allocation, not just accumulated leak.Whisper transcription (not gateway-related, but relevant): macOS OOM killer terminated a whisper subprocess mid-transcription with ~2.4GB resident while gateway was at ~740MB and normal userland services were running. This suggests total system memory pressure from the gateway baseline is limiting headroom for legitimate coexistent workloads on this hardware (16GB Mac Mini M4).
Expected
Baseline on 2026.4.1 for this same configuration was ~400 MB fresh cold-start. Climb rate under the same morning cron load was ~14 MB/hr (per my own monitoring over the 2026.4.1 period).
Data points across versions
Hypothesis
Although Active Memory plugin is disabled in this configuration, the baseline jump from 400→594-723 MB suggests something else in 2026.4.15 is allocating significantly more at startup. Given that 59 of 98 plugins are loaded (vs likely fewer on 2026.4.1), plugin initialization overhead is a candidate. Given #68825 shows qmd update chains hanging at 120s on 2026.4.15, there may also be retained promise chains or uncollected async state.
Happy to disable plugins selectively and re-measure if that would be useful for bisection.
Mitigations attempted
pkill -f Chrome && launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway): works but masks the underlying regressionWorkaround
Currently considering rollback to 2026.4.1. Would appreciate confirmation of whether this regression is planned to be addressed, or whether 4.1 is the stable long-term line for memory-constrained hardware.
Related