openclaw - 💡(How to fix) Fix [Feature Request] Treat toolResult entries as valid cut points for safeguard compaction [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78478Fetched 2026-05-07 03:36:27
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
2
Author
Timeline (top)
commented ×1labeled ×1

The safeguard compaction mode (compaction.mode: "safeguard") excludes toolResult entries from valid cut points in findValidCutPoints(). This causes compaction to fail (producing empty fallback summaries) for sessions dominated by tool calls — exactly the pattern seen in long-running agentic tasks and cron jobs.

Error Message

  • #32759 — Fixed HTTP 400 error when no messages to summarize, but root cause (missing cut points) not addressed

Root Cause

However, the simpler fix (adding toolResult to valid cut points unconditionally) should work because:

  • The compaction splitting logic already ensures tool call pairs stay together (it moves the boundary if it lands inside a tool block)
  • Cutting after a toolResult naturally preserves the preceding toolCall

Code Example

## Decisions
No prior history.

## Open TODOs
None.
...

---

// src/core/compaction/compaction.ts (or equivalent location)
const validCutPointTypes = [
  'user',
  'assistant',
  'bashExecution',
  'custom',
  'branchSummary',
  'compactionSummary',
  'toolResult',  // ← Add this
];

---

{
  "agents": {
    "defaults": {
      "compaction": {
        "toolResultAsCutPoint": true  // ← New config option
      }
    }
  }
}
RAW_BUFFERClick to expand / collapse

Summary

The safeguard compaction mode (compaction.mode: "safeguard") excludes toolResult entries from valid cut points in findValidCutPoints(). This causes compaction to fail (producing empty fallback summaries) for sessions dominated by tool calls — exactly the pattern seen in long-running agentic tasks and cron jobs.

Problem to solve

findValidCutPoints() only accepts these entry types as valid cut points:

  • user
  • assistant
  • bashExecution
  • custom
  • branchSummary
  • compactionSummary

toolResult is explicitly excluded.

When a session's messages consist primarily of toolCalltoolResult pairs (with few or no user/assistant text messages), findCutPoint() returns no valid cut point. This triggers the safeguard's "no real conversation messages to summarize" branch, writing an empty fallback summary like:

## Decisions
No prior history.

## Open TODOs
None.
...

The compaction then fails to produce a meaningful summary, and the session cannot be extended via compaction.

Proposed solution

Add toolResult to the list of valid cut points in findValidCutPoints():

// src/core/compaction/compaction.ts (or equivalent location)
const validCutPointTypes = [
  'user',
  'assistant',
  'bashExecution',
  'custom',
  'branchSummary',
  'compactionSummary',
  'toolResult',  // ← Add this
];

Alternatives considered

If enabling toolResult as a cut point by default is deemed too risky, an alternative would be to make it configurable:

{
  "agents": {
    "defaults": {
      "compaction": {
        "toolResultAsCutPoint": true  // ← New config option
      }
    }
  }
}

Pros of the configurable approach:

  • Allows users to opt in based on their specific use case (agentic tasks vs. simple chat)
  • Provides a safe default for existing users while enabling the fix for those who need it
  • Easier to roll out and test in production without risking regressions for all users

Recommended default: true for mode: "safeguard" (since safeguard is already the more aggressive mode), or false for backward compatibility.

However, the simpler fix (adding toolResult to valid cut points unconditionally) should work because:

  • The compaction splitting logic already ensures tool call pairs stay together (it moves the boundary if it lands inside a tool block)
  • Cutting after a toolResult naturally preserves the preceding toolCall

Impact

This affects:

  • Long-running agentic tasks that execute many tool calls (read, exec, api calls) with minimal user text input
  • Cron sessions that perform automated workflows with tool-heavy execution
  • Any session where tool results dominate the conversation history

Even after the fix for #78300 (which added custom-message, bash, and branch-summary as anchors), sessions without explicit user/assistant text messages still fail to compact properly.

Evidence/examples

Session Analysis

A typical affected session (e.g., from E2E testing):

  • 7 safeguard compaction attempts
  • All compactions have firstKeptEntryId pointing to session header
  • findCutPoint() returns no valid cut point
  • messagesToSummarize is empty → boundary-only compaction
  • No training export produced (no valid sample)

Related Issues

  • #78300 — Fixed empty fallback summaries by adding custom-message, bash, branch-summary as anchors, but did not include toolResult
  • #71325 — Fixed safeguard not triggering on windowed/ownsCompaction sessions, but cut point logic unchanged
  • #32759 — Fixed HTTP 400 error when no messages to summarize, but root cause (missing cut points) not addressed

Rationale

  1. Tool results carry semantic content: They contain the actual output of tool calls (file contents, command output, API responses) — this is often the most valuable information to preserve in a summary.

  2. Tool call pairs are atomic: A toolCall and its matching toolResult should be kept together. Using toolResult as a cut point naturally preserves this pairing (the cut happens after the result, keeping the full call+result unit).

  3. Consistent with existing anchors: bashExecution is already a valid cut point, and it's semantically similar to toolResult (both are execution outputs).

  4. Fixes the agentic task gap: Long-running agentic tasks are exactly the use case where compaction should work, but they're currently blocked by this limitation.

Additional information

Environment

  • OpenClaw version: 2026.5.5 (latest main)
  • Config: compaction.mode: "safeguard"
  • Affected session types: Agentic tasks, cron jobs, tool-heavy workflows

Related

  • #78300 (empty fallback summaries — partial fix)
  • #71325 (safeguard not triggering — different root cause)
  • #32759 (HTTP 400 on empty messages — symptom, not root cause)
  • #41981 (cron lane blocked by compaction loop — symptom)

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Feature Request] Treat toolResult entries as valid cut points for safeguard compaction [1 comments, 2 participants]