feat: handle MCP binary content (PDF, audio, Office docs) saved to disk by tools #211

New Issue

2026-03-10T09:16:10-07:00

hikari commented

2026-03-10 09:16:10 -07:00

Summary

CLI v2.1.69 improved MCP binary content handling — tools returning PDFs, Office documents, or audio now save decoded bytes to disk with the correct file extension instead of dumping raw base64 into the conversation context. WebFetch also saves binary responses alongside its summary.

This means tool results in the NDJSON stream may now contain file paths to locally-saved binary files rather than raw base64 content. Hikari's terminal and file browser need to handle these gracefully.

Required Changes

Frontend (Terminal)

Detect when a tool result references a local file path (binary content saved to disk)
Render a clickable file link rather than attempting to display raw content
For recognised types (PDF, images, audio), show an appropriate icon

Frontend (File Browser / Editor Panel)

Ensure the editor panel can open/preview the saved binary files where possible
PDFs: consider opening in the system viewer via Tauri's opener plugin
Audio: consider a simple playback UI

Backend

Ensure the file path in tool results is correctly parsed and forwarded in the claude:output event payload

Reference

CLI v2.1.69: "Improved MCP binary content handling — tools returning PDFs, Office documents, or audio now save decoded bytes to disk with the correct file extension instead of dumping raw base64 into the conversation context. WebFetch also saves binary responses alongside its summary"

✨ This issue was created with help from Hikari~ 🌸

## Summary CLI v2.1.69 improved MCP binary content handling — tools returning PDFs, Office documents, or audio now save decoded bytes to disk with the correct file extension instead of dumping raw base64 into the conversation context. `WebFetch` also saves binary responses alongside its summary. This means tool results in the NDJSON stream may now contain file paths to locally-saved binary files rather than raw base64 content. Hikari's terminal and file browser need to handle these gracefully. ## Required Changes ### Frontend (Terminal) - Detect when a tool result references a local file path (binary content saved to disk) - Render a clickable file link rather than attempting to display raw content - For recognised types (PDF, images, audio), show an appropriate icon ### Frontend (File Browser / Editor Panel) - Ensure the editor panel can open/preview the saved binary files where possible - PDFs: consider opening in the system viewer via Tauri's `opener` plugin - Audio: consider a simple playback UI ### Backend - Ensure the file path in tool results is correctly parsed and forwarded in the `claude:output` event payload ## Reference - CLI v2.1.69: "Improved MCP binary content handling — tools returning PDFs, Office documents, or audio now save decoded bytes to disk with the correct file extension instead of dumping raw base64 into the conversation context. WebFetch also saves binary responses alongside its summary" ✨ This issue was created with help from Hikari~ 🌸

hikari referenced this issue from a commit

2026-03-11 18:58:40 -07:00

feat: linkify MCP binary file paths in markdown output

hikari referenced this issue

2026-03-11 19:11:55 -07:00

feat: convert WSL Linux paths to Windows UNC paths when opening binary files #215

hikari referenced a pull request that will close this issue

2026-03-13 00:38:12 -07:00

feat: CLI v2.1.68–v2.1.74 compatibility updates #221

naomi closed this issue

2026-03-13 01:34:45 -07:00

naomi referenced this issue from a commit