OpenClaw OOM crash loop after a Node/runtime mismatch

Symptoms

One of these patterns:

• The gateway enters a crash loop (LaunchAgent/systemd/pm2 keeps restarting it), and you see memory climb rapidly.
• openclaw message send ... (or openclaw-message) fails with an OOM stack trace on smaller servers.

Common crash signatures:

• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Cause

Older 2026.3-era reports pointed at Node.js v24.x as the trigger. Current stable OpenClaw 2026.6.1 now recommends Node.js 24 and supports Node.js 22.19+, so do not treat Node 24 itself as the current known-bad runtime.

The more likely current cause is a mismatch between your installed OpenClaw package, your service process, and the Node binary that service actually starts with.

Fix

1) Update to the stable OpenClaw release first

Use OpenClaw’s updater for normal updates:

openclaw update
openclaw --version

As of June 2026, npm latest is stable OpenClaw 2026.6.1. Beta/main can show newer 2026.6.x versions; only use them intentionally.

2) Align the runtime to Node.js 24 or Node.js 22.19+

On the machine that actually runs the gateway (or the CLI command):

node -v

Switch to Node 24 where available, or at least Node 22.19, using your preferred manager (nvm/fnm/asdf/apt/homebrew), then confirm:

node -v

Restart and re-test:

openclaw gateway restart

# If your symptom is CLI-only, re-run the exact command that was OOM'ing:
openclaw message send --channel <channel> --target <target> --message "test"

3) Make sure your service uses the same Node you tested

This is the most common “it still OOMs” trap:

• your interactive shell uses Node 24 or Node 22.19+,
• but launchd/systemd/Docker is still running a different Node.

Verify the gateway’s Node version in the service context (the exact method depends on how you run the gateway).

If you are unsure, the pragmatic check is: restart the service and inspect the process environment/path and the resolved Node binary.

4) If you are stuck on an older build: pin temporarily

This does not fix the underlying runtime mismatch, but it can be a short-term stability move while you migrate. Prefer the updater path over an npm overwrite:

openclaw update --tag <last-working-version>
openclaw --version

Verify

• openclaw --version reports the stable version you intended (2026.6.1 unless you deliberately pinned).
• node -v reports Node 24.x or Node 22.19+.
• The gateway stays up for at least 10 minutes without entering an OOM restart loop.
• openclaw gateway status / openclaw health works reliably.
• If you were hitting the CLI symptom: the previously failing openclaw message send ... command completes.

Related

• /guides/openclaw-installation-troubleshooting
• /guides/openclaw-backup-and-rollback