Windows desktop: File Pane fails 'outside the session folder' on existing files; absolute Windows paths not auto-linked

Versions

• Claude for Windows (desktop app): 1.8555.0 (8245b7)
• Claude Code (native, controlled over Remote Control by the desktop): 2.1.147 (commit 09432314e835)
• Platform: win32-x64
• Claude Code path: C:\Users\smuch\.local\bin\claude.exe
• Project cwd in session: E:\dev\herald

Two distinct symptoms in the chat-message file-link renderer

Symptom 1 — Relative-looking path is auto-linked but click fails

When the agent emits a path like docs/_wip/fakeserver-vision-survey-2026-05-21.md inline in a chat message, the desktop app's renderer makes it a clickable blue link. Clicking opens the File Pane on the right, which displays:

File could not be read. It may have been deleted or moved, or it lives outside the session folder.

The file exists on disk at E:\dev\herald\docs\_wip\fakeserver-vision-survey-2026-05-21.md. Tool calls (Read, Edit, Bash) against the same path resolve and succeed in the same session — the bug is in the File Pane's link-resolver, not the file or the tool layer.

The app's chrome shows the path it's trying to read as E:\dev\herald/docs/_wip/fakeserver-vision-survey-2026-05-21.md — a mixed-separator path (backslash before docs, forward slashes after). Worth checking whether path-separator normalization is involved on Windows.

Symptom 2 — Absolute-looking Windows path is not recognized as a link at all

When the agent emits e:\dev\Herald\docs/_wip/fakeserver-vision-survey-2026-05-21.md (lowercase drive, mixed slashes — chosen because it matches the chrome's own path display), the renderer leaves it as plain text. No link, no click affordance. User has to manually copy the path into File Explorer or an IDE to open.

Reproduce

1. Launch Claude for Windows desktop app on Windows, control a Claude Code session in a Windows project (cwd with a drive letter, e.g. E:\dev\herald)
2. Have the agent emit two paths in a chat message:

• Relative form: docs/foo.md
• Absolute Windows form: e:\dev\herald\docs/foo.md

1. Click the relative form — File Pane errors despite the file existing
2. Try to click the absolute form — not a clickable link

Expected behavior

Either form should resolve relative to the session's cwd (E:\dev\herald) and successfully read the file in the File Pane. At minimum, both forms should produce clickable links.

Related

• #51331 — identical "outside the session folder" error reported in the SSH session context. Same File Pane resolver bug class; different surface (this report is Windows desktop direct, not SSH).
• #51584 — Cyrillic NFC/NFD path bug on macOS. Different cause, but shows the File Pane has its own path-handling layer separate from tool calls.

Notes

• This appears to be in the "Windows path-handling polish" cluster Anthropic has been working through (drive-letter case normalization fixed in v2.1.111; NTFS junction handling in v2.1.144). Possibly the same family.
• Slash/backslash normalization hypothesis: the mixed-separator chrome path is suspicious but unproven.
• Workaround in the meantime: deliver files via the agent's file-attachment surface (e.g., SendUserFile) instead of relying on chat-link clicks, or copy paths manually into File Explorer.