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

Claude in Chromeのfile_uploadツールが、Windows版Coworkで実在する読み取り可能なファイルに対してすら失敗するようになりました。2026年8月6日ごろにスケジュールタスクで始まり、8月10日には対話セッションでも報告されています。返ってくるのはMCP error -32602で始まるスキーマエラーで、paths引数がundefinedとして届いたことを示します。原因は既知issue#85517として追跡され、Claude Code v2.1.261(2026年9月5日公開)のchangelogに修正が記載されました。

ただ、file_uploadの失敗は1種類ではありません。エラー文言ごとに原因も打ち手も違うので、最初に文言から切り分けます。

返ってきたエラー文言で原因を見分ける

issueに貼られていた文言は4種類あり、それぞれ原因の層が違います。

1つ目と2つ目は、報告者が同じ系統の不具合とみている症状で、どちらもローカルセッションで起きます。3つ目と4つ目はファイルの置き場所や属性に対するチェックです。ただし4つ目は、OneDriveで誤検知とみられる報告があります。

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

厄介なのは、存在しないファイルや読み取り権限のないファイルを指定すると、別の正しいエラーが返ることです。そのときはpathsが正常に届いています。#85517の報告者は、C:\test.pdf(存在しない)、接続済みフォルダ内の存在しないパス、複数ハードリンクの元ファイルなどで、いずれもスキーマ検証を通過していることを対照実験で確かめています。

失敗したのは、接続済みフォルダかセッションの出力フォルダにある実在のファイルで、ハードリンクが1つだけのものです。同じ報告者は、このほかにも原因の候補を1つずつ外しています。

• パスの長さ: 128文字の短い構成でも再現
• ハードリンク: stat -c %hで1つだけと確認したコピーでも再現
• OneDrive・特定のフォルダ: セッション出力フォルダへ置いたコピーでも再現
• サイト固有の実装: practice-management系アプリとXeroのFiles受信箱(go.xero.com)で同じエラー

つまり、ファイルが実在して条件を満たすときだけ、どこかの前処理でpathsが落ちていたことになります。

ローカルセッションだけで起きた理由

Coworkのセッションには、クラウド実行とローカル実行の2種類があります。見分け方はCoworkがクラウド実行かローカル実行か見分ける方法にまとめています。

クラウドセッションでは、エージェントループがAnthropicのサーバー上のサンドボックスで動きます。ローカルセッションでは手元のデバイス上で動き、接続済みフォルダのファイルへ直接アクセスします。

関連issue#87386の報告者は、クライアントが認識したWindowsパスをファイル内容(pre-read)へ変換してからホストへ渡している、と推定しています。ホストはローカルセッションでpre-readを受け付けないので、認識されたパスはすべて拒否されます。クライアントが認識しないパス表記(\\?\C:\…、file:///…、VMのパス)だけが変換を免れ、許可リストの拒否に当たります。

この説明は報告者の推定です。Anthropicが原因として認めた文言ではありません。

修正までに1か月近くかかった経緯

#87386は、更新の前後が同じセッションに残っている点が資料として強い報告です。更新前のビルドでは、同じパス・同じフォルダ・同じファイルでUploaded 1 file(s) to file inputと成功していました。更新の途中でChromeのMCPサーバー名がmcp__Claude_in_Chrome__*からmcp__claude-in-chrome__*に変わり、以降のfile_uploadがすべて失敗したと報告されています。

コメント欄では、更新前のビルド(1.24012.9)へ戻すと動いたという報告も出ています。ただしこれは利用者の体験談で、公式に案内された手順ではありません。自動更新を止める方法も利用者のコメントで共有されていますが、検証はできていません。

なお、closeされた8月時点では実際には解消しておらず、changelogに載った9月5日を修正の目安と見るのが妥当です。

対処: v2.1.261を含むClaude Desktopに更新する

公式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の項に記載されています。気をつけたいのは、番号が2系統あることです。

issueで報告者が挙げているのはClaude Desktopのビルド(1.28929.0など)で、changelogに載っているのはClaude Codeのバージョンです。修正を含むDesktopのビルド番号は、changelogには書かれていません。そのため「Desktopが何番以上なら直っている」とは言い切れません。

Claude Desktopは自動で更新されるので、まずアプリを完全に再起動します。それでもpaths received undefinedが出るなら、更新が適用されていない可能性があります。

更新後も出る症状については、#87386がopenのままで、コメント欄に修正の言及は見当たりません。文言が「pre-read files」の側であれば、別の症状として扱われている可能性があります。

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

修正後も似たエラーに遭うなら、不具合ではなくクラウドセッション特有の挙動かもしれません。クラウドセッションのfile_uploadが関わる場所は3つです。

