[Cowork] "Failed to load local file" is not txt/md-specific — `_readLocalHostFile` fails the same way for every file type, including xlsx/html which silently recover

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Cowork's right-hand preview panel shows "Failed to load local file" for .txt/.md/.csv/.log/.json files, every time, regardless of encoding, line endings, or content. This looks like a text/markdown-viewer bug, but log inspection shows it isn't: the backend read call fails identically for .xlsx (53 times in my test session) and .html (8 times) — more than for the plain-text types — yet those two render fine for the user.

main.log shows this warning on every failure, for every extension:

[warn] _readLocalHostFile: path moved between validation and open: <path>

claude.ai-web.log shows the renderer-side error for the same event:

[error] [LOCAL_SESSION] Failed to load local file: {"name":"Error","message":"Error invoking remote method '$eipc_message$_..._$_claude.web_$_FileSystem_$_readLocalFile': LocalFileAccessError: [FILE_READ_ERROR] Path moved during read: <path>"}

(Earlier occurrences in the same log used [PATH_NOT_ALLOWED] Path moved during read — same check, different error code across app versions.)

Extension breakdown of the warning across my test session (2026-07-17 to 2026-07-20):

| Extension | Occurrences |
|---|---|
| .xlsx | 53 |
| .txt | 24 |
| .md | 20 |
| .csv | 10 |
| .log | 8 |
| .html | 8 |
| .json | 4 |

This is a two-step validate-then-open path check (looks like a TOCTOU guard against symlink-swap attacks) that is misfiring on the large majority of file reads, for every file type — not something specific to plain text. .xlsx/.html most likely render through a separate path (e.g. an embedded viewer or iframe loading the file directly) that doesn't depend on this call succeeding, so the failure is silently absorbed. The plain-text/markdown viewer has no such fallback and shows the raw error every time.

I ruled out, by direct testing:

• Encoding (UTF-8 no BOM, UTF-8 with BOM, ASCII) — all fail identically
• Line endings (LF, CRLF) — fail identically
• Empty vs. populated file content — fails identically
• File age (minutes vs. days after creation) — fails identically, so it isn't a narrow post-write race
• Folder location — reproduced in both the scratch outputs directory and a folder mounted via request_cowork_directory

What Should Happen?

File content should render in the preview panel regardless of extension, and the failure rate visible to users shouldn't be inversely related to how often the underlying read actually fails.

Error Messages/Logs

Steps to Reproduce

1. Open a Cowork session on Windows.
2. Connect a folder via "connect a folder," or use the default scratch output location.
3. Create a .txt, .md, .csv, .log, or .json file in that folder.
4. Click the file in the right-hand preview panel — observe "Failed to load local file" every time.
5. Create an .xlsx or .html file in the same folder and preview it — it renders correctly.
6. Check %APPDATA%\Claude\logs\main.log for _readLocalHostFile: path moved between validation and open at the same timestamps as both the failing and the "working" preview clicks — the warning fires for all of them.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.22209.3 (Claude Desktop)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Related existing reports — likely the same underlying bug or a close relative, cross-referencing for whoever picks this up:

• #33940 — same user-facing error text, Windows, no internal log evidence.
• #297 (aaddrick/claude-desktop-debian) — same error family on Linux, framed as an allowed-folder issue.
• #33499 — related but distinct: blank (not hard-error) preview for PDF/DOCX on macOS, possibly the same fallback-vs-no-fallback pattern.
• #29583, #40300 — different bug (folder-level permission tracking breaks on path rename), but same general "path handling is fragile on Windows" theme.

Happy to share the full log excerpts (125 occurrences of the warning across main.log, plus corresponding claude.ai-web.log entries) and the 10-file test matrix used to rule out encoding/content causes, on request.