[FEATURE] Desktop file pane: clicking a PDF dead-ends instead of routing to the Browser pane

Summary

Clicking a .pdf file in the desktop file pane (the file browser in the right-hand side pane) dead-ends with:

Inline preview isn't available for this file.

The same PDF renders correctly when its path is clicked in chat, which routes it to the Browser pane. So the renderer exists and works — only the file-pane click routing is missing. The result is that the same file, in the same app, behaves differently depending on which surface you reached it from, and the file browser (the surface most users would naturally reach for when browsing files) is the one that fails.

This is the same class of problem as #82976, where clicking a local .html path routes to the file/source viewer instead of the Browser pane. That issue is the inverse direction of the same routing gap.

Steps to reproduce

1. Open a project containing a PDF in the Claude Code desktop app.
2. Open the file pane and navigate the file tree to any .pdf file.
3. Click the file.

Actual: The pane shows "Inline preview isn't available for this file." There is no way to get from here to a rendered view.

Expected: One of the following:

• Preferred — the file pane forwards previewable binary types (PDF, images, video) to the Browser pane, matching what a chat path click already does. The desktop docs already describe the Browser pane as the destination for these types, so this would make the file tree consistent with the documented behavior.
• Minimum — the message becomes actionable, with an "Open in Browser pane" button. The app already knows the file is a PDF and already has somewhere to render it; surfacing that as a one-click action is a much smaller change than building any new preview capability.

Why this matters

The current message is technically accurate but is a dead end: it reports a limitation without offering the action that resolves it. Users browsing a project's files have no in-app path forward and have to know, out of band, that the fix is to get the path into chat or open the Browser pane manually.

For document-oriented projects this is a routine operation rather than an edge case. In my case the repository is a LaTeX manuscript where the build outputs and the review correspondence are all PDFs, and browsing to them in the file tree is the obvious gesture.

Environment

| | |
|---|---|
| Claude Code | 2.1.207 |
| Platform | Linux (Ubuntu 26.04 LTS, kernel 7.0.0-30-generic) |
| Surface | Desktop app, file pane / file browser |
| File types affected | .pdf (reported previously for images and Office formats as well) |

Prior art

• #53519 — "Desktop file panel: show hidden files, resolve symlinks, and handle binary files gracefully" requested exactly this. It attracted corroboration from other users (one describing it as a remaining blocker for migrating from VS Code, another reporting the same dead end for .xlsx/.docx/.pptx on Windows), but was auto-closed as stale by inactivity automation in June 2026 and subsequently locked. The raw-bytes symptom it reported was fixed — the panel now shows the polite message instead of binary garbage — but the underlying routing gap was never closed. Filing fresh per the automation's own closing instruction.
• #82976 — same routing class, .html in the opposite direction. Open.
• #83764 — related but distinct: the inline PDF preview serves stale cached content after a file is regenerated at the same path. Also open, and compounding, since the workaround for this issue (route the PDF into the Browser pane) lands on a preview that may not reflect the current build.