はじめに
普段、Claude Code から chrome-devtools-mcp 経由でブラウザを操作して、ローカル環境の動作確認を自動化することがあります。
その中で、昨日まで普通に動いていたのに、ある日突然ツール呼び出しが一切通らなることがあり、原因が3つ重なっていて切り分けに苦労したので、備忘録として残しておきます。
同じ症状で悩んでいる人の助けになれば幸いです。
問題
症状は「MCPのツール呼び出しが永遠に返ってこない」ことでした。
許可プロンプトすら出ないので、設定の問題かと思っていたのですが、allowlist には登録済みなことを確認しました。
この時点では/mcp で再接続しても症状は直りませんでした。
切り分け
切り分けは次の順で進めました。
-
ps aux | grep chrome-devtools-mcp→ 過去セッションの残骸プロセスが8個残っていた。全部 kill したが直らない - ハーネスを介さず stdio に直接 JSON-RPC を流すと、
initializeは返るのに
tools/call（list_pages）だけ返らない。MCPサーバーではなく Chrome 側が怪しい -
curl http://127.0.0.1:9222/json/versionが無応答。TCP は ESTABLISHED なのに HTTP が返らない。Chrome の CDPエンドポイント自体が固まっていた - Chrome を
--remote-debugging-port=9222付きで再起動 → 今度はポート自体が開かない
最後のやつが本命でした。
DevToolsActivePort ファイルの更新日時が前日のままで、調べると Chrome 136
以降はデフォルトプロファイルでのリモートデバッグが無効化されている（セキュリティ対応。Cookie窃取対策らしい）。
昨日まで動いていたのは、自動更新が当たる前のバイナリで起動した古いプロセスが生き残っていただけで、再起動した瞬間に新仕様が適用されたというオチでした。
解決方法
公式が案内している通り、デバッグ専用のプロファイルで別インスタンスを立てる。
open -na "Google Chrome" --args \
--user-data-dir="$HOME/.chrome-devtools-profile" \
--remote-debugging-port=9222 \
--no-first-run --no-default-browser-check
あわせて MCP 側の接続方法も変える必要があります。
--autoConnect はデフォルトプロファイルの DevToolsActivePortしか見に行かないので、専用プロファイル方式ではポート直指定にします。
{
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest", "--browserUrl", "http://127.0.0.1:9222"]
}
これで /mcp から再接続すれば復旧します。
プロファイルは --user-data-dirに永続化されるので、テスト対象へのログインは初回だけで済みます。
おわりに
「昨日まで動いていたのに」系の障害が起こった時は、何かの更新が裏で走っていないかまずは確認しようと学びました。
今回は Chromeの自動更新と古いプロセスの生き残りが重なって、原因が3層（残骸プロセス / CDP の詰まり / 仕様変更）に分かれていたのが厄介でした。
ハーネス越しに見えるエラーだけで判断せず、stdio 直叩き → curlと一層ずつ降りていくのが結局近道でした。