disconnected (1006): no reason | Friends of the Crustacean 🦞🤝 | Page 1

frozen maple Feb 17, 2026, 11:45 AM

#

gateway disconnected every time I type something to openclaw

rancid cobaltBOT Feb 17, 2026, 11:48 AM

#

That disconnected (1006): no reason is the Dashboard/Control UI’s WebSocket dropping. Most commonly it’s either (a) the Gateway process crashing/restarting when it tries to handle your message, or (b) you’re connected to the wrong URL/token/tunnel and the WS gets severed.

Can you run these on the gateway host and paste the output?

Version + runtime

openclaw --version
node -v

Is the Gateway actually staying up?

openclaw gateway status
openclaw status --all

(--all is meant to be shareable; it redacts tokens.)

#

Capture the error at the moment it disconnects

openclaw logs --follow

Leave this running, reproduce the disconnect by sending a message, then copy/paste the log lines around the disconnect/error/stack trace.

Also: if you’re accessing the UI remotely (SSH tunnel / Tailscale / reverse proxy), paste how you’re opening it. A quick sanity check is:

openclaw dashboard

and open the printed URL (correct host/port + auth).

Docs reference (same symptom): https://docs.openclaw.ai/help/faq#disconnected-from-gateway-no-reason-what-now

frozen maple Feb 17, 2026, 11:57 AM

#

Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-17.log
Command: /usr/local/bin/node /usr/local/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 35569)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /Users/Hal/.openclaw/openclaw.json

Port 18789 is already in use.

pid 35569 Hal: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

rancid cobaltBOT Feb 17, 2026, 11:58 AM

#

Your gateway status output explains the disconnect:

Runtime: running but RPC probe: failed (timeout) → the Gateway process is listening on 127.0.0.1:18789, but it’s not answering WebSocket RPC requests. When the UI tries to send a message, the WS drops → 1006.

Let’s narrow down whether it’s just wedged vs crashing on message handling.

1) Confirm versions (important on macOS)

Run on the gateway host and paste:

openclaw --version
node -v

2) Do a clean daemon restart (to clear a wedged event loop)

openclaw gateway stop

#

openclaw gateway start
openclaw gateway status

You want RPC probe: ok. If it still times out, jump to logs.

3) Grab the log around the disconnect/crash

In one terminal:

openclaw logs --follow

Then reproduce (type something in the UI), and paste the first obvious error/stack trace that appears.

If openclaw logs doesn’t show anything useful, paste:

tail -n 200 /tmp/openclaw/openclaw-2026-02-17.log

#

One quick sanity check: are you opening the dashboard on the same machine as the gateway at http://127.0.0.1:18789/? (With bind=loopback, remote devices can’t connect without an SSH tunnel/Tailscale setup.)

Docs for this exact symptom: https://docs.openclaw.ai/help/faq#disconnected-from-gateway-no-reason-what-now

frozen maple Feb 17, 2026, 12:17 PM

#

version 2026.2.15
node 25.5.0

🦞 OpenClaw 2026.2.15 (3fe22ea) — OpenAI-compatible, not OpenAI-dependent.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-17.log
Command: /usr/local/bin/node /usr/local/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 36445)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /Users/Hal/.openclaw/openclaw.json

Gateway port 18789 is not listening (service appears running).
Last gateway error: 27: 0x12e9a8b59
Logs: ~/.openclaw/logs/gateway.log
Errors: ~/.openclaw/logs/gateway.err.log

rancid cobaltBOT Feb 17, 2026, 12:18 PM

#

That’s a crash / hard-close signature, not a normal auth/“wrong token” thing:

RPC probe: failed … gateway closed (1006 abnormal closure)
plus: “Gateway port 18789 is not listening (service appears running)”
→ the LaunchAgent is loaded, but the gateway process is dying / wedging so the socket disappears.

Two things to do next (these will tell us the exact cause):

1) Paste the last ~100 lines of the gateway error log

On the Mac running the gateway:

tail -n 120 ~/.openclaw/logs/gateway.err.log
tail -n 120 ~/.openclaw/logs/gateway.log

