Remote control: side panel cannot open any file, including plain text inside the working directory

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 13, 2026

Summary

In a remote-control session, clicking a file link in the chat never opens the file in the side panel. It fails with:

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

This is reported in #48466 and #62011, both closed as inactive. Those issues describe the limitation for binary/preview content (PDF, images, HTML). I'm filing this because the limitation is broader than documented there: it also affects plain text files that sit directly inside the session's working directory. The error message is also misleading, since the file is neither missing nor outside the working directory.

Environment

  • Claude Code 2.1.220
  • macOS 26.5.1
  • Host (where the agent runs): Mac mini
  • Client (where I view the session): MacBook, via remote control at claude.ai/code

Steps to reproduce

  1. Start a session on machine A with a working directory, e.g. ~/Projects/my-project.
  2. Connect to that session from machine B via remote control.
  3. Ask Claude to link to a plain text file that already exists directly in the working directory — for example CLAUDE.md, linked as [CLAUDE.md](CLAUDE.md).
  4. Click the link.

Expected

The file opens in the side panel, as it does in a local session.

Actual

Nothing opens. The side panel shows "Couldn't read this file — It may have been deleted or moved, or it lives outside the working directory", even though the file exists and is inside the working directory.

Evidence that this is not a path or configuration problem

Same file, same session, same link — the only variable is local vs. remote:

| Link form | Local desktop session | Remote control session |
|---|---|---|
| Relative path inside working directory | opens | fails |
| file:///absolute/path | opens | fails |
| Bare absolute path | opens | fails |
| obsidian:// | never fires | never fires |

Ruled out by testing, all negative in remote control:

  • Adding the target directory to additionalDirectories in settings.json
  • Creating the same directory structure and symlinks on the client machine as on the host
  • Anchoring the session in a different working directory
  • Linking a file with no symlink, no cloud sync, sitting directly in the working directory (CLAUDE.md) — this is the decisive case, and it fails too

The last point is what makes this broader than #48466: it is not specific to binary or preview content, and not specific to files reached through symlinks or synced folders. No file is readable by the side panel in remote control.

Why this matters

Remote control is otherwise ideal for driving a long-running session on a desktop machine from a laptop. But any workflow where Claude writes a file and the user wants to read it becomes copy-paste-into-chat, which defeats much of the point of having a file panel. In my case Claude regularly writes Markdown notes to an Obsidian vault; locally I click and read them, remotely I cannot.

Requests

  1. Confirm whether this is intended, and document it on the remote control docs page (https://code.claude.com/docs/en/remote-control) — it is currently not mentioned there.
  2. Fix the error message so it reflects the real cause ("file preview is not available in remote control sessions") instead of implying the file is missing or out of scope.
  3. Consider supporting text file content over the remote-control bridge, even if binary preview stays out of scope. Per #48466 the bridge streams chat messages and tool results; text file content seems closer in kind to those than PDF or image rendering.

Related

  • #48466 — Preview pane (PDF/image/HTML) unavailable in remote-control sessions (closed as inactive)
  • #62011 — [FEATURE] Preview pane in remote-control sessions (closed as inactive)

View original on GitHub ↗