Claude Codeが60秒で起動失敗するときに疑う一因——設定ファイルの //c/ がWindowsでUNCパスに化ける

Cursor（VS Code系のエディタ）から Claude Code を起動しようとすると、毎回きっかり60秒待たされた末に、このエラーで落ちて開けなくなりました。

認証は正常、回線も生きているのに60秒でタイムアウトする——この症状で検索してたどり着いた方のために、まず切り分けと直し方から書きます。ただしこのタイムアウトの原因は一つではないので、はじめに「自分のケースが当てはまるか」を確認できる形にしました。理屈やハマった経緯は、その後ろにまとめています。

まず確認：このエラーの原因は一つではありません

先にお断りしておくと、Subprocess initialization did not complete within 60000ms というタイムアウトは、原因が一つに決まっているわけではありません。エラー文が示すとおり、認証やネットワーク周りなど別の要因でも同じ60秒タイムアウトは起こり得ます。この記事が扱うのは、そのうちの一つの原因——設定ファイルにうっかり //c/ のようなパスを書いていたケースです。

まず settings.json の additionalDirectories を開き、パス先頭が //（スラッシュ2つ）で始まる項目があるか確認してください。無ければ、本記事は当てはまりません（認証・ネットワークなど別の原因を当たってください）。あれば、それがおそらく犯人です。ドライブレター＋単一スラッシュ（C:/）に、次のように直します。

この表記が原因であれば、これで起動します。permissions.allow 側の Read(//c/...) など他の箇所も、ついでに C:/ 表記へ揃えておくと安心です（そちらが無害な理由は後述）。逆に、そもそも // 始まりの項目が無かったなら、原因は別のところにあります——認証やネットワーク周りなどを当たってみてください。

なぜ60秒も固まるのか

まず前提を一つ。Git Bash（Windows 向けの Unix 風シェル）では、C: ドライブを /c/…——スラッシュ1つ——と書きます。Git Bash 利用者には見慣れた記法で、これを Git Bash が C:\… に読み替えてくれます。今回まぎれ込んでいたのは、それが //c/… とスラッシュ2つになった形でした。私の環境では、settings.json を Claude Code と一緒に整理していく過程で、この Git Bash 風のパスが混ざっていたようです（本来は /c/、それがスラッシュ1つ多かっただけ）。

問題は、この“スラッシュ1つの差”です。Windows では、先頭のスラッシュ（またはバックスラッシュ）2つは UNCパス（ネットワーク共有）を意味します（Microsoft のパス形式ドキュメント）。UNCパスとは \\サーバー名\共有名\… の形式で、LAN内の別マシンの共有フォルダを指す書き方のこと。Windows は URL のようなスラッシュもバックスラッシュに直して扱うので、//c/ は \\c\ と同じ意味になります。つまり //c/Users/… は、拡張機能が起動するネイティブの claude.exe にとって \\c\Users\… ＝「c という名前のネットワーク共有を探してこい」という命令に化けます（/c/ とスラッシュ1つなら C: ドライブに読み替えられますが、2つだと別物です）。

そんな共有はどこにも無いので、Windows はネットワーク越しにホスト「c」を探しに行ったまま応答が返らず、処理がブロックします。そこへ Claude Code 側の初期化タイムアウト（60秒）が落ちて、起動を打ち切る——これが「毎回きっかり60秒」の正体でした。60秒という数字は SMB の待ち時間ではなく、Claude Code が subprocess の起動を待つ固定の制限時間です（エラー文の「within 60000ms」がそれ）。この不具合は Claude Code の公式リポジトリにも報告があります（issue #60025）。エラー文の “network connectivity” は誤誘導ではなく、文字どおりネットワークを探しに行っていたことを指しています。

なぜ additionalDirectories だけが固まるのか

ややこしかったのは、同じ //c/ という表記を settings.json の別の場所（permissions.allow の Read(//c/...)）にも書いていたのに、そちらは何も問題を起こしていなかった点です。同じ文字列なのに、片方だけがハングする。

違いはここでした。additionalDirectories は「実在するディレクトリ」として解決されるので、UNCに化けてネットワークを探しに行く。一方 Read(//c/...) は許可リストのパターン照合に使われるだけで、ファイルシステムにもネットワークにも触れない。だから前者だけが固まる。この非対称に気づけたのが突破口でした。

原因にたどり着くまで（約4時間）

原因が分かってしまえば一行の話ですが、そこへ着くまでに4時間ほど溶かしました。しかも最初に疑ったのは、設定ファイルではなく全然別のところです。

使用量を表示する機能まわりを疑ってみたり、ちょうど別のセッションで Shopify CLI に接続していたので「セッションの取り合いのようなものでは？」と考えたり。しばらく見当違いの方向を掘っていました。

転機は、settings.json のシンボリックリンク（Dropboxに置いた共通設定への参照）を試しに切ってリンク切れにしたら、あっさり起動したことです。設定を読み込まなくなった＝問題の記述も一緒に消えた、ということなので、犯人は設定ファイルの中身だと絞り込めました。

そこからは MCP接続を切ってみたり、細かい項目を調整したり——最初はずっと Claude 自身に任せて探させていたのですが、決め手に欠けました。最後は腹を括って手作業に切り替え、設定ファイルのコードを少しずつ削っては起動を試す、を繰り返しました。いわば設定ファイルの二分探索です。エラーが消えた瞬間に残っていた差分——それが、あの //c/ でした。

持ち帰った教訓

• Windows ではパス先頭の // は地雷。設定ファイル・スクリプト・CLI引数、どこに書いてもUNCパスに化けうる。
• 「起動がちょうど60秒（＝キリのいい固定値）で死ぬ」は、処理が重いのではなく、何かがブロックしてツール側の固定タイムアウトに達したサイン。“重い”のではなく“待たされて打ち切られている”。今回その“何か”はネットワーク探索でした。
• エラーの “network connectivity” は額面どおり受け取ってよかった。素直にネットワーク経路を疑うのが近道だった。
• 原因不明の設定バグは、AIに任せきりにするより、設定を少しずつ削る二分探索で「どの記述を消したら直るか」を見るのが結局いちばん速い。
• 設定ファイルを複数PCで同期している場合、1箇所の表記ミスが全機に伝播する。共有する設定ほど表記を揃える。

同じエラーでここへたどり着いた方は、まず設定ファイルの先頭 // を疑ってみてください。それで直れば何よりです。違っていたら、原因はほかにあります——認証やネットワーク周りを、落ち着いて当たってみてください。

この記事のような環境トラブルの切り分けは、受託の現場でClaude Codeを実務運用するための一領域です。任せ方の線引き・権限の設計・本番反映の作法まで、全体像は「Claude Code実務運用ガイド」にまとめています。