OpenClaw error: RangeError, maximum call stack size exceeded

The error appears in these forms:

RangeError: Maximum call stack size exceeded
openclaw rangeerror: maximum call stack size exceeded
Maximum call stack size exceeded

What it actually means

This is a JavaScript stack overflow. Something recursed too deeply, or something tried to serialize a structure that refers back to itself. It is a crash inside OpenClaw, not a rejected request and not a bad setting, which is why looking through your config for the cause is usually wasted effort.

Upgrade first, because this has been fixed three times

Three distinct bugs in OpenClaw have produced this exact error, each with its own fix in a later release:

Trigger	Cause	Status
Uploading a PDF or image in the Control UI or WebChat	Large attachment payloads held in UI state and in optimistic chat messages	Fixed, payloads moved to object URL previews with send-time serialization
Starting the TUI with a long chat history	Chat-log components grew without bound and overflowed render recursion	Fixed, component growth capped and stale render nodes pruned
Large or unusual agent payloads	Circular references in cache-trace payloads during stable stringify	Fixed, stringify guarded against circular references

So the first move is not to debug it, it is to stop running the version that has the bug:

openclaw --version
npm install -g openclaw@latest
openclaw gateway restart

The restart matters. Upgrading the package while an old gateway process keeps running leaves you testing the same build you just replaced.

If it survives the upgrade, identify the trigger

The three causes have three very different fingerprints, and knowing which one you have tells you the workaround.

It fires when you attach a file

Large PDFs and images were the original reported trigger. Test with a small image. If that works and a large PDF does not, you have this path. Send the file to the agent by path or URL instead of pasting it into the chat, and keep attachments modest while you wait for the fix to reach your channel.

It fires on startup or when opening the TUI

This one comes from history size, so it looks like OpenClaw is broken from the first second. Reduce how much history gets loaded at once. The channel configuration exposes historyLimit and dmHistoryLimit for exactly this, and lowering them is a safe experiment because it changes what is displayed, not what is stored.

It fires mid-conversation on long sessions

Long sessions build large payloads. Keep compaction enabled so the context gets summarised rather than growing without limit, and start a fresh session with /new to confirm that session length is the variable.

Collect the right information before reporting it

If none of the above applies, this is worth reporting, and a report with these four things attached gets fixed far faster than one without:

• The output of openclaw --version
• Whether it happens in the TUI, the Control UI, or a messaging channel
• The exact action that triggers it
• The stack trace from openclaw logs --follow, not just the one line

What not to do

Do not wipe ~/.openclaw. The error is a runtime crash, so your sessions, memory and configuration are intact, and deleting them costs you real data to fix a problem they did not cause. If you want to see whether state is involved, move the directory aside rather than removing it, and move it back when you are done.