[BUG] Switching between models causes Provider Error

[QuinRiva]

Problem (one or two sentences)

When switching from Gemini 3 Pro (via Gemini), to Claude Opus 4.5 (hosted via Vertex AI) I get the following error

Date/time: 2026-01-05T10:13:26.264Z
Extension version: 3.38.3
Provider: gemini
Model: gemini-3-pro-preview

400
400 {"type":"error","error":{"type":"invalid_request_error","message":"messages.1.content.0: Invalid `signature` in `thinking` block"},"request_id":"req_vrtx_011CWp42ZEvdekfzop6M5MdV"}

My best guess is that this may be something to do with trying to access thought signatures?

Context (who is affected and when)

Presumably anyone using Gemini Pro 3, via Gemini (not sure if Vertex AI experiences the same issue).

Reproduction steps

Ubuntu 24 via WSL 2.0
Roo Code 3.38.3

1. Start a conversation with Gemini
2. Switch to a different model.
3. Try to do anything.

Expected result

Conversation thread continues

Actual result

400 error

Variations tried (optional)

No response

App Version

3.38.3

API Provider (optional)

Google Gemini

Model Used (optional)

Gemini 3 Pro, Claude Opus 4.5

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

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

Root Cause Analysis

The bug occurs when switching from Gemini 3 Pro to Claude via Vertex AI because:

1. Gemini produces reasoning content with a thoughtSignature (encrypted reasoning continuity token)
2. Task.ts stores this incorrectly as an Anthropic-style thinking block with the Gemini signature (see lines 793-802 in src/core/task/Task.ts)
3. When switching to Claude/Vertex, the filterNonAnthropicBlocks function allows thinking blocks through since they are valid Anthropic types
4. Claude/Vertex rejects the request because the signature in the thinking block was generated by Gemini, not Claude, and cannot be cryptographically validated

The problematic code in Task.ts has a comment saying "Anthropic provider with extended thinking" but does NOT actually check the provider type:

if (reasoning && thoughtSignature && !reasoningDetails) {
    // Anthropic provider with extended thinking: Store as proper \`thinking\` block
    const thinkingBlock = {
        type: "thinking",
        thinking: reasoning,
        signature: thoughtSignature,
    }

Proposed Fix

Modify src/api/transform/anthropic-filter.ts to filter out thinking blocks that have signatures. The reasoning is:

1. Thinking blocks with signatures are only valid when continuing the same conversation session with the same provider
2. When switching providers, old thinking blocks with signatures should be stripped
3. This is a safe, defensive fix that prevents invalid signatures from being sent to any Anthropic provider

Implementation:

1. Update filterNonAnthropicBlocks to filter thinking blocks that contain a signature field
2. Keep thinking blocks without signatures (if any exist) for backward compatibility
3. Add appropriate tests

This approach:

• Fixes the issue without changing how Task.ts stores messages
• Is defensive - prevents any invalid signature from reaching Anthropic APIs
• Has minimal impact on existing functionality

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