openclaw - 💡(How to fix) Fix Cross-provider reasoning_details → Gemini thought_signature 400 still reproduces on 2026.5.26 (OpenAI/Codex → google/gemini-2.5-flash-lite) — regression after #86043 closure

Bug type

Regression (worked before, now fails). Follow-up to #86043, which was closed as "already implemented in v2026.5.22+" but the same failure class reproduces on v2026.5.26 with a different provider pair.

Beta release blocker

No

Summary

After #86043 was closed (2026-05-27) with the resolution "current main and v2026.5.22 already sanitize foreign reasoning fields before Gemini submission", the same Base64 decoding failed for "reasoning_X" 400 error still reproduces on v2026.5.26 — only the source field name changes. Original issue: reasoning_content from DeepSeek. This re-report: reasoning_details from OpenAI/Codex (gpt-5.5).

Suggests the v2026.5.22 fix sanitizes the DeepSeek-specific reasoning_content field but not the OpenAI/Codex-specific reasoning_details field when crossing into Google Gemini. The fix is field-specific, not class-wide.

Steps to reproduce

1. Run OpenClaw 2026.5.26 with primary openai/gpt-5.5 (Codex plugin, reasoning enabled) and fallback chain that includes google/gemini-2.5-flash-lite.
2. Drive a Telegram or WhatsApp session through enough turns that gpt-5.5 produces reasoning content stored in session history (≥10 messages with reasoning).
3. Trigger a fallback to gemini-2.5-flash-lite (e.g., let gpt-5.5 time out, or switch primary).
4. Observe: Gemini returns 400 INVALID_ARGUMENT on contents[N].parts[1].thought_signature with detail Base64 decoding failed for "reasoning_details".

Expected behavior

The session-history serializer should strip or transform OpenAI/Codex-style reasoning_details fields when targeting Google Gemini, just as it now (per #86043 closure) strips DeepSeek's reasoning_content. Sanitization should be class-wide (any foreign reasoning artifact) rather than field-specific.

Actual behavior

Gemini API returns 400, the embedded run errors, and — secondary observation — the model-fallback chain does not advance past gemini-lite (fallback[0]) to fallback[1] (openrouter/moonshotai/kimi-k2.5). User sees an error reply.

OpenClaw version

2026.5.26 (10ad3aa)

Operating system

macOS (Darwin 24.6.0, arm64)

Install method

npm global (Homebrew node)

Model

Primary at time of failure: openai/gpt-5.5 (Codex). Failing fallback target: google/gemini-2.5-flash-lite. (Post-migration in same session, primary is now kimi/kimi-code but the 2026-05-27 21:00 repro still hit gemini-lite as fallback[0].)

Provider / routing chain

openclaw → openai-codex (Codex plugin, gpt-5.5) → fallback decision → google-gemini-cli (gemini-2.5-flash-lite)

Logs, screenshots, and evidence

Three repros on 2026-05-27 from `~/Library/Logs/openclaw/gateway.err.log`:

``` 2026-05-27T20:36:21.409-07:00 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai/gpt-5.5 candidate=openai/gpt-5.5 reason=timeout next=google/gemini-2.5-flash-lite detail=LLM request timed out. 2026-05-27T20:36:29.719-07:00 [agent/embedded] embedded run agent end: runId=e41241d4-51eb-468d-9b0a-f4207f77eb7f isError=true model=gemini-2.5-flash-lite provider=google error=Google Generative AI API error (400): Invalid value at 'contents[11].parts[1].thought_signature' (TYPE_BYTES), Base64 decoding failed for "reasoning_details" [code=INVALID_ARGUMENT] 2026-05-27T20:36:30.004-07:00 [model-fallback/decision] model fallback decision: decision=candidate_succeeded requested=openai/gpt-5.5 candidate=google/gemini-2.5-flash-lite reason=unknown next=none

2026-05-27T20:57:27.037-07:00 [agent/embedded] embedded run agent end: runId=b7666b10-1840-4387-a7bf-854b0fcdd509 isError=true model=gemini-2.5-flash-lite provider=google error=Google Generative AI API error (400): Invalid value at 'contents[11].parts[1].thought_signature' (TYPE_BYTES), Base64 decoding failed for "reasoning_details" [code=INVALID_ARGUMENT]

2026-05-27T21:00:41.465-07:00 [agent/embedded] embedded run agent end: runId=d478d785-ce86-455a-b3f5-9a5430d2ecaa isError=true model=gemini-2.5-flash-lite provider=google error=Google Generative AI API error (400): Invalid value at 'contents[11].parts[1].thought_signature' (TYPE_BYTES), Base64 decoding failed for "reasoning_details" [code=INVALID_ARGUMENT] ```

Notable: the 20:36 fallback decision logs `candidate_succeeded next=none` after gemini-lite returned the 400, which may indicate the classifier ignores INVALID_ARGUMENT errors when deciding whether to continue the fallback chain. (This may be a separate bug related to #86043's "secondary 429 retry loop" observation.)

The bad part is consistently at `contents[11].parts[1]` — the 11th-turn assistant message — suggesting the Codex reasoning artifact survives history serialization once the turn count grows past the trim/compaction threshold.

Impact and severity

Affected: Users running a mixed-provider fallback chain with `openai/gpt-5.5` (Codex) primary and `google/gemini-2.5-flash-lite` (or any Gemini model) anywhere in the chain. Severity: Medium — gemini-lite (fallback[0]) becomes unusable as a fallback for Codex sessions, forcing chain to fail silently (see secondary observation above) or skip the slot if fallback advance worked. Frequency: 3 occurrences observed in a single ~25-minute window on 2026-05-27 in a single TG session.

Additional information

• Reference: closes-as-implemented #86043 (DeepSeek case). The fix landed in `extensions/google/transport-stream.ts:561`, `src/agents/transport-message-transform.ts:71`, `extensions/google/provider-hooks.ts:10` per clawsweeper's review. Worth checking whether the route-aware sanitizer recognizes OpenAI/Codex `reasoning_details` as a foreign reasoning field that should be stripped before Gemini submission.
• Suggested fix shape: instead of field-name-specific stripping (`reasoning_content`), strip any non-Gemini reasoning artifact (`reasoning_details`, `reasoning_content`, future names) when target provider is Google. A whitelist of Gemini-valid fields would be more robust than a blacklist of known-bad source fields.
• Workaround in our setup: we just reordered the fallback chain to put `openrouter/moonshotai/kimi-k2.5` ahead of `google/gemini-2.5-flash-lite` so the gemini-lite failure happens later in the chain and is less likely to block users.