[Bug] file_upload tool not exposed via Claude Code MCP connection

Bug Description

Bug: file_upload tool not exposed via Claude Code MCP connection

Summary

The Claude in Chrome extension (v1.0.56) has a file_upload tool that allows uploading local filesystem files to <input type="file"> elements on web pages. This tool is available when using the Chrome sidepanel directly, but is not exposed through the MCP native messaging bridge to Claude Code. This makes it impossible to automate file uploads from Claude Code skills that use --chrome.

Environment

• Claude in Chrome extension: v1.0.56
• Claude Code: latest (via claude --chrome)
• Browser: Google Chrome
• OS: macOS

Steps to reproduce

1. Run /mcp in Claude Code and select claude-in-chrome
2. Observe 17 tools listed. file_upload is not among them:

• javascript_tool, read_page, find, form_input, computer, navigate, resize_window, gif_creator, upload_image, get_page_text, tabs_context, tabs_create, update_plan, read_console_messages, read_network_requests, shortcuts_list, shortcuts_execute

1. Open the Chrome sidepanel and ask: "what upload tools do you have available?"
2. Sidepanel reports both upload_image and file_upload as available

Expected behavior

file_upload should appear in the MCP tool list and be callable from Claude Code, just as it is from the sidepanel.

Actual behavior

Only upload_image is exposed via MCP. file_upload is missing entirely. When an agent attempts to upload local files to a website, it can only find upload_image, which requires an imageId from a previously captured screenshot and does not accept local file paths. The agent then enters a failure loop trying workarounds (screenshot capture, base64 injection via javascript_tool, localhost file servers) that are all either broken or impractical.

Impact

This blocks a core automation use case: uploading files to authenticated web applications (expense reports, CRMs, document management systems, etc.) from Claude Code skills. The workarounds are:

• upload_image: Only works with screenshots/session images, not local files. Also fails across tool calls via MCP with "Unable to access message history to retrieve image" errors.
• javascript_tool with DataTransfer/base64: Files must flow through Claude's context window as base64 text. A typical receipt photo (150KB base64 after resizing) exceeds practical limits for a single javascript_tool call. Aggressive image compression to fit makes receipts illegible. Chunking across multiple calls works but requires 5+ calls per file and burns significant context.
• curl from bash with extracted cookies/CSRF: Requires API-level access that many enterprise web apps don't allow from outside the browser session.

None of these workarounds are reliable or production-quality for skills.

Suggested fix

Expose file_upload through the MCP native messaging interface with the same schema it has in the sidepanel:

{
  "name": "file_upload",
  "description": "Upload one or multiple files from the local filesystem to a file input element on the page. Do not click on file upload buttons -- clicking opens a native file picker dialog that you cannot see.",
  "input_schema": {
    "properties": {
      "paths": { "type": "array", "items": { "type": "string" }, "description": "Absolute file paths" },
      "ref": { "type": "string", "description": "Element reference ID of the file input" },
      "tabId": { "type": "number" }
    },
    "required": ["paths", "ref", "tabId"]
  }
}

Additional context

The upload_image tool also has reliability issues when used via MCP. Screenshot IDs (ss_*) captured in one tool call produce "Unable to access message history to retrieve image" errors when referenced in subsequent upload_image calls. This may be a separate but related issue with image/session state not persisting correctly across the MCP bridge.

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.36
• Feedback ID: 06a10233-d1af-471b-a3c8-d3749f2a1d4b

Errors

[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/lukealexander/.local/share/claude/versions/2.1.36 (expected in multi-process scenarios)\n    at OFR (/$bunfs/root/claude:3584:2098)\n    at tbA (/$bunfs/root/claude:3584:1209)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-05T19:25:22.491Z"},{"error":"Error\n    at <anonymous> (/$bunfs/root/claude:33:10681)\n    at emit (node:events:92:22)\n    at <anonymous> (/$bunfs/root/claude:32:3321)\n    at request (/$bunfs/root/claude:35:2149)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-05T19:25:42.475Z"}]