Bug type

Session state corruption / provider rejection

Summary

When a cron job runs in a persistent named session (sessionTarget: "session:<name>"), thinking content blocks accumulate in the session history across runs. If the thinking configuration changes between runs (or becomes inconsistent with the stored history), Anthropic rejects the entire request with a 400 immediately — causing the cron to fail silently and permanently until the session is reset.

Root cause

Anthropic's API requires that if a conversation history contains thinking content blocks, the current request must also have thinking enabled (and with a matching budget_tokens). If a cron payload sets thinking: "none" or thinking: "off" (or omits it), but the persistent session history from previous runs contains thinking blocks, Anthropic rejects the request.

OpenClaw does not strip or filter incompatible thinking blocks from session history before building the API request, so any thinking-configuration mismatch between runs permanently breaks the session.

Steps to reproduce

1. Create a cron job with sessionTarget: "session:my-session" and a model that supports thinking (e.g. claude-sonnet-4-6)
2. Run several cycles — the agent uses thinking and produces thinking content blocks stored in session history
3. Update the cron payload to set thinking: "none" or thinking: "off" (or change the budget), or let thinking be disabled via model default
4. Trigger the cron

Actual behavior

Cron fails immediately (~1 second) with:

LLM request failed: provider rejected the request schema or tool payload.

All subsequent scheduled runs fail in the same way. consecutiveErrors increments indefinitely. The session is permanently broken until manually reset (e.g. by switching to sessionTarget: "isolated").

Expected behavior

One of:

• Option A: OpenClaw detects thinking blocks in session history and automatically re-enables thinking (with the original or a default budget) to keep the history valid
• Option B: OpenClaw strips thinking content blocks from session history when building a request with thinking disabled, or when they would cause a schema rejection
• Option C: The gateway validates the thinking-history compatibility before submitting to the provider and returns a clear error with a suggested fix (e.g. "session history contains thinking blocks; use thinking: on or reset the session")

Observed workaround

Switching sessionTarget to "isolated" avoids the issue by giving each run a clean context with no accumulated thinking blocks. However, this loses cross-run session continuity.

OpenClaw version

2026.6.5 (5181e4f)

Operating system

Ubuntu 24.04 LTS x64

Additional context

• Model: anthropic/claude-sonnet-4-6
• Provider: Anthropic
• The invalid payload field thinking: "none" (instead of a valid value like "adaptive") may have been the original trigger that caused the mismatch; subsequent runs with thinking: "off" still failed, confirming the root cause is the stale thinking blocks in history, not just the invalid field value alone.
• The persistent session had been running successfully for ~406 cycles before the first failure, suggesting the issue is triggered by a configuration change mid-session rather than an initial setup error.