Claude in Chromeのファイルアップロードが失敗する原因と対処法

Claude in Chromeのfile_uploadツールは、2026年8月6日ごろからWindows版Coworkの対話セッションで、実在する読み取り可能なファイルに対してすら失敗するようになりました。返ってくるのはMCP error -32602で始まるスキーマエラーで、paths引数がundefinedとして届いたことを示します。原因は既知issue#85517として追跡され、Claude Code v2.1.261(2026年9月5日公開)の公式changelogに修正が記載されました。アップデート前の一時対応と、修正後もクラウドセッションで似た症状に遭う場合の切り分け方をまとめます。

Claude in Chromeのfile_uploadが「paths received undefined」で失敗する

file_uploadは、Claude in Chrome拡張機能が操作しているページの<input type="file">へ、ローカルのファイルをアップロードするツールです。障害が起きたセッションでは、次のエラーが返っていました。

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

このエラーの厄介な点は、存在しないファイルや読み取り権限のないファイルを指定した場合は正しく動くことです。そのときは「only files this session is allowed to read can be uploaded」という別のエラーが返り、paths引数自体は正常に届いていることが分かります。エラーになるのは、接続済みフォルダ内にある実在のファイル、かつハードリンクが1つだけの単一ファイルを指定したときだけでした。practice-management系アプリとXeroのFiles受信箱(go.xero.com)という無関係な2サイトで再現しており、特定サイトの実装に依存する不具合ではありません。

なぜ既存ファイルだけが失敗するのか

Coworkのセッションには、クラウド実行とローカル実行の2種類があります。詳しい見分け方はCoworkがクラウド実行かローカル実行か見分ける方法にまとめていますが、file_uploadの挙動を理解するうえでもこの区別が前提になります。

クラウドセッションでは、Claudeのエージェントループ自体がAnthropicのサーバー上のサンドボックスで動きます。file_uploadはこのサンドボックスの中からファイルを読み取るため、手元のディスク上のパスをそのまま渡しても読み取れません。ローカルセッションでは逆に、エージェントループが手元のデバイス上でネイティブに動き、接続済みフォルダのファイルへ直接アクセスできる設計です。

今回の不具合が起きていたのはローカルセッション側です。関連issue#87386の報告によれば、クライアント側が実在するファイルパスを検知すると、ファイル内容を事前に読み込んだ(pre-read)データへ変換してからホストへ渡す処理が挟まっていました。ところがホスト側は、ローカルセッションでの事前読み込みデータを受け付けない仕様のままで、変換されたデータを拒否していました。存在しないパスや権限のないパスはこの変換処理を経ずにホストの許可リストで弾かれるため、paths引数自体は届いていたことになります。この仕組みの説明は同issueの報告者による推定であり、Anthropicが公式に原因として認めた文言ではない点に注意してください。

経緯 — 修正までに1か月近くかかった既知issue

コメント欄では2026-08-21に「直った」という報告が出ましたが、2026-08-23には別の利用者が「直っていない」と反論しています。closeされた8月時点では実際には解消しておらず、issueが本当に解決した状態になったのは、changelogに載った9月5日と見るのが妥当です。

対処: v2.1.261へのアップデートで解消する

Anthropicの公式changelogには、次の記載があります。

Fixed Claude in Chrome file_upload failing with "paths: expected array, received undefined" in local Cowork sessions run from the Claude Desktop app

この修正はClaude Code v2.1.261(2026年9月5日公開)のchangelogに記載されています。Claude Desktopは既定で自動更新されるため、この日以降にアプリを再起動していれば、通常はこの修正を含むビルドに更新されています。念のため確認したい場合は、Claude Desktopを一度完全に再起動し、Claude in Chrome拡張機能のツール一覧がmcp__claude-in-chrome__*の名前で登録されているかを見ます。更新の前後でこのツール名が変わるタイミングが、報告の中でも不具合発生・解消の目印として使われていました。

クラウドセッションのfile_uploadは仕組みが違う

修正後も似たエラーに遭う場合、原因はこの不具合ではなくクラウドセッション特有の仕様であることが多くなります。Coworkにはクラウド実行とローカル実行の2種類があるため、まずどちらで動いているかを確かめるのが先になります。

