LLM request rejected: unexpected tool_use_id in tool_result blocks

[dwebster123]

Bug Description

Getting a repeated error when using Roo-Code with the Anthropic API:

LLM request rejected: messages.98.content.1: unexpected tool_use_id found in tool_result blocks: toolu_0114eUeLnM3d16LHL9X69Y92. Each tool_result block must have a corresponding tool_use block in the previous message.

The error persists across retries with the same tool_use_id, suggesting the conversation history is replayed with the same corrupted state.

Expected Behavior

The conversation should continue without API validation errors.

Likely Cause

A tool_result block in the conversation history references a tool_use_id that no longer has a matching tool_use block in the preceding assistant message. This can happen when conversation history is truncated or summarized — if the assistant message containing the tool_use is removed but the following user message with the tool_result is kept, the pairing breaks.

Suggested Fix

• Treat tool_use/tool_result pairs as atomic units when trimming conversation context — never remove one without the other.
• Validate the message array before sending to the API to ensure every tool_result.tool_use_id has a corresponding tool_use block in the immediately preceding assistant message.

Environment

• API: Anthropic (Claude)
• The error occurs at message index 98, suggesting it happens in longer conversations after context management kicks in.

I've analyzed this issue and here's my proposed implementation plan:

Root Cause Analysis

The bug occurs when sliding window truncation removes assistant messages containing tool_use blocks, but keeps user messages with tool_result blocks that reference those removed tool_use_ids. Anthropic's API requires every tool_result block to have a corresponding tool_use block in the immediately preceding assistant message.

Current Code State

Looking at src/core/condense/index.ts, the getEffectiveApiHistory() function already filters orphan tool_result blocks when condensation (summary) has occurred. However, when there's no summary and only sliding window truncation has been applied, the function does NOT filter orphan tool_result blocks from messages that reference truncated tool_use blocks.

Specifically, the code path starting at line 472 handles the "no summary" case but only filters based on condenseParent and truncationParent - it doesn't check for orphan tool_result references.

Proposed Fix

Modify getEffectiveApiHistory() to also filter orphan tool_result blocks in the no-summary code path. The fix will:

1. After determining which messages are "visible" (not truncated), collect all valid tool_use IDs from visible assistant messages
2. Filter out any tool_result blocks in visible user messages that reference tool_use_ids not in the visible set
3. Remove user messages that become empty after filtering

This aligns with the existing pattern already used in the condensation (summary) code path and ensures tool_use/tool_result pairs remain atomic regardless of how truncation occurs.

Files to Modify

• src/core/condense/index.ts: Add orphan tool_result filtering to the no-summary code path in getEffectiveApiHistory()
• src/core/condense/__tests__/index.spec.ts: Add test cases for orphan tool_result filtering after truncation

This approach is robust because it's a single point of defense that catches all cases, regardless of how context management is triggered.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[dwebster123]

@roomote Approve — I've also submitted PR #11030 with this exact fix implemented and all tests passing.

Thanks for the approval and for proactively submitting PR #11030 with the fix! I reviewed the PR and it implements exactly what I proposed - filtering orphan tool_result blocks in the no-summary code path of getEffectiveApiHistory().

Since your PR already has the complete implementation with tests passing, I will support that PR rather than creating a duplicate. The fix looks solid and addresses the root cause properly.

[hannesrudolph]

@dwebster123 what version of Roo Code are you seeing this with?

[tagraham]

Encountered this error (happens several times a day under normal usage):
LLM request rejected: messages.202.content.1: unexpected tool_use_id found in tool_result blocks: toolu_016vTGXiHeKC1XVMYK3ptmvj.
Each tool_result block must have a corresponding tool_use block in the previous message.

My workaround is to have cron run a cleanup script (scripts/tool-error-monitor.sh) with an auto-fix timer enabled:

• systemctl --user status clawdbot-autofix.timer
• systemctl --user status clawdbot-autofix.service

The script below doesn't fix the root cause but can keep the system running. (Mac Mini Running Linux):

#!/bin/bash

# Clawdbot Tool Error Monitor & Auto-Fix
# Watches for tool_use_id errors and attempts recovery

# Set PATH to include clawdbot
export PATH=/home/direwolf/.nvm/versions/node/v22.22.0/bin:$PATH

LOG_DIR="/tmp/clawdbot"
ERROR_LOG="/tmp/clawdbot-tool-errors.log"
EMAIL="youEMAIL@Example.Com"

echo "🔍 Starting Clawdbot tool error monitor..."
echo "Watching: $LOG_DIR/clawdbot-*.log"
echo "Errors logged to: $ERROR_LOG"

# Create error log if it doesn't exist
touch "$ERROR_LOG"

# Monitor all clawdbot log files for tool_use_id errors
tail -F "$LOG_DIR"/clawdbot-*.log 2>/dev/null | while read line; do
    if echo "$line" | grep -qi "tool_use_id.*unexpected\|tool_result.*tool_use"; then
        TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
        echo "🚨 [$TIMESTAMP] Tool ID mismatch detected!" | tee -a "$ERROR_LOG"
        echo "$line" | tee -a "$ERROR_LOG"
        
        # Capture surrounding context (20 lines before/after)
        echo "=== CONTEXT CAPTURE ===" >> "$ERROR_LOG"
        tail -n 50 "$LOG_FILE" | head -n 40 >> "$ERROR_LOG"
        echo "=== END CONTEXT ===" >> "$ERROR_LOG"
        
        # Attempt automatic fix - restart gateway
        echo "🔧 Attempting automatic fix: restarting Clawdbot gateway..."
        clawdbot gateway restart
        
        # Wait a moment for restart
        sleep 5
        
        # Check if gateway restarted successfully
        if clawdbot gateway status | grep -qi "running"; then
            echo "✅ Gateway restarted successfully" | tee -a "$ERROR_LOG"
            FIX_STATUS="SUCCESS - Gateway restarted automatically"
        else
            echo "❌ Gateway restart failed" | tee -a "$ERROR_LOG"
            FIX_STATUS="FAILED - Manual intervention required"
        fi
        
        # Send email report
        SUBJECT="Clawdbot Tool Error Auto-Fixed - $TIMESTAMP"
        BODY="Tool use ID error detected and auto-fix attempted.

Status: $FIX_STATUS
Time: $TIMESTAMP
Error Line: $line

Full context attached. Please forward this to the Clawdbot devs.

--- Error Log ---
$(tail -n 50 "$ERROR_LOG")

"

    # Send email using gog
    echo "$BODY" | gog gmail send --to "$EMAIL" --subject "$SUBJECT"
    
    echo "📧 Error report emailed to $EMAIL"
    echo "----------------------------------------" >> "$ERROR_LOG"
fi

done