Claude Codeのnetwork path警告 — UNCをadd-dirできない理由と回避策
/add-dirや起動時に出る「is a network path」の警告は、UNC共有を作業ディレクトリに加えない仕様によるものです。拒否される範囲と、ドライブ文字・ローカルマウントへの回避を示します。
Claude Codeで/add-dir \\server\shareを実行すると、「is a network path, which cannot be added as a working directory」と表示されて追加できません。起動時に同じ文言が警告として出ることもあります。壊れているのではなく、ネットワークパスを作業ディレクトリに加えない仕様による拒否です。
Windowsなら共有をドライブ文字に割り当て、起動時に--add-dirで渡せば通ります。macOSとLinuxでは、共有をローカルのパスにマウントしてから追加します。この記事では、拒否される理由、拒否される範囲、環境ごとの直し方を順に示します。
警告の文言と出る場面
メッセージの全文は次のとおりです。
\\server\share is a network path, which cannot be added as a working directory. On Windows, map the share to a drive letter and pass it at launch with --add-dir (a drive letter added mid-session does not yet carry remote-read trust).出る場面は2つあります。
- セッション中に
/add-dirでネットワークパスを指定した - 起動時に、
--add-dirやpermissions.additionalDirectoriesがネットワークパスを含んでいた
起動時に出た場合、Claude Codeはそのディレクトリを抜きにして立ち上がります。セッションは使えますが、読ませたいつもりだった共有の中身は見えていません。「警告は出たが動いている」状態では、追加されたと思い込んだまま作業を進めやすい点に注意が要ります。
なぜネットワークパスは拒否されるのか
理由は、パスを調べる動作そのものにあります。ネットワークパスを引くと、パスが指すホストへ接続が飛ぶことがあります。Windowsではその接続でホストに認証情報が渡るおそれがあります。そこでClaude Codeは、ネットワークパスを検証せずに拒否します。
「入れてから危険なら止める」のではなく、「調べる前に断る」設計です。パスを引くこと自体がホストへの接触になりうるため、引く前に断る形にしています。
この方針は単発の仕様ではなく、Windowsのパス検証まわりの修正と同じ流れにあります。v2.1.233ではNTデバイスプレフィックス(\??\)がUNC検証をすり抜け、NTLM資格情報が漏れる経路になっていた問題が塞がれました。作業ディレクトリへの追加を断る今回の仕様は、同じ「認証情報を外へ出さない」目的の延長にあります。
どのパスが拒否され、どれが通るのか
拒否されるのは、UNC共有だけではありません。
拒否されるパス
UNC共有
\\server\shareの形です。最も典型的な例です。自動マウントのパス
/net/<host>の形です。ただし、そのホストの自動マウント配下のディレクトリでClaude Codeを起動した場合は例外になります。ローカルに見えて実体がネットワークのパス
シンボリックリンクやジャンクションを経由してネットワークの場所へ届くパスです。
3つ目が見落としやすい点です。ローカルのパスに見えても、リンクをたどった先がネットワーク上なら同じく拒否されます。「共有へのシンボリックリンクをローカルに作って渡す」という抜け道は、そのままでは使えません。
逆に、ネットワークパスとは数えられないものが2つあります。
| パスの種類 | 扱い |
|---|---|
マップ済みのドライブ文字(Z:\など) | 扱いネットワークパスに数えない |
\\wsl$のパス | 扱いネットワークパスに数えない |
回避策の根拠はこの表の1行目です。共有の実体が同じでも、ドライブ文字として見せれば、拒否の対象から外れます。
Windowsでの直し方 — ドライブ文字に割り当てて起動時に渡す
手順は2段です。
ドライブ文字経由で追加する
- 1
共有をドライブ文字に割り当てる
net useでZ:などに割り当てます。 - 2
起動時に--add-dirで渡す
claude --add-dir Z:\のように、起動の引数として指定します。
net use Z: \\server\share
claude --add-dir Z:\警告文の括弧書きにあるとおり、渡すのは起動時です。セッション中に/add-dir Z:\で足したドライブ文字には、まだ「リモート読み取りの信頼」が付きません。ドライブ文字を割り当てたのに読めない場合は、いったん終了して--add-dir付きで起動し直すのが筋です。
--add-dirは複数のパスを並べて渡せるので、他のディレクトリと一緒に指定できます。
claude --add-dir Z:\ ..\shared-libなお、--add-dirはパスが実在するディレクトリであることも検証します。割り当てたドライブが切断されていると、ネットワークパスの拒否とは別の理由で追加に失敗します。net useの接続が生きているかを先に確かめてください。
macOSとLinuxでの直し方
ネットワークのマウントを、ローカルのパスに載せてから追加します。/net/<host>のような自動マウントのパスを直接渡す代わりに、SMBやNFSの共有を普段使っているローカルのマウントポイントに出し、そのパスを渡します。
# 例: マウント済みの共有をローカルパスで追加する
claude --add-dir /mnt/projectsマウント自体はmountコマンドやOSの機能で行います。そのやり方はClaude Codeの範囲外で、環境によって違います。ここで効くのは、Claude Codeに渡すパスが\\や/net/<host>ではなく、ローカルのパスの綴りになっていることです。
設定ファイルに書いてしまっている場合
permissions.additionalDirectoriesに、UNCや/net/<host>のパスを書いていると、起動のたびに同じ警告が出ます。これを止めるには、そのパスを書いている設定ファイルから該当エントリを消します。
{
"permissions": {
"additionalDirectories": ["../docs/"]
}
}ユーザー設定、プロジェクト設定、ローカル設定のどこに書いたかで、消す場所が変わります。メッセージにパスが出るので、grepなどで設定ファイルを探すと見つかります。
なお、プロジェクトの.claude/settings.jsonにあるadditionalDirectoriesは、ワークスペースのトラストを承認するまで有効になりません。ネットワークパスの警告とは別の理由で無視されることがあり、その場合のメッセージは「Workspace has not been trusted」です。切り分けは専用の記事にあります。
似て見えるほかのメッセージとの違い
ネットワークパスに関するメッセージは、出る場面が違います。
| メッセージ | 止まるもの | 主な対処 |
|---|---|---|
| is a network path, which cannot be added as a working directory | 止まるもの作業ディレクトリへの追加 | 主な対処ドライブ文字、ローカルのマウント |
| path names a network location | 止まるものworktree隔離中のセッションの書き込み | 主な対処実体のあるローカルパスで指定 |
後者は、隔離されたworktreeのセッションが、チェックアウトの外にある共有へ書こうとしたときのガードです。原因も直し方も別なので、path names a network locationの記事を見てください。今回の警告は、worktreeの有無とは関係なく、追加の段階で出ます。
バージョンによる挙動の違い
この拒否はv2.1.257(2026年9月1日)で入りました。v2.1.257より前は、到達できるネットワークパスなら作業ディレクトリとして受け付けていました。アップデートしたら急に警告が出始めた、という場合はこの変更が理由です。v2.1.257のリリースノートに、同じ版の変更がまとまっています。
その後のv2.1.273(2026年9月15日)では、Windowsで--add-dirにマップ済みドライブを加えたときの、UNCパスに対する権限チェックが改善されました。ドライブ文字の経路が前提の仕様なので、この回避策を使う人ほど恩恵を受けます。
同じ考え方がほかの機能にも及んでいる
ネットワーク共有を信頼の境界として扱う方針は、作業ディレクトリの追加だけの話ではありません。v2.1.284(2026年9月28日)では、アーティファクトの公開で、ネットワーク共有(\\host\shareや/netの自動マウント)上のファイルを、--add-dirで加えたマップ済みネットワークドライブ上にある場合を除いて拒否するようになりました。ここでも、通る条件は「マップ済みドライブとして--add-dirで渡されていること」です。
ドライブ文字経由の追加は、はじめから動いていたわけでもありません。v2.1.133(2026年5月7日)では、--add-dirやSDKのadditionalDirectoriesで渡したマップ済みドライブで、Read・Write・Editが拒否される不具合が直っています。マップ済みドライブの扱いは版を重ねて整えられてきた領域なので、挙動がおかしいときは版を確かめる価値があります。
追加後に知っておきたいこと
ドライブ文字経由で追加できても、扱いは通常の追加ディレクトリと同じです。ファイルは権限ルールに従い、読み取りは確認なしで通り、編集の可否は現在の権限モードで決まります。ディレクトリ内の.claude/設定は、スキルなど一部を除いて読み込まれません。
/add-dirで追加した場合はDirectoryAddedフックが走りますが、--add-dirの起動フラグで渡したディレクトリでは走りません。ドライブ文字経由の追加は起動時に行うので、追加の監査をフックに頼っている構成では、こちらの経路が対象外になる点に注意してください。仕組みはDirectoryAddedフックの記事で扱っています。
作業ディレクトリの外を読ませたくない運用なら、追加を絞るだけでなく、作業ディレクトリ外の読み取りを一括で禁止する設定と組み合わせる方法もあります。
切り分けの早見表
| 状況 | 見る点 |
|---|---|
/add-dirで即座に拒否される | 見る点パスがUNCか/net/<host>か |
| 起動時に警告が出てセッションは立ち上がる | 見る点設定のadditionalDirectoriesにネットワークパスがないか |
| ドライブ文字を割り当てたのに読めない | 見る点起動時の--add-dirで渡したか(セッション中の追加では信頼が付かない) |
| ローカルのパスなのに拒否される | 見る点シンボリックリンクやジャンクションが共有を指していないか |
| 古い版では通っていたのに、今は拒否される | 見る点v2.1.257以降の仕様か |
まとめ
ネットワークパスが作業ディレクトリに入らないのは、パスを調べるだけでホストに接続し、Windowsでは認証情報が渡りうるためです。直し方は、パスの綴りをネットワークの形からローカルの形へ変えることに尽きます。Windowsはnet useでドライブ文字に割り当てて起動時に--add-dirで渡し、macOSとLinuxはローカルのマウントポイント経由にします。