Bug type

Performance/reliability bug

Summary

Large tool results are persisted to session transcripts by default, which can poison shared human-facing sessions (session.dmScope = "main") and cause severe lag, token blowups, and eventual instability/OOM under tool-heavy workflows.

Steps to reproduce

1. Configure shared DM lane:
   • session.dmScope = "main"
2. Use a non-Anthropic model path in the main lane.
3. Run several heavy tool calls (exec, read) returning very large outputs (~150k-200k chars each).
4. Continue chatting in that same shared main session.

Expected behavior

• Large tool outputs should not be persisted verbatim into the live owner-facing transcript.
• Protection against tool-result bloat should apply regardless of provider path.
• Main lanes should remain responsive after tool-heavy turns.

Actual behavior

• toolResult payloads are persisted by default.
• Very large payloads still pass through (high hard cap), so transcript keeps accumulating giant entries.
• In production this led to:
  • inflated token counts on simple replies,
  • typing TTL stalls / multi-minute lag,
  • and one gateway crash with V8 JSON/OOM signature.

OpenClaw version

2026.3.13 (also observed historically in earlier versions)

Operating system

macOS 26.3.1 (arm64)

Install method

npm global

Model

openai-codex/gpt-5.4 and openai-codex/gpt-5.3-codex (main lane during incidents)

Provider / routing chain

OpenClaw -> OpenAI Codex (main lane), with tool-heavy turns in shared DM session

Config file / key location

~/.openclaw/openclaw.json

Additional provider/model setup details

contextPruning enabled in config, but this does not sufficiently protect persisted transcript state on non-Anthropic lanes.

Logs, screenshots, and evidence

Key runtime/doc evidence from source analysis:

• Tool results are persisted by guarded append path (default behavior).
• Hard cap is permissive enough for very large entries (HARD_MAX_TOOL_RESULT_CHARS = 400000, MAX_TOOL_RESULT_CONTEXT_SHARE = 0.3).
• Session pruning is documented as in-memory context trimming, not transcript rewrite.
• Pruning coverage is provider-limited (Anthropic/OpenRouter Anthropic), leaving non-Anthropic lanes underprotected.

Production impact observed:

• many persisted tool results >=150k chars in session history,
• repeated owner-facing lag,
• and one gateway crash showing node::OOMErrorHandler + v8::internal::JsonParser in diagnostics.

Impact and severity

Affected: owner-facing shared sessions that also run heavy tooling
Severity: High (reliability + responsiveness)
Frequency: Reproducible under sustained tool-heavy usage
Consequence: Human-facing main lane becomes unstable/unresponsive over time

Additional information

Likely related but not identical to:

• [Feature]: Feature Request: before_assistant_persist hook to prevent session corruption from oversized responses #21598 (before_assistant_persist feature request; assistant messages)
• the tokens got burned by dragging a huge context forward #1594 (huge context/token burn)

This report is specifically about persisted toolResult transcript bloat in live shared sessions.

Suggested fix directions:

1. safer default persistence policy for tool results (summarize/externalize large payloads),
2. optional transcript-aware compaction of oversized historical toolResult entries,
3. stricter persistence defaults for owner-facing lanes,
4. model-agnostic protection behavior.