起動時フックが増えすぎてエージェントが立ち上がらなくなるのを直す

誰向けか

Claude Code（や同種の CLI エージェント）に SessionStart / 起動時フックを足し続けていて、ある日から Subprocess initialization did not complete within 60000ms — check authentication and network connectivity が全タブ・全セッションで出るようになった人。

最初に知るべきこと：このエラーメッセージは嘘をつく

メッセージは「認証とネットワークを確認しろ」と言うが、その2つが原因であることはまずない。 初期化の時間には次が全部乗る:

• 起動時フック（SessionStart）の実行時間の合計
• MCP サーバーの接続時間（失敗した場合はそのタイムアウト時間まるごと）

フックは1本ずつ足されていくので、誰も合計を見ていない。上限（既定 60 秒）を越えた日から 再現するようになる。認証を調べに行くと何時間も溶ける。

手順1: 合計時間を測る（これをやらずに直さない）

設定ファイルの起動時フックを1本ずつ実行して、ミリ秒を足す。フックは stdin から JSON を受け取るので、 本番と同じ形で渡すこと。

echo '{"hook_event_name":"SessionStart","source":"startup"}' | <フックのコマンド>

設定から全部読んで自動で回す例（Node）:

const {execSync} = require('child_process');
const d = JSON.parse(require('fs').readFileSync('<設定ファイルのパス>', 'utf8'));
let total = 0;
for (const m of d.hooks.SessionStart || []) for (const h of m.hooks || []) {
  const t = Date.now();
  try { execSync(h.command, {
    input: '{"hook_event_name":"SessionStart","source":"startup"}',
    stdio: ['pipe','pipe','pipe'], timeout: (h.timeout || 10) * 1000 });
  } catch (e) {}
  const ms = Date.now() - t; total += ms;
  if (ms > 2000) console.log('SLOW ' + ms + 'ms  ' + h.command);
}
console.log('TOTAL ' + (total/1000).toFixed(1) + 's');

実例では 32 本で合計 93 秒、うち3本（依存収束 45.6s / コスト集計 18.9s / ツール導入チェック 10.0s）で 74 秒を占めていた。

手順2: timeout を削るのは間違い

各フックの timeout を下げても、やっている仕事は減らない。途中で殺されるだけで、 本来その処理がやるはずだった収束・同期が静かに失われる。直し方は2つしかない。

A. 出力が要らないフック → 裏に回す（detached 起動）

副作用のためだけに走るフック（環境の収束、同期、自己修復）は、即座に終了して裏で走らせる。 汎用ラッパを1本作れば全部これで包める。

// bg-launch.mjs — 渡されたコマンドを detached で起動して即 exit
import { spawn } from 'child_process';
const [cmd, ...args] = process.argv.slice(2);
spawn(cmd, args, { detached: true, stdio: 'ignore', windowsHide: true }).unref();
process.exit(0);

設定側は bg-launch.mjs <元のコマンド> に置き換え、timeout も小さくする。 処理を消したわけではないので、裏でプロセスが本当に生きているかを ps / tasklist で一度確認すること。

B. 出力が要るフック → cache-first にする

起動時に内容を表示するフック（コスト集計、状態サマリー）は消せない。 前回の出力をそのまま保存しておき、起動時はそれを即座に出す。再計算だけ裏に回す。

--cached が指定された:
  キャッシュがある  → 中身をそのまま stdout に出して exit 0（1秒未満）
                      + フル計算を detached 子プロセスで起動（ロックで二重起動を防ぐ）
  キャッシュが無い  → 従来どおり同期でフル計算し、その出力をキャッシュに保存

表示は「前回の値」になるので、出力フォーマットは1文字も変えないこと（変えると差分が 「古い値」なのか「壊れた」のか判別できなくなる）。実例では 18.9 秒 → 0.5 秒。

手順3: MCP サーバーの起動方式も見る

stdio MCP サーバーの command を npx / args ["-y", "<パッケージ>"] にしていると、 毎回パッケージ解決に行くため（特に Windows で）接続上限 30 秒に間に合わず、 毎セッション CONNECT_TIMEOUT で落ちる。しかもその 30 秒は初期化時間に丸ごと乗る。

直し方: グローバル導入して実体を直接叩く。

npm i -g <パッケージ>
# 設定を command: "node", args: ["<...>/node_modules/<パッケージ>/dist/index.js"] に変更
# 環境変数（APIキー等）は必ずそのまま維持する

検証は initialize ハンドシェイクを直接投げて秒数を測る:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}

実例では 30 秒（タイムアウト）→ 0.44 秒。

落とし穴

• 修正の確認は「新しいタブ／新しいセッション」で行う。 既に開いているセッションは起動時の状態を 表示し続けるので、直してもエラー表示は消えない。「直っていない」と誤判定しやすい。
• 速くなった観測値を、速くなった理由と取り違えない。 フラグを渡す側の設定だけ直して、 スクリプト側に実装が無くても、未知の引数は黙って無視されるのでエラーにならない。 さらに元から「N時間以内はスキップ」のようなガードがあると、そのガードに当たっただけで速く見える。 実例ではこれで「直った」と誤報告した。速いときこそ、遅い経路が走らなかっただけでないかを先に潰す。 確認は「実装したと言うならファイルを grep」「速いと言うならキャッシュとガードを消してから計測」。
• 再発防止: 起動時フックの合計が上限の半分を超えたら警告する仕組みを入れておく。 フックは今後も増えるので、同じ壁に必ずまた当たる。

効果

実例（フック32本）: 合計 93 秒 → 18.7 秒。MCP 接続 30 秒 → 0.44 秒。 処理は1つも削っていない。