If your OpenClaw agent suddenly stops replying with:
⚠️ Agent failed before reply: Cannot create a string longer than 0x1fffffe8 characters.you’ve hit Node.js ERR_STRING_TOO_LONG. OpenClaw (or one of its tools) tried to materialize a single JavaScript string larger than 0x1fffffe8 — 536,870,888 UTF-16 characters. This is a hard limit in V8, so raising --max-old-space-size will not fix it.
The usual culprit: a session transcript JSONL file that has ballooned to hundreds of megabytes. When OpenClaw reads that file back to rehydrate the conversation, Node chokes on the enormous string.
Why It Happens
The per-string ceiling is independent of total heap memory. A session file grows past it when:
- A tool reads a large file with
readFile/readFileSync. - Binary data is converted to base64 or UTF-8 (pasted images get base64-encoded straight into the transcript).
- An enormous command result is captured whole instead of streamed.
- A plugin concatenates logs or HTTP responses.
- Months of conversation history accumulate in one session.
Diagnose It
Tail the logs and reproduce the failed request to see the stack trace:
openclaw logs --follow --plain --no-colorScan existing logs for the signature error and the call that triggered it:
openclaw logs \
--limit 1000 \
--max-bytes 2000000 \
--plain --no-color | grep -nE -B20 -A40 \
'ERR_STRING_TOO_LONG|Cannot create a string|Buffer\.toString|JSON\.(parse|stringify)|readFile'Then find the oversized files. Session JSONL files live under ~/.openclaw/agents/<agent>/sessions/; gateway logs live under /tmp/openclaw/:
find ~/.openclaw /tmp/openclaw \
-type f -size +100M \
-exec du -h {} + 2>/dev/null | sort -hA single session weighing hundreds of MB is your smoking gun:
516M ~/.openclaw/agents/main/sessions/60dcebd2-….jsonl ← the one that locks
52M ~/.openclaw/agents/main/sessions/13439494-….jsonl
49M ~/.openclaw/agents/main/sessions/89e8f2e3-….jsonlRecover the Agent
Send this as a standalone message in the affected channel:
/newor:
/resetOpenClaw handles bare /new and /reset commands without invoking the model, so they can recover a poisoned session even when normal replies fail. Then run the read-only health check:
openclaw doctor --lint --jsonDo not run a full openclaw reset yet — depending on its scope, it can remove configuration, credentials, and sessions.
Archive the Bloated Session
Moving the file is safer than deleting it. Your MEMORY.md and ordinary workspace files are untouched — you’re only relocating one session JSONL:
mkdir -p ~/openclaw-session-backups
mv ~/.openclaw/agents/main/sessions/60dcebd2-*.jsonl \
~/openclaw-session-backups/Start a fresh session in the channel, and the agent responds normally again.
Prevent Recurrence
Add a tool-result ceiling so persisted results can’t grow without bound:
openclaw config set \
agents.defaults.contextLimits.toolResultMaxChars \
16000The limit only helps if the underlying tool doesn’t build a giant string before the limit is applied — so bound output at the source. For shell tools, cap explicitly rather than capturing everything:
some-command | head -c 1000000
tail -n 1000 huge.log
sed -n '1,2000p' huge-file.txtThe responsible tool or skill should stream or chunk data instead of constructing one giant string, and large binaries (especially images) should be referenced by path rather than inlined as base64.
Key Takeaways
ERR_STRING_TOO_LONGis a V8 per-string limit (0x1fffffe8), not a heap problem —--max-old-space-sizewon’t help.- The cause is almost always a bloated session JSONL from inlined images and long history.
- Recover with a standalone
/newor/reset, then archive the oversized file. - Prevent it with
toolResultMaxCharsplus tools that stream and cap their output.
