[hartmark]

Fix leakage for openapi -> gemini translation.
Historical tool callings should use the gemini native format and not translate into text, otherwise the resulting response will end up being a text output as the Gemini LLM is a pattern recognition engine and if it sees tool calls as text in the history it thinks the proper response is that.

provider response seen in wild and reproduced with tests against live Gemini models. Just export your keys into the env-variables.

provider response before fix:

"summary": {
"candidates": [
{
"index": 0,
"content": {
"role": "model",
"parts": [
{
"text": "The user wants the results of a job search from the URL they just added..... <redacted>",
"thought": true
},
{
"text": "Historical tool-call record only. Do not execute, imitate, or continue this as a tool call.\nTool name: web_fetch\nTool arguments JSON: {"url":"<redacted>"}"
}
]
},
"finishReason": "STOP"
}

[gemini-code-assist]

Code Review

This pull request refactors the OpenAI-to-Gemini translator to use a compact format for historical tool calls in text mode and defaults signaturelessToolCallMode to "native". It also cleans up unused imports, removes redundant type assertions, and adds integration, unit, and manual tests to verify that historical tool calls do not leak into the model's output. Feedback on the changes highlights a potential TypeScript compilation error under strict compiler settings when accessing _signatureNamespace via dot notation on a Record<string, unknown> type, suggesting the use of bracket notation instead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[diegosouzapw]

Thanks @hartmark — this is a great catch and the fix is correct. Merging into release/v3.8.20. 🙌

Context: a day ago we landed #3560, which deliberately kept the standard Gemini direct path on signaturelessToolCallMode: "text" on the assumption that thinking Gemini models reject historical functionCall parts that lack a thoughtSignature (400 "missing thought_signature"). Your PR challenges exactly that assumption, so before merging I validated it against the real Gemini API (Hard Rule #18, live test on our production VPS using a real gemini API key):

Sent gemini-2.5-flash:generateContent the exact contents your native path emits — a historical functionCall (role model) with no thoughtSignature, followed by a functionResponse and a user follow-up:

Scenario	Result
baseline text request	HTTP 200
signatureless native functionCall (thinking model)	HTTP 200 — "Sunny and 22°C."
strict: tools declared + thinkingConfig{thinkingBudget:1024} + signatureless functionCall	HTTP 200 — coherent summary

So current Gemini accepts signatureless native parts on thinking models — no 400, even in the strict tools+thinking case. Your "native" default is right, and it removes the text-serialization leak (the model echoing [tool_history_call:…] / "Historical tool-call record only" into its output) that the text mode caused.

The Antigravity/CLI bypass path (supportsSignatureBypass + skip_thought_signature_validator sentinel) from #3560 is untouched and still applies there. Verified green locally: translator-openai-to-gemini (37), t43-…-no-thought-signature (3), executor-gemini-cli (14), gemini-signatureless-text-mode (2), typecheck:core clean. I'll reconcile a now-stale comment on our side (the round-2 regression test still passes — its rationale comment just predates this finding).

[hartmark]

Nice to know my analysis was correct. It was quite a discreet bug that i had with OpenClaw. Sometimes my tool calling would fail with the text and i first thought it was something wrong with OpenClaw before i found it in omniroute