同じClaude Desktopなのに、フォルダを触れるタブと触れないタブがあった

しろまえ殿は、Claude Desktopの通常のチャットタブに、作業フォルダを読ませようとした。

うまくいかない。

アップロードしたファイルは読めるのに、フォルダそのものには一切触れられない。

同じアプリの中に、ローカルへのアクセス範囲が違うタブが同居していることに、しろまえ殿はここで気づいた。

三つの経路を、切り分けた

整理すると、ローカルにアクセスできる経路は三つあった。

一つ目は、Claude DesktopのCowork(接続したフォルダに対して自律的にタスクをこなす機能)タブ。

接続したフォルダに限って、読み書きの対象にできる。

二つ目は、同じアプリのCodeタブ。

こちらはプロジェクト内でファイルシステムとターミナルにフルアクセスできる。

三つ目が、Claude Code CLI。

実行時のワーキングディレクトリ配下だけが対象になる。

通常のチャットタブが何も見られないのは、設計上そうなっているだけだった。

Coworkは「隔離された作業場」で動く

もう一つ、しろまえ殿が確認して気に留めたことがある。

Coworkのタスク実行そのものは、Anthropic側サーバーの隔離環境で走る。

つまり、フォルダを接続するということは、その中身をローカル外の実行環境に渡すということでもある。

複数ファイルにまたがる作業は、Coworkでフォルダごと接続する方が効率的だ。

一方、1〜2ファイル程度なら、チャットへ直接アップロードした方が手数が少ない。

たとえば書類一式を丸ごと片付けたいときはCowork、報告書1枚を直すだけならアップロード、という使い分けになる。

顧客データなど機微な情報を含むフォルダを接続する場合は、この「どこで処理が走るか」を一度立ち止まって考える価値がある。

WSL環境では、素直にCLIを使う

開発環境がWSL2側にある場合、Windows側のClaude DesktopからWSLのパスを掴ませるより、WSL内で直接Claude Code CLIを動かす方が安定する。

ファイル監視やパーミッション、改行コードの扱いで事故りにくいからだ。

すでにClaude Code CLIで日常の開発を回している場合、Desktop側のCodeタブは同じClaude CodeにGUIが付いただけのものだ。

ローカルコードを触らせるだけが目的なら、わざわざ移行する必要は無い。

セッションが固まったら、まずジョブを疑う

余談として、しろまえ殿はもう一つ実務の癖を得た。

Claude Codeのセッションが固まったように見えるとき、原因はCtrl+Z(処理を一時停止させる操作)の誤爆であることが多い。

jobsコマンドでStoppedと出ていれば、fgで復帰できる。

パニックになる前に、まずここを確認する。

三つの経路を頭の中で分けてから、しろまえ殿はフォルダの扱いで迷わなくなった。

どのタブが何を見られるか。

それだけ知っていれば、遠回りは減る。

参考にした公式情報

• Anthropic「Claude」製品情報（Claude Desktop / Cowork機能の概要。確認日: 2026-08-02）

https://claude.com/product/overview

制度・仕様は変更されることがある。実際に使う際は、Anthropicの最新の公式情報を確認してほしい。