Coworkでフォルダを指定する方法 — ホームディレクトリ外もv1.1062.0で選択可

Coworkでフォルダを指定するには、左ナビの「Projects」で「+」を押し、「Use an existing folder」から作業中のフォルダを選びます。ホームディレクトリの外にあるフォルダも、v1.1062.0以降は同じ手順で指定できます。

Coworkのフォルダ選択は、2026年2月に報告された段階ではユーザーのホームディレクトリ内のフォルダしか許可していませんでした。プロジェクトを別ドライブに置く人や、ドキュメントの保存先を移動しているWindowsユーザーには使いづらい制約でした。v1.1062.0(2026年4月7日公開)でこの制限は撤廃され、macOSとWindowsのどちらでもホームディレクトリ外のローカルフォルダを選択できます。

残っているのはネットワーク共有です。Windowsの\\server\share形式(UNCパス)は、ドキュメントとIssueの報告が食い違う部分も含めて、今も扱いが安定していません。

Coworkはホームディレクトリ外のフォルダを選べるか

結論は「選べる」です。Claude DesktopのCowork機能はv1.1062.0以降、macOS・Windowsのどちらでもホームディレクトリ外のローカルフォルダをそのまま指定できます。

フォルダさえ指定できれば、Coworkで契約書をバッチレビューするやCoworkでブランド資産をフォルダ単位で監査するのような、フォルダ単位でまとめて処理する使い方も、保存場所をホームディレクトリの外に置いたまま実行できます。

Coworkでフォルダを指定する手順

フォルダの指定はプロジェクト単位で行います。Coworkのプロジェクトには、読み書きの対象にするローカルフォルダを1つ以上登録できます。

プロジェクトはお使いのコンピューター上に置かれ、クラウドへは同期されません。ホームディレクトリの外のフォルダでも手順は変わりません。選べないときは次の切り分けに進んでください。

つまずいたときの切り分け

エラーの出方で原因が分かれます。上から順に当てはめてください。

2026年2月に報告された制限とエラーメッセージ

制限そのものはGitHubのバグ報告で2026年2月11日に報告されました。WindowsでC:\Users\<ユーザー名>の外にあるフォルダを選ぶと、次のエラーが表示される内容です。

Invalid Folder Selection - The selected folder is outside your home directory. Only folders within your home directory can be used.

厄介だったのは、判定がシンボリックリンクやNTFSジャンクションをすり抜けられなかった点です。ホームディレクトリ内にジャンクションを作って外部フォルダを指すよう仕向けても、Coworkはfs.realpath()でパスを実体まで解決してから判定していました。リンク経由でも同じエラーで弾かれていたことになります。

影響はプロジェクトフォルダだけにとどまりません。コメントを寄せた1人は、Windowsの「既知のフォルダーのリダイレクト」でドキュメント・デスクトップ・ダウンロードを別ドライブへ移している場合も、同じ制限にかかると指摘しています。この機能はWindows Vista以降の標準機能です。

macOSでも同じ壁に当たった人がいます。/Volumes/Dataにデータ用のドライブをマウントしていた利用者が、3月15日のコメントで同じ制限を報告しています。Issueの題はWindows向けですが、制限はWindowsだけの話ではありませんでした。

制限の経緯と、v1.1062.0で変わったこと

2月22日のコメントは「バグ」ではなく設計上の挙動と位置づけていました。報告者は「UI側の制約であり、セッション開始後はサンドボックスがそのパスに触れる」と考えていましたが、これは報告者の見立てです。Issue上では理由の詳細は説明されていません。

修正前後の違いは次のとおりです。

修正前に作ったプロジェクトが自動では直らないという報告も、4月8日に出ています。新しく作ったプロジェクトのフォルダはエクスプローラーで開けるのに、古いプロジェクトは開けないという内容で、1件だけの報告です。

ドライブの種類ごとに、ファイル操作とシェルは動くか

