Summary
Calling Command Code GOAT Provider API with z-ai/glm-5.3-flash fails immediately with HTTP 400 after a Codex client sends image-bearing tool outputs.
This is not a timeout and not quota exhaustion. The request is translated from Codex /v1/responses to Command Code /v1/chat/completions, then rejected.
Expected Behavior
Either:
the image tool outputs are accepted and the model continues, or
the API returns a clear, documented error that image parts are not allowed in tool/function output.
Actual Behavior
Upstream returns HTTP 400 immediately:
{
"error": {
"type": "invalid_request_error",
"message": "Invalid input",
"param": "messages.12.content"
}
}
The failing history includes a function_call_output whose output is an image array, not a string:
[
{
"type": "input_image",
"image_url": "data:image/png;base64,...",
"detail": "high"
}
]
Steps to reproduce the issue
Use Codex Desktop against Command Code Provider API via an OpenAI-compatible proxy.
Select z-ai/glm-5.3-flash (client alias glm-5.3-flash-goat).
Ask Codex to inspect 3 local PNG files with view_image in parallel.
Continue the same turn / send the next model request that includes those tool outputs in history.
Command Code Version
0.0.1
Operating System
Windows
Terminal/IDE
codex
Shell
No response
Session file (optional)
No response
Fix prompt (optional)
No response
Additional context
Does z-ai/glm-5.3-flash accept image arrays inside tool/function outputs?
If not, what is the supported image format for Provider API when the client is Codex-style /v1/responses?
Is this a GLM upstream limit, or a /v1/responses → /v1/chat/completions conversion/schema issue in the gateway?
If tool output must be a plain string in Chat Completions, should the documented guidance be: convert input_image tool results to text such as [3 images viewed], or move images into a user message image_url part?
Summary
Calling Command Code GOAT Provider API with z-ai/glm-5.3-flash fails immediately with HTTP 400 after a Codex client sends image-bearing tool outputs.
This is not a timeout and not quota exhaustion. The request is translated from Codex /v1/responses to Command Code /v1/chat/completions, then rejected.
Expected Behavior
Either:
the image tool outputs are accepted and the model continues, or
the API returns a clear, documented error that image parts are not allowed in tool/function output.
Actual Behavior
Upstream returns HTTP 400 immediately:
{
"error": {
"type": "invalid_request_error",
"message": "Invalid input",
"param": "messages.12.content"
}
}
The failing history includes a function_call_output whose output is an image array, not a string:
[
{
"type": "input_image",
"image_url": "data:image/png;base64,...",
"detail": "high"
}
]
Steps to reproduce the issue
Use Codex Desktop against Command Code Provider API via an OpenAI-compatible proxy.
Select z-ai/glm-5.3-flash (client alias glm-5.3-flash-goat).
Ask Codex to inspect 3 local PNG files with view_image in parallel.
Continue the same turn / send the next model request that includes those tool outputs in history.
Command Code Version
0.0.1
Operating System
Windows
Terminal/IDE
codex
Shell
No response
Session file (optional)
No response
Fix prompt (optional)
No response
Additional context
Does z-ai/glm-5.3-flash accept image arrays inside tool/function outputs?
If not, what is the supported image format for Provider API when the client is Codex-style /v1/responses?
Is this a GLM upstream limit, or a /v1/responses → /v1/chat/completions conversion/schema issue in the gateway?
If tool output must be a plain string in Chat Completions, should the documented guidance be: convert input_image tool results to text such as [3 images viewed], or move images into a user message image_url part?