chrome devtools mcpをインストールして使うと新しいブラウザが起動します。そのため、ボットだと認識されてブロックされたり、開発段階でログインが必要なサービスの場合にCookieが保持されず、ログイン処理まで複雑になったりして、きちんとテストや開発ができないことがよくあります。 別のサイトに書かれていた記
chrome-devtools mcpをインストールして使うと新しいブラウザが起動します。そのため、ボットだと認識されてブロックされたり、開発段階でログインが必要なサービスの場合にCookieが保持されず、ログイン処理まで複雑になったりして、きちんとテストや開発ができないことがよくあります。
[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest"]
startup_timeout_sec = 30.0別のサイトに書かれていた記事を読んだところ、既存のブラウザでdebug portを開いて接続できるようにしていました。それで、私もその方法を適用することにしました。 ただし、この方法にはセキュリティ上のリスクがあるかもしれませんが、そもそもChrome Dev.appを起動するので、まだ大丈夫そうな気もします。
方法を説明すると（Mac OSの場合です）。
Automatorアプリを起動する。#!/bin/bash
open -a "Google Chrome Beta.app" --args \
--ignore-certificate-errors \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.chrome-debug-profile" \
--no-first-run \
--no-default-browser-checkGoogle Chrome Beta Debug.appという名前でアプリを保存し、/Applicationsのパスに入れる。
これで、debug portを使って起動するブラウザの設定は完了です。
ところが、MacOSには妙なところがあって、--user-data-dir=/tmp/atlas-mcpを設定せずにデフォルトのプロファイルで起動すると、どうやってもdebug modeが有効になりません……（これを知らずに何時間も試行錯誤しました。Windowsではそうではなかったと思うのですが ㅡㅡ）
最後に、codexのconfig.tomlで引数を変更すれば完了です。
[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9222", "--headless=false", "--acceptInsecureCerts=true"]
startup_timeout_sec = 30.0browser-urlオプションのほかにも、いくつかのオプションを一緒に設定しておきます。
その後、codex cliで「ブラウザで該当のページにアクセスして」と指示すると、すでに開いているdebug chrome dev profileでアクセスするため、あらかじめそのページにログインしておけば、ログイン済みの状態でページが開きます。そのため、cliを通じて問題を見つけて解決することが問題なくできます。
これはセキュリティ上の問題になる可能性がありますが、そもそもdebug portには外部から接続できないと認識しています。内部ネットワーク（ローカル）からのみ接続できます。（Windowsではそうでした）
そのため、大きな問題にはならないと思いますが、念のため、セキュリティ上の危険や問題があり得るということだけは認識しておくとよいでしょう。あるいは、Chrome DevまたはChrome Betaを別途インストールして、プロファイルを分けて起動するようにすれば、まだ安心かもしれません。