2) Run the gateway in the foreground (so we can see the crash live)

#

openclaw gateway stop
openclaw gateway --port 18789 --verbose --ws-log compact

Then open http://127.0.0.1:18789/, type a message, and paste whatever the terminal prints when it disconnects.

Also worth calling out: you’re on Node 25.5.0 (very bleeding-edge). OpenClaw only requires “Node 22+”, but in practice Node 22/24 LTS tends to be much more stable for long-running daemons on macOS. Let’s see the gateway.err.log first—if it smells like a Node/runtime crash, I’ll suggest the cleanest downgrade path.

frozen maple Feb 17, 2026, 12:27 PM

#

Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-17.log
Command: /usr/local/bin/node /usr/local/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 36445)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /Users/Hal/.openclaw/openclaw.json

Gateway port 18789 is not listening (service appears running).
Last gateway error: 27: 0x12e9a8b59
Logs: ~/.openclaw/logs/gateway.log
Errors: ~/.openclaw/logs/gateway.err.log

#

Paste the last ~100 lines of the gateway error log
On the Mac running the gateway:
tail -n 120 ~/.openclaw/logs/gateway.err.log
tail -n 120 ~/.openclaw/logs/gateway.log
Run the gateway in the foreground (so we can see the crash live)
openclaw gateway stop
openclaw gateway --port 18789 --verbose --ws-log compact

Then open http://127.0.0.1:18789/, type a message, and paste whatever the terminal prints when it disconnects.

#

23:24:06 Registered plugin command: /pair (plugin: device-pair)
23:24:06 Registered plugin command: /phone (plugin: phone-control)
23:24:06 Registered plugin command: /voice (plugin: talk-voice)
12:24:06 [canvas] host mounted at http://127.0.0.1:18789/openclaw/canvas/ (root /Users/Hal/.openclaw/canvas)
23:24:06 bonjour: starting (hostname=openclaw, instance="Sean’s MacBook Air (OpenClaw)", gatewayPort=18789, minimal=true)
12:24:12 [heartbeat] started
12:24:12 [gateway] agent model: kimi-coding/k2p5
12:24:12 [gateway] listening on ws://127.0.0.1:18789 (PID 36721)
12:24:12 [gateway] listening on ws://[::1]:18789
12:24:12 [gateway] log file: /tmp/openclaw/openclaw-2026-02-17.log
12:24:12 [browser/service] Browser control service ready (profiles=2)
12:24:16 [ws] ← open remoteAddr=127.0.0.1 conn=d2e798c6…f009
12:24:24 [ws] ← connect client=openclaw-control-ui version=dev mode=webchat clientId=openclaw-control-ui platform=MacIntel auth=device-token
12:24:24 [ws] webchat connected conn=d2e798c6-1a93-46d8-b4da-d39cb8ecf009 remote=127.0.0.1 client=openclaw-control-ui webchat vdev
12:24:24 [ws] → hello-ok methods=88 events=18 presence=2 stateVersion=2
12:24:24 [ws] ⇄ res ✓ agent.identity.get 5ms id=718ccce3…eae8
12:24:24 [ws] ⇄ res ✓ agents.list 2ms id=43d8710b…a3dc

<--- Last few GCs --->

#

[36721:0x7fca9f00a000] 23111 ms: Scavenge 2005.5 (2056.7) -> 2004.4 (2064.0) MB, pooled: 0.0 MB, 7.30 / 0.00 ms (average mu = 0.857, current mu = 0.731) allocation failure;
[36721:0x7fca9f00a000] 23387 ms: Mark-Compact (reduce) 2033.5 (2080.0) -> 2028.9 (2064.0) MB, pooled: 0.0 MB, 96.78 / 0.00 ms (+ 65.7 ms in 234 steps since start of marking, biggest step 5.1 ms, walltime since start of marking 276 ms) (average mu = 0.7
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

1: 0x11037b393 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
2: 0x10f399e47 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
3: 0x10f399e08 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
4: 0x10f56b531 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
5: 0x10f56ab18 v8::internal::Heap::EagerlyFreeExternalMemoryAndWasmCode() [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
6: 0x10f569aa3 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags, v8::internal::PerformHeapLimitCheck) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]

