provider: PDF attachment bricks session on GLM models (upstream json_parse_error at messages[N]) #53809

Activity

1. github-actions

   assigned

   nexxeln

   on Oct 7, 2026
2. opencode-agent commented on Oct 7, 2026

   

   opencode-agentBot

   on Oct 7, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I reproduced the OpenCode side of this on v2.0.24 and on the latest v2 branch (8587f817), using a simulated model. After read opens a PDF, the tool result is just PDF read successfully. The PDF goes in a separate user message as an OpenAI Chat file part:

   {"role":"user","content":[{"type":"file","file":{"filename":"report.pdf","file_data":"data:application/pdf;base64,..."}}]}

   That message is sent again on every later request, including a plain continue. This matches the messages[N] index in your error and why only /compact recovers the session.

   I couldn't confirm the json_parse_error itself, because that comes from the OpenCode Zen gateway and I don't have provider access here. A maintainer with Zen access will need to check whether the gateway accepts this file part for glm-5.3-flash.

   Related issues (closest first):

   • [Bug] 422 "messages.N.user.content.str: Input should be a valid string" when replaying a session containing a PDF tool result on OpenAI-compatible providers (opencode-go / zen gateway) #48868: same gateway and model (opencode-go, glm-5.3-flash) breaking on a PDF from a read result, on v1, with a 422
   • zai: PDF attachments always fail with 400 [1210] — opencode sends file_data, Z.AI accepts PDF only via file_url/file_id #49237 / pdf not readable by Z.AI/GLM 5.3 Flash through OpenCode #49028: Z.AI rejects PDFs sent as file_data
   • bug: tool-result media 400s whole request for models without attachment capability #41163: media in tool results breaks every later request
   • feat(core): recover sessions from rejected attachments #53014: open PR adding a way to recover a session after a provider rejects an attachment

   For now, /compact or a new session works around it, as you found.
3. pipaacebedo commented on Oct 11, 2026

   

   pipaacebedo

   on Oct 11, 2026

   More actions

   Here is a small, non-destructive CLI tool that repairs opencode sessions that get stuck after an agent reads a PDF file while using strict OpenAI-compatible providers (e.g. the opencode-go / zen gateway). Written in pure Python (3.8+, stdlib only).

   Related upstream issue: anomalyco/opencode#48868

   When the read tool runs on a PDF, opencode stores the result in its database with a base64 attachment:

   { "type": "tool", "tool": "read", "state": { "output": "PDF read successfully", "attachments": [{ "type": "file", "mime": "application/pdf", "url": "data:application/pdf;base64,..." }] } }

   On every subsequent turn, the session provider-isolation layer re-injects that media as a synthetic user message whose content is an array of blocks (message-v2.ts:380-399). Strict OpenAI-compatible gateways only accept content: string for user messages, so every request fails with:

   422  messages.N.user.content.str: Input should be a valid string
   400  Upstream request failed: [400] Request validation failed
   

   The session is permanently bricked: every retry replays the same broken history.

   For the affected session (or a single part), it:

   1. Backs up each affected row to fix-backups/part_<id>.json (the full JSON of the part, a few hundred KB — the 6+ GB database file is never copied).
   2. Patches the stored part so state.attachments becomes [] inside a single atomic transaction. The text output ("PDF read successfully"), metadata and tool input are kept untouched. The model already ingested the PDF text while working; only the base64 binary that breaks history replay is discarded.
   3. Verifies the result and prints a summary.

   opencode does not need to be closed: SQLite WAL mode safely supports the concurrent writer. The -wal / -shm files require no special handling.

   Requirements

   • Python 3.8+ (standard library only)
   • Works on Windows, macOS and Linux (arrow-key menu needs an ANSI-capable terminal; Windows Terminal, cmd and most POSIX terminals are fine)

   Usage

   Run the interactive wizard (recommended):

   python fix-opencode-db.py
   

   1. Type a search text (or press Enter for the 40 most recent sessions).
   2. Pick a session with the arrow keys + Enter.
   3. Review the detected parts (tool, file path, size) and confirm with s.
   4. Done — reopen the session in opencode.

   Non-interactive commands (for scripting / automation):

   Command	Description
   python fix-opencode-db.py list [text]	List sessions (date, id, title) matching text; marks [PDF xN]
   python fix-opencode-db.py fix <ses_... | prt_...>	Backup + patch + verify for the whole session or one part
   python fix-opencode-db.py verify <ses_... | prt_...>	Check current state
   python fix-opencode-db.py restore <ses_... | prt_...>	Roll back rows to their exact original state
   --db <path>	Point at a database in a non-default location

   Backups live in fix-backups/ next to the script, with a manifest.json that maps each part id to its session for session-level restores.

   Safety notes

   • Non-destructive by design: one-row transactions, strict JSON validation before
     writing, abort on any mismatch.
   • Always creates a row backup first; restore puts everything back byte-for-byte.
   • The database file itself is never copied, moved or rewritten by bulk operations.
   • Any non-PDF attachments (images) are left untouched.
   • Running fix on a session with no PDF attachments is a safe no-op.

   Troubleshooting

   Symptom	Fix
   Could not find opencode.db	Pass --db "C:\path\to\opencode.db"
   Session still fails after fix	Run verify; if it prints OK, the failure is likely a different issue — report it upstream
   Need to undo	python fix-opencode-db.py restore ses_... (type RESTORE to confirm)

   Root cause (for the curious)

   • packages/opencode/src/tool/read.ts:306-324 — read returns PDFs as base64 attachments.
   • packages/opencode/src/session/message-v2.ts:147-159 — supportsMediaInToolResult() returns false for @ai-sdk/openai-compatible, so media is extracted into a synthetic user message (lines 380-399) with array content.
   • packages/opencode/src/provider/transform.ts:409-445 — unsupportedParts() passes the file block through when the model declares PDF support, and never collapses all-text content arrays back to strings, which the OpenAI-compatible SDK requires.

   Fixes to upstream are discussed in the linked issue.

   Disclaimer

   This tool edits opencode's local SQLite database directly. Use at your own risk.
   It performs strict validation and per-row backups before any change, and no database files are deleted at any point.

   Script

   fix-opencode-db.py