• Claudeのセッションが動くクラウドのコンテナ
• Chrome拡張機能が動く手元のパソコン
• ファイルが実際に置かれているディスク

issueに投稿された利用者ガイドによると、file_uploadはコンテナの中からファイルを読み、ページの入力欄へ渡します。C:\Work\report.pdfのようなパスはコンテナの中に存在しないため、そのまま渡しても開けません。フォルダへのアクセスを許可しても、許可されるのはデバイスブリッジ(device_list_dir・device_bash・device_stage_files)であって、コンテナではありません。

ここで#87386のコメントが役に立ちます。同じアカウント・同じファイル・同じページで、クラウドセッションでも試した報告です。結果は次のとおりでした。

つまり、ステージング手順はクラウドセッション用の迂回路で、ローカルセッションの不具合をそのまま避ける方法にはなりません。issueに投稿された利用者ガイドは、そのセッションをクラウド実行(「Run new tasks in the cloud」をON)へ切り替えてからステージングする迂回を挙げています。#87386のコメントでも、クラウドへ切り替えると最後までアップロードできたと報告されています。

ステージングを経由するアップロード手順

同じガイドにある手順です。ファイルをコンテナへ先にコピーするdevice_stage_filesを挟みます。

stagedPathは返された値をそのまま使います。フォルダ名は接続したフォルダに応じて変わるため、自分で組み立てると外れることがあります。利用者ガイドでは、1回の呼び出しで最大50ファイルをまとめてステージングできるとされています。

サイズには2段の上限があります。ガイドによれば、ステージングは1ファイルあたり約400MB・1回あたり約500MBまでで、上限はエラー文にも表示されます。file_uploadは、Claude Codeの公式ドキュメント上、1回の合計が10MBまでです。ステージングが通っても、file_upload側で失敗する大きなファイルは、1件ずつ渡します。

公式ドキュメントには、Readを拒否する権限ルールがあるファイルはアップロードもブロックされる、という制限もあります。

成功しても送信は終わっていない

ガイドによれば、Uploaded 1 file(s) to file inputは「ファイルが入力欄に入った」ことしか示しません。フォームの送信ボタンは別に押す必要があり、ページ側の表示で確認します。ステージング経由なら元のファイル名がそのまま残るので、ページに出たファイル名とディスク上の名前が一致するかで、本当に手元のファイルを送ったか見分けられます。

よくあるつまずき

• ファイル入力欄をクリックしない: OS標準の「ファイルを選択」ダイアログが開き、拡張機能からは見えず操作できなくなります。file_uploadはこのダイアログを避けるために存在するツールです
• JavaScriptでFile/FileListを注入しない: React・Angularなどのフレームワークは、プログラムから設定したFileListではイベントを発火しないことが多く、送信ボタンが反応しないままになります。#87386の報告者はDataTransferの注入でファイルを入力欄に載せられたと述べていますが、その上でツール側の不具合だと位置づけています
• パスの綴りを変えて同じ呼び出しを繰り返さない: C:/…、\\?\C:\…、file:///…は、失敗の原因が綴りでなければ結果は変わりません。綴りで文言が変わるのは、クライアントがパスと認識するかどうかの差です
• チャット添付だけに頼らない: ファイル名にアンダースコア変換やuuidが付き、元ファイルとの対応が追いづらくなります

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

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

#85517の報告者は、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による誤検知だと見ており、OneDriveフォルダ内のファイルがすべて弾かれたと書いています。本記事の「paths received undefined」とは別の原因です。

エラー文は「コピーしてコピーをアップロードせよ」と案内します。ただし、報告者がこの手順を試した結果は次のとおりでした。

1. コピーの作業を始めようとしたところ、サンドボックスが「Workspace unavailable」で約25分間使えなかった
2. エクスプローラーで接続済みフォルダのサブフォルダにコピーしたところ、今度はpaths received undefinedに当たった

つまり案内どおりにコピーしても、当時は2つ目の不具合に阻まれたことになります。この報告では、cpによる回避を試す段階でサンドボックスが止まっており、コピーできてもその先に別の不具合がありました。

影響度早見表

まとめ

エラー文言が「paths received undefined」ならローカルセッションの不具合で、Claude Desktopの更新と再起動が最初の一手です。「only files this session is allowed to read」は、指定したパスがセッションに許可された場所にないときの文言です。ローカルセッションならファイルを接続済みフォルダに置き直し、クラウドセッションならdevice_stage_filesを経由します。「pre-read files」が更新後も続くなら、#87386で追跡されている別の症状かもしれません。Coworkの全体像はClaude Cowork(クロードコワーク)とはにあります。