#

7: 0x10f5612be std::__1::__invoke_result_impl<void, v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment, v8::internal::AllocationHint)::$_0&>::type v8::internal::HeapAllocator::CollectGarbageAndRetryAllocation<v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment, v8::internal::AllocationHint)::$_0&>(v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment, v8::internal::AllocationHint)::$_0&, v8::internal::AllocationType) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
8: 0x10f55f1d6 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment, v8::internal::AllocationHint) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]

winged ivy Feb 17, 2026, 12:27 PM

#

frozen maple [36721:0x7fca9f00a000] 23111 ms: Scavenge 2005.5 (2056.7) -> 2004.4 (2064.0) ...

💬 Oh no, it sounds like you're running into some memory issues with Node.js! Have you tried increasing the heap size or optimizing your code to use less memory? Maybe we can figure out a solution together.

frozen maple Feb 17, 2026, 12:27 PM

#

9: 0x10f536922 v8::internal::MaybeHandlev8::internal::SeqTwoByteString v8::internal::FactoryBasev8::internal::Factory::NewRawStringWithMapv8::internal::SeqTwoByteString(int, v8::internal::Taggedv8::internal::Map, v8::internal::AllocationType, v8::internal::AllocationHint) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
10: 0x10f66ccd8 v8::internal::JsonParser<unsigned short>::MakeString(v8::internal::JsonString const&, v8::internal::Handlev8::internal::String) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
11: 0x10f66f878 v8::internal::JsonParser<unsigned short>::ParseJsonObject(v8::internal::Handlev8::internal::Map) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
12: 0x10f66f84c v8::internal::JsonParser<unsigned short>::ParseJsonObject(v8::internal::Handlev8::internal::Map) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
13: 0x10f66f84c v8::internal::JsonParser<unsigned short>::ParseJsonObject(v8::internal::Handlev8::internal::Map) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
14: 0x10f66c9b1 v8::internal::JsonParser<unsigned short>::ParseJson(v8::internal::DirectHandlev8::internal::Object) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
15: 0x10f66c809 v8::internal::JsonParser<unsigned short>::Parse(v8::internal::Isolate*, v8::internal::Handlev8::internal::String, v8::internal::Handlev8::internal::Object, std::__1::optionalv8::internal::ScriptDetails) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
16: 0x10f3fcf5f v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*) [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
17: 0x10ed1c9b6 Builtins_CEntry_Return1_ArgvOnStack_BuiltinExit [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]
18: 0x12cdea097
19: 0x10ec6fc93 Builtins_InterpreterEntryTrampoline [/usr/local/Cellar/node/25.5.0/lib/libnode.141.dylib]

winged ivy Feb 17, 2026, 12:27 PM

#

frozen maple 9: 0x10f536922 v8::internal::MaybeHandle<v8::internal::SeqTwoByteString> v8::int...

👋 Hey unreadyplayer! What's up?

frozen maple Feb 17, 2026, 12:28 PM

#

@rancid cobalt

rancid cobaltBOT Feb 17, 2026, 12:29 PM

#

Yep — that output is still saying the same thing: launchd thinks the gateway is “running”, but the WebSocket closes (1006) and the port stops listening. At this point we need the actual crash/error from the gateway logs.

Please paste these (they’re the ones openclaw status is explicitly pointing at):

tail -n 200 ~/.openclaw/logs/gateway.err.log
tail -n 200 ~/.openclaw/logs/gateway.log

If gateway.err.log is empty or unhelpful, do this to catch the failure live:

openclaw gateway stop
openclaw gateway --port 18789 --verbose --ws-log compact

Then open http://127.0.0.1:18789/, type one message, and paste the terminal output right when it disconnects.

#

One extra data point that often matters here: you’re on Node 25.5.0 (non‑LTS). If the logs show a Node/runtime crash, the quickest “make it stop flaking” fix is usually switching the gateway to Node 22 or 24 LTS — but let’s confirm from gateway.err.log first.

#

That stack trace is V8/Node blowing up during allocation — i.e. the gateway is crashing with an out-of-memory / heap allocation failure, which is why the UI gets a 1006 (socket just dies, no close frame).

Two concrete next steps:

1) Confirm it’s the classic “heap out of memory” line