4. amitnarw commented on Oct 14, 2026

   

   amitnarw

   on Oct 14, 2026

   More actions

   Hit this too, on v2.0.28 (latest). Windows 11, ollama-cloud / glm-5.3-flash.
   Read a ~400KB PDF with the read tool, worked fine, model even answered questions about it. From the next message onwards every single request failed with invalid message format (ref: ...) = a different ref each time, so at first I thought it was random. Restart didn't help, session was dead. Even "say hi" wouldn't go through.
   Dug into the session db and found the read tool had stuffed the entire PDF as base64 into the history. Every new message resends that history, GLM chokes on it, session never recovers.
   Fixed it by hand by editing the stored message and swapped the PDF blob with a short text note pointing to the file on disk. Worked again right away, lost nothing except the blob. Same history reads fine on a non-GLM model btw, so it's specifically GLM failing on the PDF part.
   Also: the error text here is different from the json_parse_error in the main report (I'm on ollama-cloud, not the opencode provider), so anyone googling "invalid message format" should find this thread.
5. cep207 commented on Oct 22, 2026

   

   cep207

   on Oct 22, 2026

   More actions

   Same failure mode in OpenCode Desktop, with a plain .txt attachment
   (not a PDF, and not from the read tool) — so this is broader than the
   read-tool/PDF path.

   • Client: OpenCode Desktop v1.18.3, Windows
   • Model: GLM-5.3-Flash through the OpenCode gateway
   • Steps: attach a .txt file to the prompt, send
   • Errors, in order across retries:
     1. Upstream request failed: [400] Failed to deserialize the JSON body into the target type: data did not match any variant of untagged enum ChatCompletionRequestUserMessageContent at line 1 column 1357103
     2. Upstream request failed: [unsupported_content_type] Messages may contain text, images and video; this model does not read audio or files.
   • Every subsequent send in the same session keeps failing with Roadmap & Existing Issues #2.

   Expected: for models without file input support (models.dev), OpenCode
   should either serialize the attachment as text or reject the attachment at
   compose time — not brick the whole session.