Claude Codeがautofs環境で起動に数分かかる原因と回避策

Claude Codeの起動に数十秒から数分かかり、VS Code拡張では「Subprocess initialization did not complete」で落ちる。しかも作業ディレクトリは大学や研究所のクラスタ上にある。この組み合わせなら、原因は認証やネットワークではなく、autofsの自動マウントである可能性があります。

GitHubの報告(anthropics/claude-codeのissue #95804)によると、作業ディレクトリの祖先にautofsのワイルドカードマップがあると、起動時の探索が存在しない名前を大量に問い合わせます。そのたびにautofsがNFSマウントを試み、1名前あたり23秒から2分以上待たされます。

autofsのワイルドカードマップで起動が止まる症状

症状が出るのは、作業ディレクトリの親のどこかが「ワイルドカードエントリを持つ間接マップ」のautofsルートになっている環境です。issueの報告者の例では、/gが次のようなマップです。

# /etc/auto.master
/g  /etc/auto.g
 
# /etc/auto.g
*   &:/vol/&

*は「どんな名前が来ても、その名前のホストの/vol/<名前>をマウントする」という意味になります。HPCクラスタのファイル共有でよく見る構成です。issueには、ワイルドカードマップやプログラムマップなら再現し、標準の/net -hostsも含むと書かれています。

見え方は次のとおりです。

• claude -p "ok"のようなCLI起動が、報告者の環境で約30秒かかる
• 初回は遅く、直後にもう一度起動すると1秒ほどで立ち上がる
• 数分空けると、また遅くなる
• VS Code拡張が60秒のタイムアウトで失敗する

直後の再起動だけ速いので、「たまに遅い」というネットワーク不調のような見え方になります。報告者によれば、これはautofsが失敗した名前を約60秒覚えている(負のキャッシュ)ためです。

起動時の祖先ディレクトリ探索が何を引き起こすか

Claude Codeは、起動時に作業ディレクトリとその上位のすべてのディレクトリを順にたどり、設定や指示のファイルを探します。公式のメモリのドキュメントには、CLAUDE.mdとCLAUDE.local.mdは作業ディレクトリとその上位ディレクトリから読み込まれ、CLAUDE.mdがどこにも無いときは上位ディレクトリのAGENTS.mdも読むと書かれています。

この探索は、存在しないファイルに対するstat系のシステムコールです。通常のファイルシステムなら一瞬でENOENT(存在しない)が返ります。ところがautofsのルート直下では、存在しない名前の参照が「その名前のマウントキーが指定された」と解釈されます。結果としてmount.nfs CLAUDE.md:/vol/CLAUDE.mdのようなプロセスが起動します。

issueのstrace -fでは、作業ディレクトリ/g/stegle/aivazidisから起動したとき、autofsルート/gの直下で次の名前が探索されていました(v2.1.278)。

v2.1.280での再確認では、/g/.rgignoreと/g/.gitignoreも探索されていました。探索される名前はCLAUDE.mdだけではないため、ファイル名ごとの対処では追いつきません。

遅さを増幅しているのが、名前そのものです。.mdは実在するトップレベルドメインなので、claude.mdやagents.mdはホスト名として解決できます。報告者の環境ではclaude.mdがAnthropic側のインフラのアドレスに、agents.mdが第三者のアドレスに解決されました。autofsは実際にそのホストへNFSとportmapperのRPCを送り、再試行がすべて失敗するまで待ちます。stat /g/CLAUDE.mdが23秒、stat /g/AGENTS.mdが3分3秒という計測値は、この待ちの長さです。

探索は主スレッドで順番に実行されます。statx()は、マウント試行が失敗するまで割り込めない待機状態(D状態)に入ります。名前が5つあれば、待ちは足し算になります。

自分の環境が当てはまるかを確かめる

原因がautofsかどうかは、起動を遅くしている最中にプロセスを見れば分かります。

作業ディレクトリの祖先にautofsルートがあるかは、マウント一覧で確かめます。

pwd -P
grep autofs /proc/mounts

pwd -Pは物理パスを表示します。grepの結果に、マウント先がpwd -Pの祖先になっているautofsの行があれば候補です。issueでは次の行が示されていました。

auto.in.g /g autofs rw,relatime,fd=30,pgrp=3639,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=93233 0 0

次に、claudeを別のシェルで起動したまま、待ちの正体を見ます。

ps -eo stat,etime,cmd | grep mount.nfs

mount.nfs CLAUDE.md:/vol/CLAUDE.md ...やmount.nfs AGENTS.md:/vol/AGENTS.md ...がD状態で並んでいれば、ほぼ確定です。さらに、システムコールの待ち時間を見たいときはstraceが使えます。

strace -f -tt -T -e trace=statx \
  claude -p "ok" 2>&1 | grep -E "ENOENT.*<[0-9]{2}"

出力の末尾の<23.039426>のような数字が、そのシステムコールで待った秒数です。コマンドの書き方はissueのstrace -f -tt -Tを土台にした例で、grepの条件は読みやすくするために足したものです。環境によりstatxの代わりにnewfstatatが出ることもあるため、何も出ないときは-eの指定を外して全体を眺めてください。

もう一つの見分け方は再現性です。待ちが「初回だけ長く、直後は短い」なら、負のキャッシュが効いています。毎回長いなら、別の原因を疑う余地があります。

VS Code拡張が60秒で失敗する理由

CLIなら遅くても最終的には起動しますが、VS Code拡張では起動自体が失敗します。issueによると、拡張はサブプロセスの初期化に60秒のタイムアウトを持ち、超えると次のエラーになります。

Error: Subprocess initialization did not complete within 60000ms — check authentication and network connectivity

メッセージは認証とネットワークを疑わせますが、報告者の環境では認証トークンは有効で、Anthropicのエンドポイントは0.4秒未満で応答していました。つまり、この文面にだけ従って認証をやり直しても直りません。

もう一つの落とし穴は、同時起動です。複数のセッションを近いタイミングで開くと、すべてが同じ進行中のマウント試行を待ち、そろって失敗します。報告者のログでは、拡張が2.1.278に自動更新された翌日から、このエラーが日に18〜33回出ていました。

拡張の挙動が分からなくなったときの切り分けは、VS Code拡張が応答しないときの手順にもあります。ただし、そちらの確認項目に当てはまらず、HPCのログインノードで起きているなら、まずautofsを疑う価値があります。

効かなかった回避策と、効き目が限られる回避策

ありがちな対処を、issueのコメントにある結果と合わせて並べます。

シンボリックリンク経由で開く。autofsの外側にリンクを作り、そのリンク経由でワークスペースを開く方法は効きません。Claude Codeがgetcwd()の返す物理パスを使うため、祖先の探索は結局autofsルートに到達します。

CLAUDE_CODE_DISABLE_CLAUDE_MDS=1を設定する。この環境変数は、公式のドキュメントでは、ユーザー・プロジェクト・自動メモリを含むCLAUDE.mdのメモリファイルの読み込みを止めるものです。CLAUDE.mdの探索は省けても、次の2点が残ります。

• プロジェクト自身のCLAUDE.mdも読まれなくなる
• .git、.mcp.json、.claudeの探索は減らない

claudeMdExcludesで除外する。公式のドキュメントは、この設定を「メモリの読み込み時に特定のCLAUDE.mdをスキップする」ものと説明しています。探索のstat自体を省くかどうかは、ドキュメントに記載がありません。仮に省けても、.gitや.mcp.jsonの探索は対象外です。設定の書き方はclaudeMdExcludesの設定手順にあります。

作業ディレクトリの選び方を変える。autofsルートが祖先に入っている限り、探索は祖先をすべてたどるため、サブディレクトリの深さは関係ありません。親にautofsルートが来ない場所、たとえばホームディレクトリ配下やローカルディスクにリポジトリを置くと、そもそも探索がautofsに触れません。ただしこれはシステムコールの仕組みから導いた考え方で、issueで検証された方法ではありません。データが共有領域にしか置けない場合は使えないため、次の方法が必要になります。

root権限なしで効いた回避策 — 名前空間でautofsルートを隠す

issueのコメントには、root権限なしで効いた回避策があります。非特権のユーザー名前空間とマウント名前空間の中でClaude Codeを動かし、autofsルートを「いま実際にマウントされている共有だけが見える読み取り専用のtmpfs」に差し替える方法です。

報告者が同じノードで測った結果は次のとおりです。

使えるかを先に確かめる条件が一つあります。非特権のユーザー名前空間が許可されていることです。

cat /proc/sys/user/max_user_namespaces

0より大きければ、この方法の前提を満たします。報告者の環境(EL8)では既定で有効でした。組織によっては制限されていることがあるため、ログインノードのポリシーも合わせて見てください。

ラッパーの置き方は2通りです。VS Code拡張はリモートのマシン設定にclaudeProcessWrapperを指定します。公式のドキュメントでは、起動に使う実行ファイルを指定する設定で、同梱バイナリのパスが引数として渡されると説明されています。

{
  "claudeCode.claudeProcessWrapper": "/path/to/claude-gshim"
}

CLIはエイリアスで包みます。

alias claude='claude-gshim claude'

ラッパーのスクリプト本体(Python 3.6以降、標準ライブラリのみ)は、issue #95804のコメントに全文があります。使うときは次の点に注意してください。

• 起動時にマウントされていない共有は、そのセッションの中から見えない。見たい共有は環境変数で名前を渡す作り
• 設定に失敗したときは、警告を出して元のコマンドをそのまま実行する作り
• あくまで利用者側の回避策であり、公式の機能ではない

根本対策として提案されていること

issueでは、利用者側の回避策とは別に、Claude Code側の修正案が4つ挙がっています。

1. 祖先の探索を、ファイルシステムやマウントの境界で止める。少なくとも/proc/self/mountinfoでfstypeがautofsのエントリは対象外にする
2. 存在しない名前をstatせず、祖先ディレクトリをreaddirで列挙する。autofsの間接ルートを列挙してもキーのマウントは起きない
3. 候補の名前を、短い期限つきで並行に探索する
4. VS Code拡張の60秒のタイムアウトを設定で変えられるようにし、エラー文を認証とネットワークの話に決め打ちしない

この問題はissue #95804が最初ではありません。前身の#82632も同じ原因を報告していましたが、修正されないまま古さを理由にクローズされています。同じ現象に遭遇した人は、クローズされたissueでなく#95804を見れば最新の状況が分かります。

切り分けの早見表

まとめ

HPCや大学クラスタで起動が遅いなら、まずgrep autofs /proc/mountsで祖先にautofsルートがあるかを見て、psでmount.nfsのD状態を探すのが最短です。当たっていれば、リポジトリを置く場所を変えるか、名前空間ラッパーで存在しない名前をautofsに届かせないようにすると、起動が秒単位に戻ります。同じ構成を共有する管理者にも、遅さの原因はClaude Codeの認証ではなく、ワイルドカードマップに届く存在しない名前の参照だと伝えられます。

CLAUDE.mdやAGENTS.mdの読み込みの仕組みそのものは、AGENTS.mdが読み込まれない原因の記事が詳しく、クラスタ上でClaudeを使う全体像はClaude ScienceのHPC接続にあります。