Please paste the start of the crash from gateway.err.log (it’s usually a few lines above the stack frames):

tail -n 80 ~/.openclaw/logs/gateway.err.log

2) Fix: don’t run the gateway on Node 25 (use Node 24 or 22 LTS)

You’re on node 25.5.0 (non‑LTS). On macOS daemons, that’s a common source of weird V8 crashes.

If you installed Node via Homebrew (your paths look like it), do:

brew install node@24

#

brew unlink node
brew link --overwrite --force node@24

node -v   # should show v24.x
openclaw gateway restart
openclaw gateway status  # RPC probe should become ok

Optional quick workaround (if you need it working immediately)

Try running in the foreground with a bigger heap:

openclaw gateway stop
NODE_OPTIONS="--max-old-space-size=4096" openclaw gateway --port 18789 --verbose

If that stops the crashes, we can make that setting permanent for the LaunchAgent after we confirm the exact error line.

#

That log snippet is the smoking gun:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

So the gateway isn’t “disconnecting” — it’s crashing (which makes the UI see WS close as 1006).

Fix #1 (recommended): run the gateway on Node 24 LTS (or 22 LTS), not Node 25

You’re on node 25.5.0 (non‑LTS). Swap to LTS and restart:

brew install node@24
brew unlink node
brew link --overwrite --force node@24

which node
node -v

#


openclaw gateway restart
openclaw gateway status   # looking for: RPC probe: ok

Fix #2 (workaround): raise the Node heap for the LaunchAgent

This buys headroom (and confirms it’s “just” heap pressure):

openclaw gateway stop
launchctl setenv NODE_OPTIONS "--max-old-space-size=4096"
openclaw gateway start

(If you want to revert later: launchctl unsetenv NODE_OPTIONS then restart.)

#

If it still OOMs after Node 24 + bigger heap

Then it’s likely a runaway session/history or a real leak. Two quick checks that are safe to paste:

du -sh ~/.openclaw/agents/*/sessions 2>/dev/null | sort -h | tail -n 20
tail -n 80 ~/.openclaw/logs/gateway.err.log

If it keeps happening on Node 24, I’d file a GitHub issue with gateway.err.log + openclaw --version: https://github.com/openclaw/openclaw/issues

frozen maple Feb 17, 2026, 12:36 PM

#

Tried fix 1:

Service: LaunchAgent (not loaded)
File logs: /tmp/openclaw/openclaw-2026-02-17.log
Command: /usr/local/bin/node /usr/local/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown (Bad request.
Could not find service "ai.openclaw.gateway" in domain for user gui: 504)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /Users/Hal/.openclaw/openclaw.json

Service unit not found.
Service not installed. Run: openclaw gateway install
File logs: /tmp/openclaw/openclaw-2026-02-17.log

rancid cobaltBOT Feb 17, 2026, 12:38 PM

#

That “fix 1” result just means the LaunchAgent isn’t installed/loaded anymore, so openclaw can’t manage it:

Could not find service "ai.openclaw.gateway" / Service unit not found. Service not installed. Run: openclaw gateway install

1) Reinstall the macOS LaunchAgent (and make sure it uses your current Node)

Run:

which node
node -v
openclaw gateway install --force --runtime "$(which node)" --port 18789
openclaw gateway start
openclaw gateway status

You’re aiming for RPC probe: ok.

#

2) Prevent the crash: raise the Node heap (persistent, works with launchd)

Your logs show a real heap OOM (Reached heap limit … heap out of memory), so give the gateway more heap via the service-loaded .env:

echo 'NODE_OPTIONS=--max-old-space-size=4096' >> ~/.openclaw/.env
openclaw gateway restart

(If you have plenty of RAM and it still OOMs, bump to 8192.)

3) If it still OOMs, it’s probably a huge JSON state/session file

The stack you pasted includes Builtin_JsonParse, which often means it’s trying to JSON.parse() something enormous/corrupt.

Run and paste the output:

#

du -sh ~/.openclaw/agents/*/sessions 2>/dev/null | sort -h | tail -n 20
ls -lh ~/.openclaw/logs/gateway.err.log
tail -n 60 ~/.openclaw/logs/gateway.err.log