クラウドセッションのfile_uploadが関わる場所は3つです。Claudeのセッションが動くクラウドのコンテナ、Chrome拡張機能が動く手元のパソコン、そしてファイルが実際に置かれているディスクです。file_uploadはコンテナの中からファイルを読み、ページの入力欄へ渡します。C:\Work\report.pdfのようなパスはコンテナの中に存在しないため、そのまま渡しても開けません。フォルダへのアクセスを許可しても、これはデバイスブリッジ(device_list_dir・device_bash・device_stage_files)を許可するだけで、コンテナ自体を許可するわけではありません。

以下はissueに投稿された利用者ガイドに基づく手順です。ファイルをコンテナへ先にコピーするdevice_stage_filesを経由します。

1. device_stage_files(["C:\\Users\\you\\Documents\\Invoices\\march.pdf"])
   -> stagedPath: /mnt/user-data/uploads/Invoices/march.pdf
 
2. find("アップロードダイアログのファイル入力欄")
   -> ref_42 のような参照を取得
 
3. file_upload(
     paths = ["/mnt/user-data/uploads/Invoices/march.pdf"],
     ref   = "ref_42",
     tabId = <対象タブのID>
   )

stagedPathは返された値をそのまま使い、自分で組み立てないことが重要です。フォルダ名の付け方は接続したフォルダに応じて変わり、予測できるとは限りません。1回の呼び出しで最大50ファイルをまとめてステージングできるため、複数ファイルは分割せずまとめて渡します。ただし同ガイドの報告によると、device_stage_files自体には1ファイルあたり約400MB、1回の呼び出しあたり約500MBの上限があり、file_upload側は1回の呼び出しの合計サイズが10MBに制限されます。ステージングまでは成功しても、file_upload側の10MB制限で失敗するケースがあるため、大きなファイルは1件ずつアップロードします。

よくあるつまずき

• ファイル入力欄をクリックしない: OS標準の「ファイルを選択」ダイアログが開き、拡張機能からは見えず操作できなくなります。file_uploadはこのダイアログを避けるために存在するツールです
• JavaScriptでFile/FileListを注入しない: React・Angularなどのフレームワークは、プログラムから設定したFileListではイベントを発火しないことが多く、送信ボタンが反応しないままになります
• パスの綴りを変えて同じ呼び出しを繰り返さない: C:/…、\\?\C:\…、file:///…のような別表記を試しても、失敗の原因が綴りでなければ結果は変わりません
• チャット添付だけに頼らない: チャットへの添付は動きますが、ファイル名にアンダースコア変換やuuidが付くため、ディスク上の元ファイルとの対応が追いづらくなります。ステージング経由なら元のファイル名がそのまま残ります

ページ側がアップロードを受け付けない場合は、file_upload自体の問題ではなくClaude in Chromeが動かないときの原因と対処法で扱う切り分けが役立ちます。対象のファイル形式がページ側で許可されていない、必須項目が別に残っている、といったサイト側の制約が原因のことがあります。

OneDriveの「複数のハードリンク」エラーは別の不具合

同じissueの報告者は、OneDrive同期フォルダ内の通常のPDFを対象にしたときにも、次の別のエラーに遭遇しています。

Cannot upload "...": the file has multiple hard links, which can alias a file
outside the session's allowed directories. This commonly triggers for files
inside package-manager stores like node_modules (Bun and pnpm hard-link
packages). Copy the file (e.g. with cp) and upload the copy.

この検知は本来、node_modulesのようなパッケージマネージャのストア内ファイルを想定した安全チェックです。OneDrive Files On-Demandで同期された通常のファイルまで弾いてしまうのは、この安全チェック側の誤検知であり、本記事で扱う「paths received undefined」とは原因が別です。OneDriveフォルダのファイルだけがこのエラーになる場合は、いったんフォルダ外の場所へコピーしてからアップロードすると回避できます。両方のエラー文言を見分けておくと、v2.1.261へのアップデートで直るはずの不具合なのか、OneDrive特有の誤検知なのかを切り違えずに済みます。

影響度早見表

まとめ

Windows版Coworkのfile_uploadが「paths received undefined」で失敗する不具合は、ローカルセッション限定の問題としてClaude Code v2.1.261で修正されています。手元のClaude Desktopを更新すれば、対話セッションでの直接アップロードは通常どおり動きます。更新後もクラウドセッションで似たエラーに遭う場合は、不具合ではなくdevice_stage_filesを経由する仕組み上の要件である可能性が高く、先にセッションの実行方式を確認するのが近道です。Coworkの全体像はClaude Cowork(クロードコワーク)とはで確認できます。