openclaw - 💡(How to fix) Fix Session ending with assistant message causes infinite prefill error loop with Opus 4.6 [1 participants]

Bug Description

When a session transcript ends with an assistant role message (e.g., due to OAuth prompt, tool timeout, or aborted response), subsequent attempts to resume that session fail with Anthropic API error because Claude Opus 4.6 does not support assistant message prefill.

This creates an infinite error loop — every trigger (mention, DM, heartbeat) hits the same error, and the session never recovers.

Reproduction

1. Configure an agent with anthropic/claude-opus-4-6 as primary model
2. Trigger a session where the last stored message is role: assistant (e.g., OAuth authorization prompt that gets no user follow-up)
3. Send a new message to that session
4. Expected: Agent responds normally
5. Actual: FailoverError — API rejects the request because messages end with assistant role

Error Log

lane task error: lane=session:agent:xxx:telegram:group:yyy 
error="FailoverError: The AI service is temporarily overloaded..."

The error cascades through the entire fallback chain (anthropic → codex → minimax → newapi), because the session transcript itself is malformed.

Root Cause

The session store (.jsonl) persists the assistant message as the last entry. On next load, OC sends this transcript to the model API. Anthropic Opus 4.6 requires the last message to be role: user — it does not support assistant prefill. Other models (Sonnet, GPT) handle this fine.

Proposed Fix

In the message preparation pipeline (before sending to model API), add a guard:

// If last message is assistant and model doesn't support prefill,
// inject a synthetic user message to allow continuation
if (messages.length > 0 && messages[messages.length - 1].role === "assistant") {
  if (!modelCapabilities.supportsPrefill) {
    messages.push({
      role: "user",
      content: [{ type: "text", text: "(session resumed)" }]
    });
  }
}

Alternatively, the session store could ensure transcripts never end with an assistant message by appending a sentinel on write.

Impact

• Affects all agents using Opus 4.6 as primary model
• In multi-agent setups (14 agents), this can cascade across all agents simultaneously
• Recovery requires manual session file deletion
• We found 28 affected sessions across 16 agents in a single Docker instance

Environment

• OpenClaw: 2026.3.28
• Model: anthropic/claude-opus-4-6
• Setup: Multi-agent Docker deployment with Telegram + Feishu channels

Workaround

We wrote a cron script that periodically scans session files and deletes any that end with role: assistant. This prevents the error loop but loses session context.