openclaw - 💡(How to fix) Fix [Bug]: Persisted `toolResult.details.aggregated` bypasses tool-result truncation and token estimation, causing durable transcript bloat and repeated compaction in OpenAI-Codex sessions [1 participants]

Summary

In OpenClaw 2026.4.11, heavy tool-use sessions on the openai-codex lane can get stuck in repeated compaction because oversized tool-result payloads are still being persisted in toolResult.details.aggregated even when visible tool-result text is truncated.

The key problem is:

• message.content[*].text is capped
• but message.details.aggregated still persists very large payloads
• token estimation and compaction planning appear to ignore that persisted details.aggregated payload
• so the session transcript on disk stays much larger than the runtime thinks it is

This creates a durable pollution problem, not just a live-context problem.

Environment

• OpenClaw version: 2026.4.11
• Install method: global npm
• OS: Ubuntu on WSL2
• Provider/model lane: openai-codex/gpt-5.4
• Session type: normal direct user chat with heavy built-in tool usage, especially exec

What I observed

In large tool-result turns, especially with exec:

• message.content[*].text is truncated to around 40k chars
• but message.details.aggregated can still persist around 150k to 200k chars

This means the built-in truncation only half-fixes the problem.

From local source inspection, the relevant behavior appears to be:

• capToolResultSize(msg) calls truncateToolResultMessage(msg, DEFAULT_MAX_LIVE_TOOL_RESULT_CHARS, ...)
• DEFAULT_MAX_LIVE_TOOL_RESULT_CHARS = 40000
• getToolResultTextLength(msg) appears to count only msg.content[*].text
• message.details.aggregated is not included in that sizing path

Related downstream logic also appears to rely on the same limited measurement:

• truncateOversizedToolResultsInSessionManager(...)
• estimateToolResultReductionPotential(...)
• buildToolResultReplacementPlan(...)

Those seem to only “see” content text, not the large persisted details.aggregated payload.

There also seems to be a second mismatch:

• estimateMessagesTokens(messages) uses stripToolResultDetails(messages)
• so token/compaction estimation ignores tool-result details
• but the stored transcript still keeps those huge details.aggregated payloads

Expected behavior

One of these needs to happen:

1. toolResult.details.aggregated should be stripped or hard-capped before transcript persistence, especially for exec
2. or tool-result sizing / compaction planning / token estimation must include persisted details
3. ideally both

If a large tool result is too big for durable history, it should not remain on disk in a form that keeps poisoning future turns.

Actual behavior

• visible tool-result text is truncated
• oversized details.aggregated still persists
• compaction/retry logic underestimates how much transcript pressure actually exists
• session continues to hit compaction pressure again
• the transcript remains polluted until reset / cleanup, even though the user-facing context signal suggests compaction should have relieved it

Why this matters

This breaks the simple expected behavior of:

• session grows
• around ~80% it compacts
• session becomes usable again

Instead, the session can compact repeatedly while still carrying oversized persisted tool-result baggage forward.

This is especially painful on mobile, where the user needs a minimal and reliable “context is healthy / context is not healthy” behavior, not a diagnostic dashboard.

Repro direction

1. Start a normal openai-codex session
2. Trigger several heavy built-in tool calls, especially exec
3. Let the session approach compaction pressure
4. Inspect stored tool-result entries in the session transcript
5. Compare:
   • truncated content[*].text
   • still-large details.aggregated
6. Observe that compaction happens, but future turns still re-enter pressure faster than expected

Impact

• repeated compactions
• degraded session stability
• transcript stays polluted after compaction
• effective context window feels much smaller than it should
• user experience regresses from “compact and continue” to “compact spiral / unhealthy session”

Additional context

This feels like a regression in transcript hygiene. Earlier behavior seemed to sanitize transcript pollution more aggressively, while the current lane appears to allow large persisted tool-result details to survive even when visible content is capped.

Proposed fix direction

Best fix:

• strip or hard-cap toolResult.details.aggregated before transcript write

Minimum acceptable fix:

• make all tool-result size estimation, reduction planning, and compaction logic account for persisted details.aggregated