Problem

Multi-pass context compression on long sessions (155+ messages) can produce tool-role messages with tool_call_id set to None, empty string, or missing entirely. The existing _sanitize_tool_pairs method handles two failure modes but misses this third one — these malformed messages slip through and reach the API, causing HTTP 400:

'tool_call_id' is not set

Once a session gets corrupted this way, it's permanently stuck — every subsequent API call fails with the same 400, and since the error classifier treats it as a generic format_error (non-retryable), it falls back to the same broken messages. The user sees Primary model failed — switching to fallback repeatedly until they manually run /new.

Reproduction: Long WeChat session (155 msgs, ~33K tokens) → 5+ compression passes → MiMo API rejects every subsequent request with 400. Workaround is /new to start a fresh session.

Fixes #16472 — Tool call ID not invalidated after 400 error (same permanent-failure loop from malformed tool messages).

Fixes #4662 — Malformed persisted tool calls poisoning sessions (our Part 1 prevents corruption at compression time, Part 2 auto-recovers when corruption is detected via API 400).

Also mitigates:

• Session compression corrupts tool_call arguments, truncating JSON to 214 chars #12731 — Session compression corrupts tool_call arguments (compression sanitizer now catches missing IDs)
• Truncated tool_call.arguments in conversation history wedges the retry loop #14443 — Truncated tool_call.arguments wedges the retry loop (retry loop now auto-sanitizes instead of looping forever)
• run_agent sanitizer misclassifies tool results when tool_call_id has surrounding whitespace #9999 — sanitizer misclassifies tool results with whitespace in tool_call_id (different bug, but our sanitizer improvements reduce the attack surface)

Root Cause

Two-part chain:

Part 1 — Compression produces malformed messages:
_sanitize_tool_pairs only collects tool_call_id values that are truthy. Tool messages with falsy tool_call_id never enter the orphan-detection set, so the filter never matches them.

Part 2 — Error classifier doesn't recognize tool format errors:
The _classify_400 function only triggers compression for context_length_exceeded patterns. A 400 like tool_call_id is not set falls through to format_error → non-retryable → fallback → same broken messages → still 400 → permanent loop.

Fix

Part 1: Prevent corruption (context_compressor.py)

Added Step 0 to _sanitize_tool_pairs: filter out tool-role messages where tool_call_id is falsy before the existing orphan checks run.

Part 2: Auto-recover from corruption (error_classifier.py + run_agent.py)

• New FailoverReason.tool_message_malformed enum value
• New should_sanitize_tools flag on ClassifiedError
• New _TOOL_CALL_MALFORMED_PATTERNS matching tool_call_id, function call output, etc.
• New _sanitize_tool_messages_for_retry() method on AIAgent that removes malformed/orphaned tool messages in-place
• Retry loop checks classified.should_sanitize_tools and auto-recovers instead of falling back

Tests

6 new tests across 2 test files:

• test_sanitizer_removes_tool_messages_with_none_tool_call_id
• test_sanitizer_removes_tool_messages_with_empty_tool_call_id
• test_sanitizer_removes_all_orphaned_when_no_assistant_calls
• test_400_tool_call_id_malformed (error classifier)
• test_400_no_tool_call_found_for_output (error classifier)
• test_enum_members_exist (updated for new enum value)

All 125+ tests pass.