solution gateway critical macos linux windows

OpenClaw OOM crash loop: gateway or openclaw-message hits JavaScript heap out of memory (Node v24)

Fix OpenClaw gateway or openclaw-message OOM crash loops caused by Node.js v24 by pinning the runtime to Node v22 (LTS) and verifying your service actually uses the expected Node binary.

By CoClaw Team

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

In multiple recent reports, the trigger is Node.js v24.x (for example v24.13.0).

The same OpenClaw versions become stable again when the runtime is pinned to Node.js v22.x (LTS).

Fix

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

node -v

Switch to Node 22 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"

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

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

  • your interactive shell uses Node 22,
  • but launchd/systemd/Docker is still running Node 24.

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.

3) If you cannot change Node on that host: roll back OpenClaw temporarily

This does not fix the underlying Node runtime trigger, but it can be a short-term stability move while you migrate Node:

npm uninstall -g openclaw
npm install -g openclaw@2026.3.2
openclaw --version

Verify

  • node -v reports Node 22.x.
  • 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.

Verification & references

  • Reviewed by:CoClaw Code Team
  • Last reviewed:March 14, 2026
  • Verified on: macOS · Linux · Windows
Want to explore more? Browse all solutions or ask in the Community Forum .
Report a problem

Related Resources

Node.js version mismatch (OpenClaw requires Node 22+)
Fix
Fix install/runtime failures caused by old Node.js versions by upgrading to Node 22 LTS and ensuring your shell/service uses the same Node.
Gateway fails to start: EADDRINUSE / another gateway instance is already listening
Fix
Fix OpenClaw gateway port conflicts (EADDRINUSE) by stopping the other process or choosing a new gateway port/profile.
Linux/systemd: OpenClaw leaves orphan gateway processes or port 18789 conflicts
Fix
Fix Linux hosts where CLI-triggered gateway respawn collides with a systemd-managed OpenClaw gateway, causing orphan processes, EADDRINUSE, or 'another gateway instance is already listening'.
Windows native: node run hangs after printing PATH, or the runtime stays unstable
Fix
Stabilize native Windows setups where `openclaw node run` hangs after PATH output, the runtime behaves differently from your shell, or your real requirement is better served by WSL2.
OpenClaw Remote Browser Setup: Gateway on One Machine, Browser on Another
Guide
Choose a stable remote-browser topology for OpenClaw, pin the right browser-capable node, and verify that gateway routing, relay startup, and browser takeover all land on the machine you intended.
OpenClaw on Native Windows: PATH, Scheduled Tasks, Node Host, and the Real Failure Modes
Guide
A field guide to running OpenClaw on native Windows without guesswork: separate shell, Scheduled Task, and node-host environments; fix PATH-driven failures cleanly; and know when WSL2 is the faster exit.