サンドボックスに載るかどうかで、ファイル操作とシェルコマンドの結果が分かれます。ドキュメントの記述を場所別に並べると次のとおりです。

マップ済みドライブは、次のコマンドでドライブレターに割り当てます。

net use Z: \\server\share

サンドボックスは、セッションをまたいで起動したままになることがあります。起動中にドライブをマップすると、サンドボックスが次に再起動するまでシェルからは見えません。再起動のさせ方は同ページに書かれていないため、新しいセッションを開くだけで直るとは限りません。シェルから見えないときは、対象ファイルをローカルフォルダにコピーしてからビルドやスクリプトを実行します。

リムーバブルドライブも同じ扱いです。USBメモリ上のリポジトリでビルドしたいときは、ローカルへコピーする案内になっています。

ドキュメントとIssueの報告が食い違う点

ここまでの表はドキュメントの記述に沿っています。ただし、このページの題は「Claude Desktop on 3P」(サードパーティ基盤向けのClaude Desktop)です。未設定のとき任意のフォルダを添付できる点は、標準版と同じと書かれています。一方、ネットワークドライブやリムーバブルドライブの節が標準版にも当てはまるとは書かれていません。

標準版のCoworkは既定でクラウド側で動き、ローカルのファイルはデスクトップアプリ経由で読み書きします。表のシェルの列がそのまま当たるかは分からず、UNCの扱いは#45297の報告で確かめるしかありません。

その報告は、ドライブレターの割り当てについて割れています。

• 4月18日・7月7日のコメントは、割り当てたドライブが内部でUNCに解決され、UNC paths are not supportedで失敗すると書いています
• 9月10日のコメントは、企業のファイルサーバーでドライブレター経由なら読み取りだけ通り、書き込みが失敗すると報告しています
• 9月16日のコメントは、ドライブレター経由ならフォルダを添付できると報告しています

別の報告者は、9月16日のコメントで失敗の出方が変わったと書いています。4月は「添付できたのに使う段階で失敗」でしたが、現行ビルドでは「UNCパスを選んでも、何のメッセージもなくフォルダが追加されない」とのことです。この点も、そのコメントだけの報告です。

OSやビルド、共有の種類で挙動が違う可能性があります。ネットワーク共有を使うなら、書き込みまで含めて自分の環境で小さく試すのが確実です。#45297は9月25日にも更新があり、OPENのままです。

ドライブレターに寄せる場合の副作用も報告されています。

ネットワーク共有をCoworkで使えたという報告

正式な手順ではありませんが、Windowsのネットワーク共有で動いたという報告があります。プロジェクトの作り方で挙動が変わるという内容です。

チェックを入れ損ねると、同じプロジェクトの別チャットでファイルが表示されないそうです。この手順を試した別の利用者2人が、9月22日と25日に動いたと返信しています。うち1人は、SMBのパスを小文字に変えたことも併せて挙げています。投稿者を含めて3人の報告で、公式に確認された手順ではありません。

macOSで外付けドライブ・ネットワークストレージを使う場合

Windowsのマップ済みドライブとは扱いが異なります。サードパーティ基盤向けのドキュメントには、macOSで/Volumes/配下にマウントされたネットワークストレージはローカルフォルダとして扱われると書かれています。標準版で同じかどうかは明記がありません。外付けSSDやNAS共有を/Volumes/経由でマウントしている場合、ドライブレターの割り当てのような手順は、少なくともそのドキュメントの範囲では不要です。

WSLのフォルダを使うときの注意

WSL(Windows Subsystem for Linux)のファイルも、同じUNCの壁に当たります。Windowsは各ディストリビューションを\\wsl$\<ディストリ名>または\\wsl.localhost\<ディストリ名>として見せます。

