[BUG] Regression: Claude in Chrome file_upload rejects ALL paths after Claude Desktop update — "can't accept pre-read files" (worked on previous build, before/after captured in one session)

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?

mcp__claude-in-chrome__file_upload rejects every path format after updating Claude Desktop, in an interactive Cowork session on Windows. The same call, same file location, same connected folder, same session succeeded before the update (previous build was ~1-3 weeks old).

Timeline (single session, 2026-08-17):

1. Cowork session started on the previous Claude Desktop build (installed ~1-3 weeks earlier). Connected folder: C:\test.
2. file_upload with paths: ["C:\\test\\<file>.pdf"] -> SUCCESS ("Uploaded 1 file(s) to file input: ... (57 KB total)"). File landed in the page's file input normally (target: mysmis2021.gov.ro, standard input type=file).
3. Claude Desktop updated mid-session. Observable marker: the Chrome MCP server re-registered under a new name — tools renamed from mcp__Claude_in_Chrome__* to mcp__claude-in-chrome__*.
4. From that moment, ALL file_upload calls fail, with two distinct errors depending on path spelling (see Error Messages).
5. Second machine (office laptop) already on the updated version: identical failure on fresh sessions — reproducible across machines.

What was tested (all fail):
| Path variant | Result |
|---|---|
| C:\test\file.pdf (connected folder) | Error A |
| C:/test/file.pdf | Error A |
| Session outputs folder (Windows path) | Error A |
| \\?\C:\test\file.pdf | Error B |
| file:///C:/test/file.pdf | Error B |
| /sessions/<vm>/mnt/test/file.pdf (VM path) | Error B |
| Chat attachment route | fails likewise |

Error A = "can't accept pre-read files"; Error B = "only files this session is allowed to read" (full texts in Error Messages field).

Per Error A's own wording, the client converts recognized filesystem paths into pre-read files before they reach the host, and the host then refuses pre-read files for this session type. The two components contradict each other — every recognized path is converted, so every recognized path is refused. Unrecognized spellings pass through unconverted and die at the host allowlist, which apparently does not contain the user's connected folder (C:\test was connected and readable by Read/Glob tools the whole time). Same family as #63334 (upload validator consults session state that doesn't match the live session), but different error text, interactive session (not scheduled task), Windows (not macOS), and a clean regression with before/after captured in a single session.

Environment notes: local session ("Run new tasks in the cloud" = OFF); on this device the local Linux VM does not start ("isolated Linux environment failed to start (not supported on this device)") — VM-less local mode. Extension works fine otherwise (navigate/find/computer/javascript_tool all OK; only file_upload broken). DataTransfer injection via javascript_tool successfully attaches a synthetic file to the same input, so the page side is fine — only the tool's path handling is broken.

Suggested fix direction: the client-side path->files conversion appears intended for cloud sessions (host can't read local disk). For local sessions it should pass paths through to the host untouched; alternatively the host should accept client-pre-read files when the session is local.

What Should Happen?

file_upload should attach a file from a user-connected folder to a page file input — exactly as it did before the update, in the same session, with the same arguments.

Error Messages/Logs

Error A — returned for every Windows-style path (connected folder C:\test\..., C:/test/..., and the session's own outputs folder):

file_upload can't accept pre-read `files` in this session; it only takes `paths` of files in folders the user has connected to the session. If you passed `paths` and still see this, the client converted them before they reached the host and file_upload is unavailable here — tell the user instead of retrying.

Error B — returned for spellings the client does not recognize as Windows paths (\\?\C:\test\..., file:///C:/..., /sessions/<vm>/mnt/...):

Cannot upload "<path>": only files this session is allowed to read can be uploaded. Ask the user to share the file with this session, or to add its folder with /add-dir.

Before the update, the identical call succeeded:
Uploaded 1 file(s) to file input: <file>.pdf (57 KB total)

Steps to Reproduce

1. Windows machine, Claude Desktop with Cowork, "Run new tasks in the cloud" OFF, Claude in Chrome extension connected.
2. Start an interactive Cowork session; connect a local folder (e.g. C:\test) containing any PDF.
3. Open any page with an <input type=file> (e.g. a form with an upload field) via mcp__claude-in-chrome__navigate; locate the input with find.
4. Call mcp__claude-in-chrome__file_upload with paths: ["C:\\test\\<file>.pdf"], the input's ref, and tabId.
5. On the updated build (2026-08-17): Error A above, 100% of the time. Alternate spellings (\\?\ prefix, file:///, VM /sessions/ path) produce Error B. On the previous build (~1-3 weeks old): the same call succeeds.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown exactly — Claude Desktop build installed ~1-3 weeks before 2026-08-17 (early August 2026)

Claude Code Version

Claude Desktop for Windows (Cowork), latest as of 2026-08-17 — auto-updated mid-session, which is when the regression appeared

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Related open issues — this appears to be a third error signature of the same regression family:

• #85517 — interactive Cowork sessions on Windows, -32602 "paths received undefined" for eligible files. Same environment (Windows + Cowork + Claude in Chrome), different error text.
• #85140 — pins the regression to Desktop release 2.1.221 (working through 2.1.219), scheduled sessions. That window matches this report: my previous working build was installed early August 2026.
• #84880 — scheduled-task variant, regression began ~6 Aug 2026.
• #77240 — "rejects host paths, no files param" — closest match to the error text reported here.
• #63334 — closed scheduled-session variant (INVALID_SESSION masked by generic message).

New evidence this report adds: (1) a distinct error message not documented in the issues above ("file_upload can't accept pre-read files in this session..."), explicitly revealing the client-side path→files conversion; (2) a clean before/after capture in a SINGLE session — the tool worked, Claude Desktop auto-updated mid-session (observable: Chrome MCP server re-registered, tools renamed from mcp__Claude_in_Chrome__ to mcp__claude-in-chrome__), and the tool broke immediately after; (3) reproduction across two machines; (4) confirmation that DataTransfer injection via javascript_tool still works on the same input — only file_upload's path handling is broken.

Reported by an end user (non-developer); the diagnostic matrix above was gathered systematically by the Claude session itself. Happy to run further diagnostics on request.