[AndrianBalanescu]

Problem

opencode-go backed providers (ollama-cloud, opencode-go, opencode, opencode-zen) use a Go ChatCompletionRequest struct where the reasoning field is typed as openai.Reasoning (a structured type, not a bool).

When a client sends reasoning: true or reasoning: false — which is valid per the OpenAI API for enabling/disabling reasoning — the Go JSON decoder rejects it with:

400: json: cannot unmarshal bool into Go struct field
ChatCompletionRequest.reasoning of type openai.Reasoning

Evidence

Observed in production with ollama-cloud/glm-5.2 — 3 consecutive 400 errors in a 30-second window, each with the unmarshal error above.

Fix

Add opencodeReasoningSanitizer.ts — strips the boolean reasoning field from the request body before forwarding to opencode-go backed providers. This mirrors the existing pattern in mimoThinking.ts where Xiaomi MiMo gets similar reasoning field normalization.

• Boolean reasoning: true/false → stripped (lets upstream apply default behavior)
• Object reasoning: {effort: "high"} → forwarded as-is (matches Go struct)
• String reasoning: "high" → forwarded as-is
• No reasoning field → no change

Testing

13 unit tests covering: provider detection, boolean stripping (true/false), object/string preservation, reference identity, immutability, and field preservation.

[gemini-code-assist]

Code Review

This pull request introduces a sanitizer service (opencodeReasoningSanitizer.ts) and corresponding unit tests to strip boolean reasoning fields from request bodies for opencode-go backed providers, preventing 400 unmarshaling errors on the Go backend. The reviewer suggested adding a defensive check in stripBooleanReasoning to ensure the body parameter is a non-null object before using the in operator, avoiding potential runtime errors.

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.

[gemini-code-assist]

To prevent potential runtime exceptions (such as TypeError: Cannot use 'in' operator to search for 'reasoning' in null), we should add a defensive check to ensure body is a non-null object before performing the in operator check.

Suggested change

	export function stripBooleanReasoning(body: JsonRecord): JsonRecord {
	if (!("reasoning" in body)) return body;
	export function stripBooleanReasoning(body: JsonRecord): JsonRecord {
	if (!body || typeof body !== "object") return body;
	if (!("reasoning" in body)) return body;

References

1. Enforce defensive programming by ensuring appropriate null/undefined checks exist before object property accesses or operators like 'in'.

[AndrianBalanescu]

Closing — the reasoning sanitizer logic is already inlined in ComboService on release/v3.8.49, so this extraction approach is no longer needed. The test coverage can be added separately if useful.

[diegosouzapw]

Merged — thanks @AndrianBalanescu! Stripping the bare boolean reasoning field before forwarding to opencode-go providers is the right fix (their Go struct types it as a structured object). We rebuilt the branch clean on the current tip (it carried old-main auto-sync drift) — applied only your 2 real commits (the sanitizer + guard + test), your code and authorship intact. Real CI green.