Feature Request: File upload support in the built-in Browser pane

Feature Request: File upload support in the built-in Browser pane

Summary

The built-in Browser pane (Claude_Browser / mcp__Claude_Browser__* tools) has no way to upload a local file to a web page. Clicking an <input type="file"> element (or any button wired to one) correctly triggers the page's native "Open File" dialog, but that dialog is rendered by the OS outside the browser tab's DOM — so it's invisible to computer (screenshot/click/type) and there's no equivalent of the Claude-in-Chrome extension's file_upload tool to inject file data directly into the input element.

Why this matters

Any real-world task that involves uploading media (video, image, PDF, etc.) to a third-party site — social media scheduling, CMS uploads, form attachments, support tickets — hits a hard wall in the built-in Browser pane. Today the only workarounds are:

1. Ask the user to manually click through the native file picker themselves (works, but means Claude can't complete an otherwise fully-automatable multi-step task end to end).
2. Switch entirely to the Claude-in-Chrome extension, which does have file_upload (paths → reads local files under session permissions → sets them on a ref'd file input) and upload_image (for screenshots). This requires the user to have the extension installed and to re-authenticate on every site, which is a heavier ask than just continuing in the pane that's already open and already logged in.

Suggested fix

Add a file_upload-equivalent tool for the built-in Browser pane, mirroring what mcp__claude-in-chrome__file_upload already does:

• Accepts a tab id, a ref (from read_page/find) pointing at the file input, and either paths (server-side reads local files under the session's existing file-read permissions) or inline base64 files.
• Sets the file(s) on the input's files property via the same privileged automation channel already used for computer/javascript_tool, without needing to touch any OS-level dialog.
• Respect the same size/permission constraints already in place for local file access in this harness.

Real-world case that surfaced this (context, not required reading)

Session was driving a multi-platform social scheduling workflow (Facebook Reels → Instagram → TikTok) for a small video series, all through the built-in Browser pane since the user was already logged into Facebook there. Every platform's upload flow (Facebook's regular post composer, Facebook's Reel composer) hit the same wall: clicking "Hochladen"/"Video hinzufügen" opens the native OS file dialog, which is outside what computer can see or interact with. Ended up asking the user to manually pick the file each time, which works but breaks the "hand off a multi-step task and get it done" value of the automation.