Zen /v1/responses (glm-5.3-flash): 422 "Input should be a valid string" when a tool output contains an image — bricks Codex screenshot/browser sessions

Summary

Through the Zen Go plan /v1/responses endpoint with glm-5.3-flash, any Codex session in which the browser/computer-use plugin returns a screenshot as a tool output (function_call_output whose output is an array containing input_image) fails with HTTP 422 on every subsequent request:

{"error":{"param":"messages.14.user.content.str","type":"invalid_request_error","message":"Error from provider (Console Go): Upstream request failed: [invalid_request_error] Input should be a valid string"}}

The image itself is fine — the model demonstrably has working vision through this endpoint when the image arrives in a user message. This looks like a Responses→Chat conversion bug: the image-bearing tool output gets mapped to a message branch that requires content to be a plain string.

Environment

• Client: OpenAI Codex CLI 0.151.0 / Codex desktop, wire_api = "responses", disable_response_storage = true (full history re-sent every turn)
• Provider: Zen Go plan, base …/zen/go/v1, model glm-5.3-flash (catalog: input_modalities: ["text", "image"])
• Via cc-switch local proxy; observed 2026-09-13

Evidence

A. Real session (21 input items, browser task). Six function_call_output items; five are plain-text arrays and pass; the single one containing [{"type":"input_text",…},{"type":"input_image","image_url":"data:image/jpeg;base64,…"}] (a ~7 KB Chrome-tab screenshot) is rejected as messages.14.user.content.str. 7 consecutive retries → identical 422 (plus one 504). The session is unusable from that point on.

B. Same session, image replaced by a text placeholder → HTTP 200, complete history (~66k tokens) processed and the model continues the task normally. So the poisoned item is exactly the image-in-tool-output.

C. Vision works through this channel when the image is in a user message:

• Minimal probe: user message + valid 8×8 red PNG → 200, model answers “红色” (red) correctly.
• Full 90k-token session context with the same image appended to the last user message → 200, correct color answer + task continues.

D. Minimal 3-item probe (user message → paired function_call → function_call_output with text+image array) → 200 and the model describes the screenshot correctly.

So the failure is not image support per se, and not the paired-output shape alone — it appears in longer multi-turn sequences (multiple prior tool outputs / reasoning items), pointing at message-branch selection in the Responses→Chat converter (or Console Go's validation) for image-bearing tool outputs.

Impact

Every Codex session using browser/computer-use plugins bricks after the first screenshot; all retries 422 with no recovery path short of editing the client-side session file.

Related issues

• #32821 — GLM-5.2 via OpenCode Go: same "content should be a valid string" family (auto-closed after 60 days, root cause not addressed)
• #41766 — Zen /v1/responses drops array-format assistant content
• #31870 — pasted images break multi-turn chat (image_url array vs string)

Request

Please make the Responses→Chat conversion map input_image parts inside function_call_output to a vision-capable message (or at least fail with a descriptive error) instead of the string-content branch. Happy to provide the full captured session payloads (sanitized) if useful.