[xh123637]

Summary

Fixes #1028. With a Gemini 3 model on the native Gemini provider, the first tool call succeeds and the follow-up request fails with HTTP 400: Google returns a thoughtSignature as a sibling of each functionCall part and requires it back, unchanged, in the same part on the next request — but Clawith dropped it at every step:

• GeminiClient._parse_response_data copied only keys from inside functionCall into _gemini_extra; the part-level thoughtSignature never reached the normalized tool call.
• GeminiClient.stream() collapsed all parts' signatures into one response-level reasoning_signature that is not tied to any tool call.
• _sanitize_tool_calls_for_context (caller.py) and the durable runtime (model_step_service.py) rebuild tool calls from id/name/arguments only, so the signature also vanished between steps.
• GeminiClient._build_payload never emitted a part-level thoughtSignature (it merged _gemini_extra into the functionCall object instead).

Changes

The signature now travels on the normalized tool call as _gemini_thought_signature, next to the existing _gemini_extra:

• backend/app/services/llm/client.py
  • _parse_response_data stores the part-level thoughtSignature on the tool call.
  • stream() binds the signature of the part that carries a functionCall to that tool call (the response-level reasoning_signature behaviour is unchanged).
  • _build_payload emits {"functionCall": {...}, "thoughtSignature": ...} as a part-level sibling when the tool call carries a signature.
• backend/app/services/llm/caller.py — _sanitize_tool_calls_for_context carries _gemini_thought_signature exactly like _gemini_extra.
• backend/app/services/agent_runtime/model_step_service.py — _with_call_instances stores the signatures keyed by Call Instance ID in additional_kwargs["provider_thought_signatures"] (mirroring provider_call_ids, and only when at least one signature exists, so stored messages for other providers keep their exact previous shape); _prompt_messages re-attaches the signature to the rebuilt tool call by Call Instance ID.

Tool calls without a signature serialize byte-identically to before.

Scope note: this covers the native Gemini provider from the issue's reproduction steps. The OpenAI-compatible Gemini endpoint (.../v1beta/openai/), where the signature travels as extra_content.google.thought_signature on OpenAI-shaped tool calls, loses it in a different place (stream aggregation in OpenAICompatibleClient) and is not changed here.

Tests

New backend/tests/test_llm_gemini_thought_signature.py (9 tests): non-streaming parse keeps the signature on the tool call and the next payload sends it back as a part-level sibling; streaming (httpx MockTransport SSE) binds the signature to its own tool call; the context sanitizer keeps it; the runtime stores it under the Call Instance ID and restores it onto the rebuilt tool call, ending in the final Gemini payload. With the three source files reverted, the 6 behaviour tests fail (the signature is lost end to end, matching the issue) and the 3 guards still pass (a response without a signature gains no key, a payload without a signature is byte-unchanged, runtime storage without signatures keeps its exact previous shape); with the fix, all 9 pass.

Full backend suite (root pytest config): 9 failed / 2564 passed with the fix vs 9 failed / 2555 passed on unmodified main in the same sandbox — the failure sets are identical (pre-existing test_deploy_tools.py environment failures) and the +9 are the new tests. ruff check on the changed files reports the same 38 pre-existing findings before and after; this change adds none.