Summary

In OpenClaw 2026.5.26, long-running tools can persist many individually sub-cap toolResult entries into a session. The aggregate persisted tool output can later make even very short follow-up messages exceed the model context window.

This is not specific to one command or provider. The concrete report came from a Telegram direct session with a long-running process task, but the underlying issue is a general persisted-history/tool-output budget problem.

Real environment

• Version observed: OpenClaw 2026.5.26
• Surface: Telegram direct conversation
• Runtime shape: Windows-side OpenClaw bot/session running a long process task
• Model context: large-context model, but session history still became poisoned by aggregate persisted tool output

User-visible symptom

After a long-running process task produced repeated tool output, normal short Telegram messages failed repeatedly:

Your input exceeds the context window of this model. Please adjust your input and try again.

This happened even for short follow-up messages such as:

1

So the problem was not the current user input length; the previous persisted session history had grown too large.

Evidence from session inspection

The affected direct session contained many repeated persisted messages like:

role: toolResult
toolName: process
content: text chunks, many around ~30k chars each

Each individual chunk could be under an existing per-result cap, but the active branch accumulated enough of them that later prompts replayed too much tool output.

Raw screenshots/logs are intentionally not attached here because they include private Telegram/session details. The relevant error text and persisted-message shape are quoted above in redacted form.

Expected behavior

Persisted session history should not allow repeated tool outputs to grow without an aggregate budget. A long-running tool should not poison future turns such that unrelated short user messages fail context assembly.

Related fix

A proposed fix is in:

• Bound aggregate persisted tool results #87639

The PR keeps the existing per-tool-result cap, and adds an aggregate persisted toolResult budget for the active branch so repeated sub-cap outputs are rewritten/truncated before later user turns can replay them all.