[FEATURE] File preview pane should use the existing read_file control request in Remote Control (bridge) 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

Clicking a file path in a Remote Control session (Claude Desktop or claude.ai) opens the
preview pane, which immediately shows:

Couldn't read this file — It may have been deleted or moved, or it lives outside the working directory.

The conversation itself works fine. This makes Remote Control the only session type with
no visual feedback for generated files (plots, docs, reports) — my agents run on a remote
VPS via claude remote-control, produce markdown briefs/reports in the workspace, and I
cannot open any of them from the chat that references them.

Previously reported in #48466 and #62011 (both closed as not planned). I'm filing this as
a smaller, more concrete ask because the protocol side now exists — only the client
call appears to be missing. What we verified with --debug-file, on CLI 2.1.204
(Linux, remote self-hosted bridge worker) and 2.1.207 (macOS, worker on the *same
machine* as Claude Desktop, local repo, file present at the exact path):

1. The inbound control channel works end-to-end. Observed successful round-trips over

the worker/session SSE channel: initialize, can_use_tool (full permission dialog
from Desktop), get_context_usage.

1. A preview click sends nothing. After clicking file links (relative and absolute;

Desktop main window and claude.ai in Chrome), the worker and child debug logs show
zero incoming requests — no read_file, no file_suggestions, only heartbeats.
The pane fails client-side without ever contacting the worker.

1. It fails even fully locally: same machine, file exists, still the same error — so

the pane is not reading the local disk for RC sessions either.

1. The CLI-side read_file handler works. Feeding

{"type":"control_request","request_id":"x","request":{"subtype":"read_file","path":"README.md","max_bytes":4096}}
into the stream-json REPL returns the file content, with relative paths resolved
against the session cwd.

Repro: claude remote-control --debug-file /tmp/rc.log --verbose, click a file link in
the chat, grep the log for read_file / control_request.

Proposed Solution

When the preview pane opens for a bridge (Remote Control) session, issue a read_file
control request to the worker — size-capped, cwd-contained (the CLI handler already
enforces resolution against the working directory) — and render the returned content,
instead of failing locally.

Ideal UX: clicking report.md in the chat opens the pane and shows the rendered file,
exactly as it does for local/SSH sessions today. Text/markdown alone would already cover
most "look at what you generated" workflows; binary types (PDF/images) could stay
unsupported initially.

Environment: CLI 2.1.204 (Linux/Docker worker) and 2.1.207 (macOS 15); Claude Desktop
(macOS, current as of 2026-07-13) and claude.ai (Chrome). Related: #48466, #62011 —
same symptom, closed before the read_file control request existed.

Alternative Solutions

• Asking the agent to paste file contents into the chat — works but floods the

conversation and loses formatting/anchors.

• SSH sessions instead of Remote Control — preview works there, but sessions don't

persist across disconnects, which is the whole reason we use Remote Control.

Priority

High - Significant impact on productivity

Feature Category

File operations

Use Case Example

_No response_

Additional Context

Technical note: the plumbing appears complete on the CLI side — the read_file
control_request handler exists and works (verified by direct injection into the
stream-json REPL on 2.1.204 and 2.1.207), and the inbound control channel to the worker
demonstrably delivers other control_requests (initialize, can_use_tool,
get_context_usage) — so this looks like a client-side gap only: the preview pane never
issues any request for Remote Control sessions (verified with --debug-file on both
ends; zero incoming requests after preview clicks, only heartbeats).

Environment: CLI 2.1.204 (Linux/Docker worker) and 2.1.207 (macOS 15); Claude Desktop
(macOS, current as of 2026-07-13) and claude.ai (Chrome).

Related: #48466, #62011 — same symptom, closed as not planned before the read_file
control request existed.