[BUG] File preview pane reports "deleted or moved / outside the working directory" for reads it never attempted

Status Fixed / completed
Reported on v2.1.220
Maintainer reply None cached
Activity 1 comment · opened Jul 28, 2026 · closed Aug 26, 2026

What's Wrong?

In Remote Control (bridge) sessions, clicking a file link 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.

Neither clause is true in this condition. The file exists, is readable, and is inside the
session's working directory. The pane never attempts a read at all — it fails client-side
before any I/O.

The defect is that the pane reports a file-state problem for what is actually an
unattempted read. It does not distinguish "I looked and it wasn't there" from "I never
looked," and it renders the same string for both — where one is true and the other misleading.

This is narrowly about the diagnostic message. It is not a request to implement the
read — that is #77203, and I am deliberately not restating it here. I am filing separately
because the message is wrong independently of whether the read is ever implemented, and
because the two predecessor requests for that feature (#48466, #62011) were both closed as
not planned. If #77203 is also declined, this string stays misleading indefinitely, and
it is a much smaller fix.

To be precise about scope: the message is correct when a file link resolves to a path
that genuinely does not exist (e.g. a relative link resolved against the wrong root). The
bug is its use as a fallback for the unattempted-read case.

Why it costs users time: the message names three specific, plausible causes — deletion,
relocation, and working-directory scope — all of which point at the user's filesystem. I
lost a substantial amount of time chasing exactly those: verifying file existence and
permissions, checking recorded session cwd, and ruling out symlink canonicalization on a
distro where /home is a symlink to /var/home. None were relevant. The failure was
decided client-side before any read, which no part of the message suggests.

What Should Happen?

The pane should distinguish the two conditions:

  • Read attempted, file genuinely missing or out of scope → the current message is fine.
  • Read not attempted because the surface cannot reach the file → say that, e.g.

"Preview isn't available for Remote Control sessions" or "This view can't reach files on
the session's machine."

The second form is accurate, points the user away from a filesystem hunt, and remains
correct whether or not #77203 is implemented.

Error Messages/Logs

Verbatim, from the preview pane:

Couldn't read this file
It may have been deleted or moved, or it lives outside the working directory.
/var/home/claude/projects/CulinaryOS/docs/STATE_OF_PLAY.md

The path shown is correct and the file is present:

-rw-r--r--. 1 claude claude 12858 Jul 28 10:05 /var/home/claude/projects/CulinaryOS/docs/STATE_OF_PLAY.md

Evidence that no read is attempted (two independent measurements, from opposite ends):

  • Client side (mine): on claude.ai in Chrome, patching fetch,

WebSocket.prototype.send, and incoming message events, then clicking a file link,
captures zero read traffic — no HTTP request, no WebSocket frame. Only routine
presence/session polling and telemetry.

  • Worker side (#77203): claude remote-control --debug-file shows zero incoming

read_file / control_request entries after preview clicks, only heartbeats.

Steps to Reproduce

  1. Run claude in a terminal in a directory where it reads or writes files, so file links

appear in the transcript.

  1. Run /rc in that session — or start it with claude remote-control. Both reproduce.
  2. Open the session in Claude Desktop or at claude.ai, and click a link to a file that

does exist and is inside the session's working directory.

The message appears for a file that is present, readable, and in scope. (A link resolving
to a genuinely absent path is not this bug — there the message is accurate.)

Full investigation, including what was ruled out (directory depth, spawn provenance,
environment health, symlink canonicalization):
https://github.com/anthropics/claude-code/issues/77203#issuecomment-5110557505

Is this a regression?

Not sure — the underlying preview limitation has been reported since #48466 (2026-04). I
have not tested whether the message wording changed at any point.

Claude Code Version

2.1.220 (Claude Desktop 1.24012.9)

Platform / OS

Linux — Fedora Silverblue x64. Also reported on macOS in #77203.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