claude-in-chrome file_upload broken on latest CLI+extension: rejects host paths, no files param; upload_image can't retrieve image

Summary

On the latest Claude Code + latest Claude Chrome extension, both file-upload paths of the claude-in-chrome integration are broken, so an agent cannot programmatically attach a file to a web page's <input type="file">:

• mcp__claude-in-chrome__file_upload rejects host filesystem paths and instructs the caller to pass file contents via a files parameter — but its advertised schema only has paths (no files param exists to pass), and Claude Code (the "MCP controller") does not do the path→contents read itself.
• mcp__claude-in-chrome__upload_image fails with an image-retrieval error, so it can't be used as a fallback.

Net: there is no working way to upload a file to a page through Claude Code on these versions.

Environment

• Claude Code CLI: 2.1.207 (confirmed latest via claude update)
• Claude Chrome extension: 1.0.80 (confirmed latest on the Chrome Web Store, updated 2026-07-07)
• Claude Desktop app: 1.15962.1 (installed, not running — extension paired to Claude Code)
• macOS (Darwin 25.5.0)

Repro

1. From Claude Code, run /chrome and connect a browser.
2. Navigate to any page containing an <input type="file">.
3. Locate the input with find/read_page to get its ref.
4. Call file_upload with { paths: ["/abs/path/to/file.pdf"], ref, tabId }.

Actual

file_upload returns:

file_upload no longer accepts host filesystem paths. The MCP controller must read
the file and pass its contents via the `files` parameter. If you are seeing this in
Claude Desktop, update the desktop app.

But:

• The file_upload tool schema exposed to the model has only paths, ref, tabId — no files parameter to pass contents through.
• Updating does not help: Claude Code 2.1.207 and extension 1.0.80 are both already the latest, and the message's "update the desktop app" remedy only applies to Claude Desktop, not Claude Code.

Trying the alternate tool upload_image with a screenshot imageId captured via the computer screenshot action (tried both with and without save_to_disk) returns:

Unable to access message history to retrieve image

Expected

Either:

• file_upload accepts a path for a file the session is allowed to read and the controller reads it and forwards the contents to the extension (matching the error's stated contract), or
• the file_upload schema exposes the files/contents parameter the extension now requires so the model can supply contents directly, and
• upload_image can retrieve a previously captured screenshot for upload.

Impact

Any Claude Code browser-automation workflow that must attach/upload a file to a web form is fully blocked on current versions — everything up to the upload works, but the file can never be placed into the file input. Also verified that a workaround of serving the file over http://127.0.0.1 and fetch-ing it from the page is blocked by the browser (HTTPS→localhost subresource fetch hangs), so there is no client-side workaround either.