案内は2つです。共有をドライブレターにマップして選ぶか、Windows側の通常フォルダにコピーしてから選びます。サードパーティ基盤向けのドキュメントによると、Cowork自体はWSLを必要とせず、Windows版はOS標準の仮想化機能でサンドボックスを動かします。標準版で同じ構成かは明記がありません。

#45297には、WSLのフォルダが突然使えなくなったという8月4日の報告もあります。タスクがクラウドで動くようになった更新の後、接続済みのはずのフォルダでファイル操作がUNC paths are not allowedで失敗したそうです。設定の「Run new tasks in the cloud」をオフにすると、ファイル操作だけは戻ったと書かれています。シェルやgitは使えないままで、1人の報告です。

ただしサポート記事によると、Pro・Maxプランでは2026年10月6日に「コンピューター上のみ」の選択肢が設定から削除され、新しいタスクはクラウドで動きます。この回避策はそれ以降、選べなくなる見込みです。Team・Enterpriseでは、管理者が組織設定の「Run Cowork in the cloud」で切り替えます。

管理者がフォルダの選択肢を制限する仕組み

Team・EnterpriseプランのClaude Desktopには、管理者がMDMで配るallowedWorkspaceFoldersというキーがあります。標準版の設定一覧では、値はパスの文字列の配列です。設定すると、ユーザーが添付できるフォルダを指定したルートの配下だけに絞れます。未設定なら、OSの権限で届くフォルダを自由に添付できます。

値の書き方による挙動の違いは、サードパーティ基盤向けのドキュメントの記述です。標準版の設定一覧には、modeと空配列の説明がありません。

• ["~/Documents/Claude", "/Volumes/Shared/Projects"]のように並べると、そのルートの内側だけが対象です
• 要素を{"path": "...", "mode": "ro"}の形にすると、Coworkではエージェントが読めても書き換えられない共有フォルダにできます
• 空配列[]なら、ユーザーのファイルシステムには一切触れず、サンドボックス内の作業領域だけで動きます

判定は解決後のパスに対して行われ、シンボリックリンクや..での回避はできません。組織の端末で急にフォルダが選べなくなったときは、今回のバグとは別に、この管理ポリシーが原因でないか確認する価値があります。

Coworkの制約とClaude Codeの違い

Issueのコメント欄では、ターミナルで動くClaude Codeは任意の場所のフォルダを扱えるのに、GUIのCoworkだけホームディレクトリに縛られるのは奇妙だという声が複数上がっていました(RavenSwords、rgsiiiyaのコメントなど)。両者の挙動が違う理由は、Issueでは説明されていません。

修正前に出回った回避策は3種類でした。Windows用のMCPサーバーやDesktop Commanderで任意の場所を読む方法、macOSでNFSのループバックマウントを使う方法、ファイルをホームの下へコピーする方法です。MCPで広い権限を渡す手は、効果の裏で権限も広がります。v1.1062.0以降はローカルフォルダには不要です。

ほかに報告されたつまずき

ホームディレクトリの外にドキュメントフォルダを移している環境では、別の失敗が出た報告があります。4月12日のコメントによると、定期タスクのSKILL.mdをE:\Dokumente\...から作る際に失敗したそうです。エラーはEXDEV: cross-device link not permittedで、リンク先はアプリのデータ領域(C:側)でした。ドライブをまたぐハードリンクを作れないという意味のエラーで、フォルダの選択とは別の層の問題です。1件のみの報告で、修正されたかは、Issueに書かれていません。

シンボリックリンクを使った古い回避策を残している場合は、フォルダを選び直すほうが単純です。複雑な迂回を残すとパスの解決先が分かりにくくなります。

まとめ

ローカルドライブなら、v1.1062.0以降はホームの外でもそのまま選べます。迷うのはネットワーク共有とWSLで、公式の手順どおりドライブレターにマップしても、環境によって読み取りだけ・失敗・メッセージなしの不発に分かれます。共有を使うなら、書き込みとシェル実行まで小さなフォルダで試してから本番の作業に移るのが無難です。