Bug Tool calls fail when assistant content is null

[picpicpic]

Description

I am encountering an issue in OpenCode v2 (version 2.0.18) where tool calls trigger a validation error from the provider.
This behavior is not present in OpenCode v1 with the same provider.

Plugins

none

OpenCode version

2.0.18

Steps to reproduce

1. Use a custom provider
2. Trigger any tool call
   For example, I use the following prompt to reproduce: use the shell tool to call 'echo dummystring'
3. The request sent to the provider contains "content": null for the assistant message that initiates the tool call

Actual behavior:
The provider returns a ValidationError because it expects a string or an array for the content field, but receives null.

Failing request

{ "model": "gemma-4-31b-it", "messages": [ { "role": "assistant", "content": null, "tool_calls": [...] } ] }

Error response

{ "errors": [{ "errorMessage": "Request doesn't match the schema", "message": "Invalid input: expected string, received null" }] }

Expected behavior:
The content field should be an empty string "" instead of null when a tool call is made without accompanying text.

Workaround / Proof of concept:
I created a small plugin that intercepts the request and replaces "content": null with "content": "".
With this change, the tool calls work perfectly.

Fixed request which is working

{ "model": "gemma-4-31b-it", "messages": [ { "role": "assistant", "content": "", "tool_calls": [...] } ] }

Screenshot and/or share link

No response

Operating System

macOS

Terminal

Kitty, VSCode terminal, MacOS Terminal

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• relay: opencode/deepseek-v4-flash-free sends assistant message with missing content key (DeepSeek HTTP 400) #41165: DeepSeek via the OpenCode relay rejects assistant messages when content is missing or null; its report notes that content: "" is accepted.

[picpicpic]

This is not a duplicate of #41165, even though the symptoms look similar.

#41165 was fixed by #41210 ("fix(ai): align chat assistant content"), which is indeed included in 2.0.18.
However, #41210 only covers the case where an assistant message has neither text nor tool calls.
The current code in packages/ai/src/protocols/openai-chat.ts (line 484) is:

content: content.length > 0 ? content.map((part) => part.text).join("") : toolCalls.length > 0 ? null : "",

So after that PR:

• text present → concatenated text
• no text, no tool calls → "" (this is what fix(ai): align chat assistant content #41210 fixed)
• no text, tool calls present → still null (unchanged, and this is my case)

[Hotragn]

The null is deliberate rather than accidental, which is worth knowing before anyone patches it. On v2, packages/ai/src/protocols/openai-chat.ts:484:

content: content.length > 0 ? content.map((part) => part.text).join("") : toolCalls.length > 0 ? null : "",

So the three cases are explicit: text present → the joined text; no text but tool calls → null; neither → "". The schema agrees — content: Schema.NullOr(Schema.String) on the assistant message (:149).

That matches the OpenAI Chat Completions spec, where an assistant message carrying tool_calls may have content: null, so the request isn't malformed — the provider here is stricter than the spec. Which makes "send "" instead" a behaviour change for every OpenAI-compatible provider, not just the strict ones, and some do distinguish an explicit null from an empty string when replaying assistant turns.

The file already handles this class of divergence per-provider rather than globally — the Kimi reasoning_content branch a few lines above (:470) is the closest example, and there's similar handling for Moonshot, Gemini and Alibaba elsewhere. A narrow option along those lines looks like the shape that fits, but which providers should opt in isn't something I can determine from outside.

@picpicpic — it would help to know which server you're running (the model name gemma-4-31b-it suggests a self-hosted gateway), since that identifies whether this needs a provider flag or a broader default change.

[picpicpic]

Hi @Hotragn
Thank you for all this information.
I reached out to our internal provider, but unfortunately I don't have any technical details about the server being used...
They just wanted to let me know that a new version would be available soon.
I will retest it at that point.