[BUG] Desktop app: an attached file cannot be located by path, and file_upload rejects any path containing emoji

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?

Summary

A file attached to a conversation in the desktop app is not reachable by Claude as a file. Claude can see the image content, but there is no path it can open, copy, or hand to a tool — including file_upload, whose own description says attachments are exactly what it accepts.

From the user's side this is backwards. Deliberately attaching a file is a stronger signal than leaving one on the Desktop, and it takes more clicks — yet a file on the Desktop is trivially usable and an attachment is not usable at all.

What Should Happen?

Expected

Copy the attachment into a session-readable location and expose its path — the same fix proposed in #65181 (closed as stale; that one is the macOS TUI variant). #72396 covers the adjacent TUI case where pasted images became paths.

Error Messages/Logs

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" }]

Steps to Reproduce

Repro

1. Desktop app (Claude 1.25927.0, Claude Code 2.1.221, macOS 26.6 arm64).
2. Attach any image to a message and ask Claude to use the file rather than look at it — for example, upload it to a file input on a page.
3. There is no path to give any tool.

Searching for it does not help, and causes a second problem. A sweep of ~/Library/Application Support, ~/Library/Containers, ~/Library/Caches and /private/var/folders for recently-modified image files returned nothing, and triggered the macOS TCC prompt "claude would like to access data from other apps" (#63130). So the workaround for this bug produces an alarming permission dialog and still fails.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.221

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Second, independent defect found while testing this

mcp__claude-in-chrome__file_upload rejects the paths array before the tool runs when a path contains non-ASCII characters. The whole array arrives as undefined:

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" }]

Path length is not the cause. 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"). A path containing an emoji directory name fails validation every time.

This is not an edge case for me: my project folders are named with emoji, so every path into my working tree is unusable with file_upload. Together with the attachment problem above, there is currently no way to get a file I own into a web page from the desktop app.

Related: #70614 (Glob wildcards vs emoji directory names, closed).

Also

file_upload's schema lists only paths and tabId as required, but calling it without ref fails validation asking for ref. Either the schema or the validator is wrong.