[FEATURE] Preview pane (PDF/image/HTML) in remote-control sessions
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Problem Statement
The preview pane in Claude Code Desktop can render PDFs, images, and static HTML files in local and SSH sessions. However, in remote-control sessions (claude remote-control), clicking a file path in the chat does not open the preview pane — the file simply isn't displayed. This is because remote-control only streams chat messages and tool results through the Anthropic API bridge, with no channel for binary file content.
Why this matters
Remote-control is the only session type that offers persistence — the session survives disconnects and can be reconnected from any device. SSH sessions from the desktop app support file preview but die when the connection drops. This forces users to choose between persistence and visual feedback, which is a painful tradeoff for workflows that involve iterating on visual outputs (plots, figures, generated documents) on remote machines.
Reproduction
- On a remote machine:
claude remote-control --name my-session - Connect from Claude Desktop or claude.ai/code
- Ask Claude to create or read a PDF/image file
- Click the file path in the chat → nothing happens (no preview pane)
- Compare: the same file path in an SSH session opens in the preview pane
Environment
- Claude Code CLI: latest
- Platform: Linux (Ubuntu 24.04, remote) → macOS (Desktop app, client)
- Session type: remote-control
Proposed Solution
Expected behavior
File paths for supported types (PDF, PNG, HTML, etc.) should open in the preview pane in remote-control sessions, just as they do in SSH sessions.
Possible approach
SSH sessions already stream file content for the file pane and preview pane. A similar mechanism could be added to the remote-control protocol — when the client requests a file for preview, the local CLI process reads it and sends it back through the existing encrypted bridge. This could be limited to supported preview types and capped in size to keep things lightweight.
Alternative Solutions
_No response_
Priority
High - Significant impact on productivity
Feature Category
CLI commands and flags
Use Case Example
_No response_
Additional Context
_No response_
5 Comments
Ref. https://github.com/anthropics/claude-code/issues/48466#issuecomment-4528195066
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Adding a concrete, recurring use case and a request to reconsider this.
I run Claude Code sessions on a work laptop and drive them remotely (claude.ai/code + the mobile app) from home via Remote Control. A very common task — building or reviewing a UI mockup — needs an interactive preview, but the dev server binds to
localhoston the execution machine (the laptop), which the remote viewer's browser has no route to. So the preview pane shows nothing remotely (per #48466).The practical effect is that Remote Control forces a choice between persistence/mobility and visual feedback: for anything visual, the only remote-viewable path is to push a branch and wait on a hosted preview deploy (Cloudflare/Vercel/etc.) for every iteration — which is far too slow for interactive UI work where you want to see each change immediately.
Even a one-way stream of the preview pane (HTML/image/PDF rendered on the execution machine, pushed through the existing encrypted bridge — the way SSH sessions already surface previews) would close most of the gap; full local-port forwarding would close all of it. This is a real pain for anyone doing UI/mockup work in remote sessions, and "not planned" feels off for a workflow the feature otherwise enables well. Please consider reopening.
+1 for this feature - even a non interactive preview would be hugely beneficial. especially when using Claude Code as a science focused IDE.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.