Description

When the Anthropic API blocks an assistant output mid-stream due to content filtering (Output blocked by content filtering policy), the session history becomes permanently corrupted. Every subsequent user message triggers the same error repeatedly until the user manually resets with /new.

Steps to Reproduce

1. Send a message that causes the assistant to make a long write tool call (e.g., writing a multi-thousand-character Markdown file with classical Chinese text)
2. The Anthropic API blocks the output: Output blocked by content filtering policy
3. The tool call is truncated — the tool_use block exists but the corresponding tool_result is missing or synthetic
4. OpenClaw inserts a synthetic error result: "[openclaw] missing tool result in session history; inserted synthetic error result for transcript repair."
5. After this, every subsequent message fails with:

   LLM request rejected: messages.N.content.M: unexpected tool_use_id found in tool_result blocks: toolu_XXXXX. Each tool_result block must have a corresponding tool_use block in the previous message.
   

6. The session is permanently stuck. Only /new or /reset recovers it.

Expected Behavior

• After a content filtering error truncates a tool call, the session should auto-recover gracefully
• Options: automatically strip the orphaned tool_use/tool_result pair, or auto-reset the session, or at minimum inform the user to run /new

Actual Behavior

• The synthetic repair does not correctly fix the tool_use/tool_result pairing
• The session is permanently broken with no automatic recovery
• The error message is raw API jargon sent directly to the user in Telegram, which is confusing

Environment

• OpenClaw (latest, auto-updated 2026-01-31)
• Model: anthropic/claude-opus-4-5
• Channel: Telegram
• Trigger: Writing a long Markdown file containing classical Chinese literature (醉翁亭記 lecture notes)

Suggestion

1. When a content filtering error truncates a tool call, strip both the orphaned tool_use and the synthetic tool_result from the session history before the next API call
2. Alternatively, detect the "unexpected tool_use_id" error and auto-recover by pruning the broken message pair
3. Show a user-friendly message instead of raw API errors on messaging surfaces