[Bug]: read_file on Office/audio/video files poisons checkpointed history with content blocks the Anthropic API rejects — run permanently wedges

[kyh]

Description

During an --init run on a large monorepo, a research subagent called read_file on a binary file. The file content was serialized into the subagent's message history as a document-style content block whose media_type is not application/pdf. The Anthropic Messages API rejects any subsequent request containing that history:

400 invalid_request_error:
messages.N.content.0.tool_result.content.0.document.source.base64.media_type:
Input should be 'application/pdf'

Because the poisoned tool_result is already persisted in the LangGraph checkpoint, every retry — and every resumed run — replays the identical invalid request. The branch can never succeed.

This is related to but distinct from #284: that fix (deepagents ≥1.10.6 falling back to text/plain for unknown extensions) does not cover known non-text extensions.

Still present in latest (openwiki 0.1.2 / deepagents 1.10.8)

In deepagents 1.10.8 (dist/langsmith-DjCMSywL.js), read_file on a binary file still returns:

• type: "file" with e.g. application/vnd.openxmlformats-officedocument.presentationml.presentation for .pptx/.ppt — Anthropic document blocks only accept application/pdf → 400
• type: "audio" / type: "video" blocks — not supported by the Anthropic Messages API at all → 400

So any repo containing a .pptx, .ppt, or audio/video file that a subagent decides to read can still permanently wedge an init/update run when using the Anthropic provider.

Consequence: whole run dies, not just the branch

The failing subagent task doesn't fail gracefully. Observed sequence in the checkpoint __error__ channel:

1. 400 invalid_request_error (repeats on retry)
2. AbortError: This operation was aborted (sibling tasks aborted)
3. TypeError: terminated — process exits

Re-running --init resumes the thread, makes progress on healthy branches for a few minutes, then hits the same 400 and dies again. Hours of research checkpoints become unusable without manual DB surgery.

Steps to Reproduce

1. openwiki --init (Anthropic provider) in a repo containing a .pptx (or other Office/audio/video) file located somewhere a research subagent will explore.
2. A subagent reads the file; the next model call in that branch returns the 400 above.
3. The run eventually dies with TypeError: terminated.
4. Re-running openwiki --init resumes from the checkpoint and hits the same 400 — permanently wedged.

Workaround that confirmed the diagnosis

Deleting the poisoned subagent's rows from checkpoints/writes in ~/.openwiki/openwiki.sqlite (its checkpoint_ns = tools:<uuid>) and re-running let the run resume and re-execute that subagent cleanly.

Suggested fixes

1. For the Anthropic provider, only emit base64 document blocks for application/pdf and image blocks for supported image types; return a text placeholder (<binary file, N bytes, skipped>) for everything else (Office docs, audio, video).
2. Validate/sanitize tool_result content before it enters checkpointed history — a malformed block is unrecoverable once persisted, since retries replay it.
3. Isolate subagent failure: a task failing with a non-retryable 4xx should fail its branch with an error ToolMessage to the parent instead of aborting siblings and killing the run.

Environment

• openwiki 0.0.1 (bug reproduced), block-construction paths verified unchanged in 0.1.2 / deepagents 1.10.8
• provider: anthropic, model: claude-sonnet-5
• macOS, node 25.9.0

[Henildiyora]

Hi Kaiyu Hsu (@kyh), thanks for the detailed writeup — the repro steps and root-cause analysis made this really easy to follow.

I'd like to work on this if it's not already being picked up. I'm planning to start with the first suggested fix (placeholder text for unsupported binary types in the Anthropic provider path, extending the pattern from #284) as the core fix, and can follow up on the other two suggestions after.

Happy to be assigned — I'll ask any specific questions once I start digging in.