[BUG] Claude in Chrome file_upload: eligible files fail with -32602 "paths received undefined" in interactive Cowork sessions (Windows) — related to #84880 / #85107 / #63334

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?

Environment: Claude desktop app (Cowork mode), Windows 11; Claude in Chrome extension driving Google Chrome; model claude-fable-5. Date: 10 August 2026, ~10:15–10:45pm AEST.

Task: upload a 178 KB PDF from a connected (OneDrive-synced) folder to a web app via mcp__claude-in-chrome__file_upload.

Summary

file_upload failed for every existing, eligible file this session, on two unrelated websites (a practice-management app and Xero's Files inbox), with a malformed-arguments error indicating the paths parameter is dropped between the harness and the extension. Nonexistent or ineligible paths return correct, descriptive domain errors — proving arguments transmit properly in those cases. The failure occurs only when the file exists and passes eligibility checks, which suggests the harness-side staging/eligibility pipeline for eligible files strips or loses paths before extension-side schema validation runs.

Unlike #84880 (whose reporter's interactive sessions still work), this failure is in a normal interactive session. The error signature matches #85107's report of paths arriving as undefined. #63334 (closed, not planned) documented the scheduled-session variant.

Chronology and exact errors

1. Original file, OneDrive-synced connected folder (C:\Users\<user>\OneDrive - <org>\...\<file>.pdf) — rejected twice with:

> Cannot upload "…": the file has multiple hard links, which can alias a file outside the session's allowed directories. This commonly triggers for files inside package-manager stores like node_modules (Bun and pnpm hard-link packages). Copy the file (e.g. with cp) and upload the copy.

This is a normal OneDrive-synced PDF, not a package store — likely a false positive from OneDrive Files On-Demand. Every file in the OneDrive folder is rejected this way, so no OneDrive file can be uploaded directly.

1. Sandbox workspace was down when the suggested cp workaround was first attempted: "Workspace unavailable. The isolated Linux environment failed to start (VM service not running. The service failed to start.)" — persisted ~25 minutes, then recovered on its own mid-session.

1. Fresh copy in a subfolder of the connected folder (made via File Explorer) — reproduced 5+ times, with backslash and forward-slash path forms, and after re-fetching the tool schema:

> MCP error -32602: Input validation error: Invalid arguments for tool file_upload: [ { "expected": "array", "code": "invalid_type", "path": ["paths"], "message": "Invalid input: expected array, received undefined" } ]

The call supplied paths as a one-element array every time.

1. Control tests — all passed schema validation (arguments clearly arrive when the file is nonexistent or ineligible):

• C:\test.pdf (nonexistent) → "Cannot upload…: only files this session is allowed to read can be uploaded."
• Nonexistent 154-character path in the connected folder → same "only files…" error
• Nonexistent file in the subfolder → same "only files…" error
• The multi-hard-link original (item 1) → hard-link error, i.e. also past schema validation

1. Copies in the session outputs folder (via File Explorer, later via bash once the VM recovered):

• Full-length filename → same -32602 "received undefined"
• Short filename, confirmed single hard link (stat -c %h = 1), 128-character total path → same -32602

This rules out path length, hard links, OneDrive, and the specific folder as causes.

1. Linux-style path /sessions/<session>/mnt/outputs/… → "only files this session is allowed to read" (VM was down at that moment).

1. Cross-site control (Xero): created a 209-byte dummy PDF in the session outputs folder, located the type="file" input on Xero's Files inbox (go.xero.com), called file_upload → identical -32602 "paths … received undefined". Nothing was uploaded.

Pattern / probable cause

file_upload fails with "paths: received undefined" exactly when the target file exists and is eligible (inside an allowed directory, single hard link). Ineligible or nonexistent paths produce correct domain errors. This suggests the harness-side pre-processing of eligible files crashes or strips paths before the extension-side schema validation runs, so the extension sees no paths at all. Possibly related to the workspace VM having been in a failed state earlier in the session (if file staging routes through the VM); however, the failure persisted after the VM recovered.

Impact

Blocks all browser file-upload workflows for this practice: scheduled runs have failed since ~6 August (see #84880's matching timeline) and interactive sessions now fail as above. Manual browser uploads are the only route.

Other anomalies in the same session (possibly related)

• Workspace VM failed to start for ~25 minutes, then recovered without intervention.
• The target site's browser session logged itself out mid-task and the MCP tab group vanished (tabs "no longer exist"; a fresh tab group was created).
• First tabs_context_mcp call failed once with "Tabs cannot be edited right now (user may be dragging a tab)".
• Computer-use focus anomalies while driving File Explorer ("Claude's own window still has keyboard focus"; "no app is frontmost"; a Ctrl+L landed on the desktop and opened the Start menu).
• Sandbox mount would not permit removing files from the connected folder (mv: cannot remove …: Operation not permitted).

Related issues

• #84880 — same timeline (regression began 6 Aug 2026) and environment (Windows + Cowork), but scheduled-task sessions only; this report shows interactive sessions also affected, with a different (earlier-layer) error.
• #85107 — same -32602 "paths … received undefined" signature, plus schema/validator mismatch notes.
• #77240 — earlier schema divergence in the same tool.
• #63334 — closed scheduled-session variant (INVALID_SESSION masked by the "only files…" message).

What Should Happen?

file_upload should accept a valid, session-readable file supplied as a one-element paths array and upload it to the located file input, as it did reliably until early August 2026. A file that the session's Read/bash tools can already access should never fail schema validation with "paths: received undefined" when the argument was supplied, and a normal OneDrive-synced document file should not be rejected as a multi-hard-link package-store file.

Error Messages/Logs

Eligible existing file (the failing case):
MCP error -32602: Input validation error: Invalid arguments for tool file_upload: [ { "expected": "array", "code": "invalid_type", "path": ["paths"], "message": "Invalid input: expected array, received undefined" } ]

OneDrive-synced original:
Cannot upload "…": the file has multiple hard links, which can alias a file outside the session's allowed directories. This commonly triggers for files inside package-manager stores like node_modules (Bun and pnpm hard-link packages). Copy the file (e.g. with cp) and upload the copy.

Nonexistent/ineligible path (control — correct behaviour, proves arguments arrive):
Cannot upload "…": 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.

Workspace failure earlier in the same session:
Workspace unavailable. The isolated Linux environment failed to start (VM service not running. The service failed to start.)

Steps to Reproduce

1. Windows 11, Claude desktop app in Cowork mode with a OneDrive-synced folder connected, Claude in Chrome extension active.
2. In a normal interactive session, navigate Chrome to any page with an <input type="file"> (reproduced on two unrelated sites, including Xero's Files inbox at go.xero.com).
3. Create a small valid PDF inside the session outputs folder (or copy one there), confirm it is readable via the Read/bash tools and has a single hard link (stat -c %h = 1).
4. Call file_upload with paths as a one-element array pointing at that file (backslash or forward-slash form — both fail) and the located file input.
5. Observe MCP -32602 "paths … received undefined" despite paths being supplied. Repeat with a nonexistent path to confirm the control case returns the normal "only files this session is allowed to read" error instead, proving the arguments transmit.

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown exact version — last known working day was 5 August 2026 (daily scheduled uploads succeeded); failures began 6 August 2026. Matches the regression window reported in #84880.

Claude Code Version

Claude 1.26832.0 (056ee2) 2026-08-06T05:43:05.000Z

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Reporting as an end user (small business, non-developer) — the diagnostic chronology above was gathered systematically by the Claude session itself during the failure. Two follow-ups I can provide on request: (1) a retest in a completely fresh session after a full app restart (not yet done — the failing session had also experienced a workspace VM outage earlier, noted in the report), and (2) results from the next scheduled run, which has failed daily since 6 August. Happy to run further diagnostics or provide logs if you tell me what to capture.

Also related: #85140 — same two error signatures on Windows, pinned to the 2.1.221 release (working through 2.1.219), but scheduled-task sessions only; my report adds interactive-session and cross-site reproduction. Not a duplicate of #85140 or #84880: both cover scheduled sessions only, whereas the failures above occur in a normal interactive session.