[FEATURE] Inline side-panel preview for .docx/.pptx/.xlsx sent via SendUserFile (pipeline already exists in Cowork)

Summary

When Claude Code sends an Office file (.docx, .pptx, .xlsx) to the user via SendUserFile, it renders as a download-only card with no side-panel preview — even with display: "render" passed explicitly. Images, PDFs, SVG, and Markdown all preview inline; Office formats are the gap.

The notable part: the rendering pipeline already exists. Cowork / Claude Desktop previews .docx and .pptx today by converting through LibreOffice into a cached PDF (office-cache/*.pdf) — this is visible in #55508, which is a font bug inside that working preview path. So this isn't "build Office preview from scratch." It's that the existing preview path isn't reachable from SendUserFile in the Claude Code surface.

Reproduction

1. In Claude Code (desktop app, macOS), have a .docx anywhere on the local filesystem.
2. Ask Claude to show it: "pull up the doc so I can preview it on the side."
3. Claude calls SendUserFile({ files: ["/path/to/file.docx"], display: "render" }).
4. Expected: the document renders in the side panel, as a PDF would.

Actual: a download card appears. Opening it requires leaving the app for Word.

Why it matters

The single most common document workflow is "read this and explain it to me." Claude parses the file fine — but the user can't follow along without switching to another application, which defeats the point of the side panel.

The workaround is for Claude to shell out to LibreOffice, convert to PDF, and send that — which:

• produces a throwaway second file cluttering the user's directory,
• loses fidelity on complex layouts (deeply nested tables in particular),
• and duplicates, in a bash call, a conversion the app is already doing internally for its own preview cache.

The layout-fidelity loss lands hardest exactly where side-by-side reading matters most: dense, form-shaped documents.

Concrete case

A Chinese regulatory filing template — a ~250-row .docx of nested tables, one field per row, with highlighted pre-filled cells and □ checkbox glyphs. The user wanted my field-by-field explanation in the transcript next to the actual form so they could see which cells were already populated. That is inherently a two-pane task, and the file could not be displayed at all. The PDF-conversion workaround mangles the nested table structure, so the fallback was materially worse than the original.

Suggested behavior

Route display: "render" on an Office file into the same LibreOffice-backed preview path Cowork already uses, and surface the result in the side panel.

Fidelity priorities for this content type, in order:

1. table structure (including nested tables and merged cells)
2. cell shading / text highlighting
3. checkbox and other symbol glyphs
4. CJK glyph coverage — see #55508; whatever font set the preview converter ships with should cover CJK, since these documents are frequently the ones being explained
5. typography polish (least important)

If full render isn't in scope near-term, a first-page thumbnail on the download card would still be a large improvement over a bare filename.

Environment

• macOS Darwin 24.3.0 (Apple Silicon)
• Claude Code in the desktop app
• File type: .docx (expected to apply equally to .pptx / .xlsx)

Related

• #55508 — font regression within the existing Cowork docx/pptx preview pipeline; confirms that pipeline exists and is LibreOffice-based