claude-in-chrome file_upload fails: paths: expected array, received undefined

Confirming this bug independently on Windows, with an isolated repro that rules out several other variables:

Environment: Claude Code CLI, Windows 11, model claude-sonnet-5, claude-in-chrome MCP.

Repro (not tied to any third-party app):

1. Created a minimal local HTML page (served over http://localhost) with a single <input type="file">.
2. Got a valid ref via read_page (shown correctly as button [ref_1] type="file").
3. Called file_upload with that ref and various local file paths:

• A real PDF with a Windows hard link → correctly rejected with "the file has multiple hard links..." (as expected).
• The same PDF copied to remove the hard link, still under a path containing an accented character (é/á) → paths: expected array, received undefined.
• The same file copied again into a path with no accented characters at all, inside the session's own scratchpad/output folder (which should be in the allowlist) → same paths: expected array, received undefined.
• A brand-new trivial .txt file created directly in the scratchpad folder → same paths: expected array, received undefined.

1. Re-fetched a fresh ref immediately before each call to rule out a stale-ref issue — no change.

So this reproduces regardless of file type, path length, accented characters, or whether the file is in a user-connected folder vs. the session's own output folder — as long as the file is real, readable, and has a single hard link (i.e., once it passes the earlier validation checks that correctly reject missing/hard-linked files), the call to file_upload fails with this schema error every time. This points to an unhandled exception during the actual file read/attach step that gets misreported to the client as a paths schema validation failure instead of the real underlying error.

Current workaround (same as reported above): fill out the rest of the form via form_input/JS, then pause and ask the user to manually select the file through the native browser UI.

Third independent confirmation, Windows 11 + Claude Desktop (Cowork mode), reproducing daily 2026-08-05 through 2026-08-07. I want to add one probe that I think isolates the failing step more precisely than anything posted so far, and which independently corroborates @jairomoreira296-hue's read that this is a misreported exception rather than a schema problem.

The decisive probe: existence flips the error

Two browser_batch calls differing only in whether the target file exists:

| Path passed | Error returned |
|---|---|
| ...\Dragon Beaux Restaurant\Salt Baked Chicken.jpg (exists, 545,452 bytes) | file_upload requires a non-empty paths array... |
| ...\Dragon Beaux Restaurant\ZZ_DOES_NOT_EXIST_PROBE.jpg (does not exist) | Cannot upload "C:\...\ZZ_DOES_NOT_EXIST_PROBE.jpg": only files this session is allowed to read can be uploaded. |

The non-existent path is quoted back verbatim. So the argument arrives intact, is parsed, and is existence-checked. It is not lost in transit, and this is not a schema validation failure despite what the error says.

The behaviour is inverted: a path that does not exist produces a loud, specific, correct error. A path that does exist clears the existence/allowlist check and is then silently dropped from the array, leaving it empty, before any upload occurs. Whatever runs between "path validated" and "file attached" is throwing, and the throw is being flattened into a paths schema error.

This matches @jairomoreira296-hue exactly: missing file → correct error; hard-linked file → correct error; real readable file → schema error.

Two error surfaces, same underlying fault

• Standalone: -32602 ... "path": ["paths"], "message": "Invalid input: expected array, received undefined"
• Inside browser_batch: file_upload requires a non-empty paths array of files the user has shared with this session

Standalone reports undefined, batch reports empty. Consistent with the array being emptied by a filter step rather than never arriving.

Ruled out (each tested directly, not assumed)

| Hypothesis | Test | Result |
|---|---|---|
| Session allowlist / shared-folder scope | File in the session's own outputs folder; also a file in the session's own uploads folder (the location confirmed working in #63334) | Same failure |
| OneDrive placeholder / reparse point | stat: links=1, 1072 blocks allocated, real JPEG magic ffd8ffe1 — fully hydrated | Not the cause |
| OneDrive filesystem generally | Copied to non-OneDrive session outputs folder | Same failure |
| File size | 3,828-byte generated JPEG vs 545 KB client photo | Both fail |
| Filename complexity | z_small.jpg (short, ASCII, no spaces) vs Salt Baked Chicken.jpg | Both fail |
| File age / provenance | Created seconds earlier by the sandbox vs a 2015 photo | Both fail |
| Stale element ref | Fresh find before every call, across many sessions | Same failure |
| Multi-device routing | Two browsers connected; explicitly select_browser'd the local Windows one; later sessions had only one connected | Same failure |
| Stale local state | Full restart of desktop app, extension, and machine reboot | Same failure |
| Extension reinstall | See #84652, which reports this persists after extension update and full reinstall-equivalent reset | Not the cause |

Every existing file fails, regardless of location, size, name, age, or filesystem.

v1.26832.0 does not fix this

The 2026-08-06 changelog entry "Claude in Chrome file uploads failing for files in the session's shared folders and outputs" does not resolve it. Retested after updating: identical failure, including for a file in the session's own uploads directory. This matches @arjen-rave's same-day report on #63334.

Not the same bug as #63334

Worth separating, since they get conflated. #63334 is the CCD-vs-cowork INVALID_SESSION bug and surfaces as "only files this session is allowed to read". This issue surfaces as a paths schema error on files that pass every check. Related area, different failure.

Suggested next step for whoever picks this up

Given the existence-flip above, the fault is almost certainly in the read/attach step between allowlist validation and DataTransfer construction, with the exception being swallowed and re-emitted as a schema error. Surfacing the real exception instead of the paths message would likely make this a short fix — and would have saved three of us several days each.

Impact

Blocks a production workflow publishing daily social posts for 21 restaurant clients across two scheduled tasks. Three consecutive days lost, 0 accounts published. Image selection and captions complete each day; only the upload step fails. Only workaround is the one already reported here: have the user select files manually, then resume automation.

Confirming this same bug independently, with some additional data points that might help narrow it down.

I hit the exact same error (paths: expected array, received undefined) trying to upload real files to a file input inside an iframe on a third-party site. Non-existent paths pass schema validation fine and fail later with the expected "only files this session is allowed to read" message — it's specifically real, accessible files that break validation at the schema level.

Two things I isolated that might be useful: it reproduced identically across JPEG, PDF, and TXT files, and with filenames both with and without spaces or digits, so it's not filename-content-dependent. I also fully uninstalled and reinstalled the Claude in Chrome extension mid-session and the bug persisted immediately after reinstall with a brand new tab/session, which suggests this isn't a stale local extension state issue but something server-side in how the tool call is validated before dispatch.

This is currently blocking any workflow that needs to upload a real local file through a web form via this tool.

The cause here is the path, not the tool: file_upload fails input validation when a path contains non-ASCII characters. The whole paths array arrives as undefined.

Reproduced today on macOS 26.6 (Claude desktop 1.25927.0, Claude Code 2.1.221):

• A path containing an emoji directory name → Invalid input: expected array, received undefined, every time.
• The same call with a 254-character pure-ASCII path → parses fine and returns the normal, correct rejection ("only files this session is allowed to read can be uploaded").

So it is not path length, and it is not the allowlist. Validation fails before the allowlist is consulted, which is why the error names paths rather than the file.

Practical impact: my project folders are named with emoji, so every path into my working tree is unusable with this tool.

One more, possibly related: the schema lists only paths and tabId as required, but omitting ref fails validation demanding ref.

Filed the fuller version — this, plus the attachment-path problem that led me here — as #85107.