blocked because the path is network-shaped

バックグラウンドセッションが、ネットワーク上の場所を指すパスを拒否しました。

バックグラウンドセッションは対話的な確認ができないため、パスの解決に厳しい制約がかかります。ネットワーク上のパスは、接続状態・認証・遅延・切断のいずれでも挙動が変わるため、危険と判断して先に止めます。

日本の開発現場では、次のような構成でよく当たります。

⚠️ Z: のようにドライブレターが割り当てられていると、ローカルに見えて実はネットワークです。 見た目で判断できないため、このエラーで初めて気づくことがあります。

1. そのパスが本当にネットワークか確認する

Windows（PowerShell）

Get-PSDrive -PSProvider FileSystem |
  Select-Object Name, Root, @{n='種別';e={ if ($_.DisplayRoot) { 'ネットワーク: ' + $_.DisplayRoot } else { 'ローカル' } }}

DisplayRoot に \\server\share が入っているドライブはネットワークドライブです。

現在の作業ディレクトリを確認します。

(Get-Location).Path
[System.IO.Path]::GetPathRoot((Get-Location).Path)

macOS / Linux

df -h . | tail -1
mount | grep -E "$(df --output=target . | tail -1)"

smbfs / nfs / cifs などが出ればネットワークです。

2. ローカルへ移す（最も確実）

⭐ 推奨はこれです。 作業ディレクトリをローカルディスクに置いてください。

# 例: ネットワーク上のリポジトリをローカルに複製する
git clone \\fileserver\share\project C:\dev\project
cd C:\dev\project

ネットワーク越しのファイル操作は、そもそも遅く、ファイル監視も不安定です。 バックグラウンドセッションに限らず、開発の作業ディレクトリをネットワーク上に置くのは避けたほうが確実に快適になります。

3. WSL を使っている場合

\\wsl$\... という形で Windows 側から WSL のファイルを触ると、このエラーに当たります。

⭐ WSL のファイルは、WSL の中から扱ってください。

# WSL のターミナルで
cd ~/project
claude

逆に Windows 側のファイルを WSL から触る場合（/mnt/c/...）も、パフォーマンスが大きく落ちます。 どちらか一方に寄せるのが定石です。

4. 対話セッションで実行する

バックグラウンドでなければ制約は緩みます。どうしてもネットワーク上で作業する必要があるなら、通常の対話セッションを使ってください。

⚠️ ただし、遅延と切断のリスクは残ります。 根本的には手順 2 が正解です。

5. 似たエラーとの区別

同じくバックグラウンドセッションのパス制約で出るものに、次があります。

後者の場合は、正規化した絶対パスを使ってください。

readlink -f ./project

(Resolve-Path .\project).ProviderPath

• ⭐ 開発の作業ディレクトリをネットワークドライブに置かない。 このエラーだけでなく、ビルドの遅さ、ファイル監視の取りこぼし、ロックの競合など、あらゆる問題の温床になります
• 共有が必要ならファイル共有ではなく Git を使う。それがバージョン管理の本来の役割です
• Z: などのドライブレターは実体が見えません。新しい環境では最初に Get-PSDrive で確認する習慣をつけると事故が減ります
• WSL と Windows のファイルを行き来しない。どちらかに寄せる