If one sessions folder is massive, we can isolate the single giant file and move it aside (non-destructively) so the gateway boots again.

winged ivy Feb 17, 2026, 12:38 PM

#

rancid cobalt ```bash du -sh ~/.openclaw/agents/*/sessions 2>/dev/null | sort -h | tail -n 20 ...

💬 Hey Krill, that command looks like a good start to find out which session folders are taking up the most space. Once you identify the large ones, we can indeed move the big files elsewhere to get the gateway running again. Let me know if you need help with isolating and moving those files

rancid cobaltBOT Feb 17, 2026, 12:39 PM

#

That crash log is definitively an OOM:

FATAL ERROR: Reached heap limit … JavaScript heap out of memory

…and the stack showing Builtin_JsonParse suggests it’s trying to JSON.parse() something huge (often a giant session/state file), then the gateway dies → Control UI sees WS close as 1006.

You also now have a second problem: the LaunchAgent isn’t loaded/installed anymore, so openclaw can’t manage it.

A) Get the service back (and make sure it uses your current Node)

Run on the gateway Mac:

which node
node -v

openclaw gateway install --force --runtime "$(which node)" --port 18789

#

openclaw gateway start
openclaw gateway status

If gateway status still says the service isn’t there, paste the output of:

ls -lh ~/Library/LaunchAgents/ai.openclaw.gateway.plist

B) Give the gateway more heap (persistent for launchd)

echo 'NODE_OPTIONS=--max-old-space-size=4096' >> ~/.openclaw/.env
openclaw gateway restart

C) Find the “giant JSON” that’s triggering `JSON.parse` OOM

#

Paste the last lines of this:

du -ah ~/.openclaw | sort -h | tail -n 30

If you see a single file that’s hundreds of MB / GB, don’t delete it yet—just paste the filename here and we’ll move it aside safely (so you can restore it if needed).

frozen maple Feb 17, 2026, 12:43 PM

#

when I ran: openclaw gateway install --force --runtime "$(which node)" --port 18789

I got:

Invalid --runtime (use "node" or "bun")

rancid cobaltBOT Feb 17, 2026, 12:45 PM

#

--runtime only accepts node or bun — it doesn’t take a path. So this is the correct form:

openclaw gateway install --force --runtime node --port 18789

If you’re trying to make the LaunchAgent use Node 24, you need to make sure your system node (e.g. /usr/local/bin/node on Intel macs, /opt/homebrew/bin/node on Apple Silicon) points to Node 24 before you run gateway install, because the installer will pick a “system node” automatically.

1) Switch Homebrew “node” to 24 LTS

brew install node@24
brew unlink node
brew link --overwrite --force node@24

which node
node -v    # should be v24.x

#

2) Reinstall + start the service

openclaw gateway install --force --runtime node --port 18789
openclaw gateway start
openclaw gateway status

3) (Still recommended) add heap headroom to stop the OOM crashes

Since launchd won’t inherit your shell env, put it in ~/.openclaw/.env:

echo 'NODE_OPTIONS=--max-old-space-size=4096' >> ~/.openclaw/.env
openclaw gateway restart

After that, paste your new openclaw gateway status output. If it still dies, paste the last ~50 lines of ~/.openclaw/logs/gateway.err.log (that’ll tell us what it’s parsing that’s so huge).

frozen maple Feb 17, 2026, 12:52 PM

#

there's a bunch of things in the hundreds of mb and even gb. /Users/Hal/.openclaw is 7.5gb for instance.

how can I tell what is safe to delete?

rancid cobaltBOT Feb 17, 2026, 12:54 PM

#

If ~/.openclaw is 7.5GB and the gateway is crashing with heap out of memory, the goal isn’t “free space” as much as “find the one (or few) huge JSON/session files that the gateway is trying to parse”.

Here’s what’s safe vs risky to delete/move:

Generally safe to delete

Logs

/tmp/openclaw/openclaw-*.log
~/.openclaw/logs/gateway.log
~/.openclaw/logs/gateway.err.log

Deleting logs won’t break anything; you just lose history.

Usually safe (but you lose conversation history)

Session transcripts + session index

~/.openclaw/agents/<agentId>/sessions/<SessionId>.jsonl (transcripts)
~/.openclaw/agents/<agentId>/sessions/sessions.json (session metadata/index)

#

Per docs, transcripts live as JSONL and the sessions.json index can be recreated on demand; removing a transcript removes that conversation history. Source: https://docs.openclaw.ai/concepts/session#where-state-lives

Best practice: don’t delete first — move to a quarantine folder so you can restore if needed.

Not safe to delete (will break auth/channel pairing)

Credentials + auth profiles

~/.openclaw/credentials/ (WhatsApp/Telegram/etc state)
~/.openclaw/agents/<agentId>/agent/auth-profiles.json (your API keys/OAuth)
~/.openclaw/openclaw.json (config)

Source: https://docs.openclaw.ai/help/faq#where-does-openclaw-store-its-data

How to find the culprit (biggest files)

Stop the gateway first so nothing is writing while you move files:

#

openclaw gateway stop

Then list the biggest files:

cd ~/.openclaw
find . -type f -size +200M -exec ls -lh {} \; | sort -k5 -h

If you see something like a multi-hundred-MB/GB file under agents/.../sessions/, that’s very likely what’s triggering the JsonParse OOM.

“Safe fix” workflow (move, don’t delete)

mkdir -p ~/.openclaw/_quarantine
mv /path/to/the/huge/file ~/.openclaw/_quarantine/

#

openclaw gateway start

If the gateway comes back, you’ve confirmed the offending file. Then you can decide whether you want to permanently delete it (it’ll mean losing that session/history).

If you paste the output of that find ... -size +200M ... command (just the top few biggest lines), I can tell you which ones are logs vs sessions vs credentials and what I’d quarantine first.

frozen maple Feb 17, 2026, 12:57 PM

#

If I asked openclaw to make a large csv recently, which folder would that be in?

rancid cobaltBOT Feb 17, 2026, 12:58 PM

#

If you asked OpenClaw to write a CSV file, it will almost always end up in the agent’s workspace directory (because relative paths like report.csv or ./report.csv resolve there).

By default that workspace is:

~/.openclaw/workspace
(docs: https://docs.openclaw.ai/help/faq#where-should-agentsmd-soulmd-usermmd-memorymd-live)

Find your actual workspace path

On the gateway host:

openclaw config get agents.defaults.workspace

(If that returns empty, assume ~/.openclaw/workspace.)

Locate big CSVs

#

WORKSPACE="$(openclaw config get agents.defaults.workspace 2>/dev/null | tr -d '\"')"
[ -z "$WORKSPACE" ] && WORKSPACE="$HOME/.openclaw/workspace"
echo "Workspace: $WORKSPACE"

find "$WORKSPACE" -type f -name "*.csv" -size +50M -exec ls -lh {} \; | sort -k5 -h

If you’re in remote mode, remember the file is on the gateway machine, not necessarily the laptop where you’re looking.

frozen maple Feb 17, 2026, 12:58 PM

#

is it safe to delete things in the workspace folder?

rancid cobaltBOT Feb 17, 2026, 12:59 PM

#

It depends what the “things” are.

Safe (common)

Deleting generated artifacts you asked it to create is generally safe:

big .csv, .json, .txt, exports
downloaded files
screenshots / PDFs your skills produced

Worst case: you just lose that output file. The Gateway won’t “break” because a CSV is gone.

Be careful (this is your agent’s brain + setup)

Your workspace often also contains stuff you probably don’t want to delete unless you mean to reset things, like:

AGENTS.md, SOUL.md, USER.md, MEMORY.md / memory.md
memory/ folder (durable notes)
any custom skills/config files you put there

Deleting those can make the bot “forget” behavior/preferences and lose durable notes.

#

Practical “safe cleanup” approach

Find the largest files in the workspace:

cd ~/.openclaw/workspace
find . -type f -size +100M -exec ls -lh {} \; | sort -k5 -h

Instead of deleting immediately, move to an archive:

mkdir -p ~/.openclaw/workspace/_archive
mv path/to/big.csv ~/.openclaw/workspace/_archive/

If your main issue is the gateway OOM/crash, deleting/moving big CSVs is fine, but the OOM you pasted looked like the gateway choking while parsing its own JSON state—so if cleaning the workspace doesn’t fix it, we’ll likely need to quarantine a giant file under ~/.openclaw/agents/<agentId>/sessions/ next.

frozen maple Feb 17, 2026, 1:07 PM

#

1.1G /Users/Hal/.openclaw/agents
1.1G /Users/Hal/.openclaw/agents/main
1.1G /Users/Hal/.openclaw/agents/main/sessions

rancid cobaltBOT Feb 17, 2026, 1:08 PM

#

Yep — that’s very likely the problem. ~/.openclaw/agents/main/sessions is just conversation history + session metadata, and it can absolutely grow huge.

What’s in that folder (and what’s “safe”)

Inside ~/.openclaw/agents/main/sessions/ you’ll typically see:

sessions.json
Session index/metadata (map of sessionKey → sessionId/updatedAt/etc).
Safe to move/delete (it’ll be recreated), but you’ll lose the session list/history mapping in UIs until new sessions are created.
*.jsonl
Actual chat transcripts (often the biggest files).
Safe to move/delete in the sense the gateway will keep working — but you lose that conversation history (and any continuity that came from it). Your durable “memory” notes in the workspace are separate and won’t be deleted.

The safest approach: quarantine (move) the biggest offenders

Stop the gateway so nothing is writing while you move files:

#

openclaw gateway stop

Find the biggest files:

cd ~/.openclaw/agents/main/sessions
ls -lhS | head -n 30

Create a quarantine folder + move the top 1–3 huge files (start with the biggest .jsonl, and/or a huge sessions.json if it’s big):

mkdir -p ~/.openclaw/_quarantine/main-sessions
mv <HUGE_FILE.jsonl> ~/.openclaw/_quarantine/main-sessions/
# (repeat for a couple of the biggest ones)

#disconnected (1006): no reason

1) Confirm versions (important on macOS)

2) Do a clean daemon restart (to clear a wedged event loop)

3) Grab the log around the disconnect/crash

1) Paste the last ~100 lines of the gateway error log

2) Run the gateway in the foreground (so we can see the crash live)

1) Confirm it’s the classic “heap out of memory” line

2) Fix: don’t run the gateway on Node 25 (use Node 24 or 22 LTS)

Optional quick workaround (if you need it working immediately)

Fix #1 (recommended): run the gateway on Node 24 LTS (or 22 LTS), not Node 25

Fix #2 (workaround): raise the Node heap for the LaunchAgent

If it still OOMs after Node 24 + bigger heap

1) Reinstall the macOS LaunchAgent (and make sure it uses your current Node)

2) Prevent the crash: raise the Node heap (persistent, works with launchd)

3) If it still OOMs, it’s probably a huge JSON state/session file

A) Get the service back (and make sure it uses your current Node)

B) Give the gateway more heap (persistent for launchd)

C) Find the “giant JSON” that’s triggering JSON.parse OOM

1) Switch Homebrew “node” to 24 LTS

2) Reinstall + start the service

3) (Still recommended) add heap headroom to stop the OOM crashes

Generally safe to delete

Usually safe (but you lose conversation history)

Not safe to delete (will break auth/channel pairing)

How to find the culprit (biggest files)

“Safe fix” workflow (move, don’t delete)

Find your actual workspace path

Locate big CSVs

Safe (common)

Be careful (this is your agent’s brain + setup)

Practical “safe cleanup” approach

What’s in that folder (and what’s “safe”)

The safest approach: quarantine (move) the biggest offenders

C) Find the “giant JSON” that’s triggering `JSON.parse` OOM