Claude CodeのChrome連携とplan mode — 確認が出る操作と出ない条件
plan modeでChrome連携を使うと、GIF録画・新規タブ・ショートカット実行の前に確認が出ます。tabs_context_mcpのcreateIfEmptyやbrowser_batchの扱い、確認が出なくなる条件を確かめます。
plan mode(計画だけを立てて、承認までファイルを編集しないモード)のまま claude --chrome でブラウザを動かすと、途中で確認が挟まります。確認が出るのは、GIFの録画、新しいタブを開く操作、ショートカットの実行の3つです。ここでは、確認が出る操作の範囲と、確認が出なくなる条件を順に示します。
plan modeで確認が出るブラウザ操作
Chrome連携のドキュメントは、plan modeでの扱いを1つの節にまとめています。内容は次のとおりです。
plan modeで確認が出る操作
GIF録画
録画を始める前に、権限プロンプトが出ます。
新しいタブを開く
Claudeがタブを新規に作る前に確認が入ります。
ショートカットの実行
ショートカットを走らせる前に確認が入ります。
3つに共通するのは、ブラウザの状態を変えたり、画面の内容を記録したりする操作であることです。plan modeは「調べて計画を書く」ためのモードなので、ブラウザ側の状態変更も計画段階では勝手に進めない、という設計に沿っています。
確認が出る3操作のほかに、2つの呼び出しが対象に加わります。
tabs_context_mcpがcreateIfEmptyを指定したときbrowser_batchが上の操作を1つでも含むとき
tabs_context_mcp は、いま開いているタブの一覧を取る呼び出しです。普通に一覧を読むだけなら確認は出ません。createIfEmpty を付けると、タブが1枚もないときに新しいタブを作ってしまうため、実質「新しいタブを開く」と同じ扱いになって確認が出ます。
browser_batch は複数の操作を1回の呼び出しにまとめる仕組みです。バッチの中にGIF録画・新規タブ・ショートカットのどれかが混じると、バッチ全体が確認の対象になります。
読み取りだけの操作は止まらない
確認が出る範囲は、読み取り専用の操作までは広がりません。変更履歴には、plan modeで状態を変えるブラウザツールの呼び出しが確認なしで通ってしまう不具合の修正が載っており、同じ項目に「読み取り専用の browser_batch は自動で許可される」とあります。リリースの文脈はClaude Code v2.1.199のリリースノートにまとめています。
つまり、plan modeでページの内容を読む、コンソールログを見る、といった調査は途切れにくい作りです。計画を立てる前にブラウザで現状を確かめたい場面とは相性がよい挙動です。
確認が出ない条件はひとつだけ書かれている
同じ節に、確認が出なくなる条件が1つだけ書かれています。次の2つがそろったときです。
- 対話式のCLIセッションで、bypass permissions mode(権限確認を飛ばすモード)が使える状態にある
- feature-flag fetching(Anthropicからの機能フラグ取得)がオフになっている
両方を満たすと、上の呼び出しは確認なしで実行されます。それ以外の構成、たとえばVS Code拡張のチャット画面や -p による非対話実行では、plan modeの確認が維持されます。
bypassが「使える」とはどういう状態か
bypass permissions modeは、起動時に有効化したセッションでだけ選べます。有効にする方法は、permissions.defaultMode に bypassPermissions を設定するか、起動フラグを付けるかの2通りです。
claude --permission-mode bypassPermissions--dangerously-skip-permissions も同じ意味です。plan modeで始めたまま後からbypassへ切り替えたいときは、--allow-dangerously-skip-permissions を併用して、Shift+Tab の切り替え順にbypassを加えます。
claude --permission-mode plan --allow-dangerously-skip-permissions --chromeこの起動方法なら、plan modeで始めつつ「bypassが使える」状態になります。ただし、それだけではChromeの確認は消えません。もう1つの条件であるフラグ取得のオフが必要です。
feature-flag fetchingがオフになる場面
環境変数のドキュメントによると、Claude Codeは次の場合にフラグ取得を行いません。
DISABLE_GROWTHBOOK、DISABLE_TELEMETRY、DO_NOT_TRACK、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICのいずれかを設定したセッション- Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryなどサードパーティプロバイダーのセッション
- Claude apps gatewayのセッション
変数ごとに、フラグ取得が止まる値が違います。たとえば DISABLE_GROWTHBOOK は 1 か true で止まり、0 や false ならそのままです。一方 DISABLE_TELEMETRY と CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC は、0 や false を入れても無効化されるままになります。設定した値の意味は、変数表の該当行で確かめてください。
なお、Chrome連携そのものはBedrockなどのサードパーティプロバイダーでは使えません。そのため、フラグ取得のオフが現実に効いてくるのは、テレメトリ関連の変数を入れている環境です。
確認が出るのは仕様か不具合か
「plan modeなのに毎回聞かれる」と感じたときは、次の順で切り分けると早く判断できます。
plan modeの確認プロンプトの切り分け
- Q操作は GIF録画・新規タブ・ショートカットのどれかですか?答えがいいえのとき答えがはい
読み取り専用の操作は確認が出ないはずです。出ているなら、
browser_batchの中に上の操作が混じっていないか、tabs_context_mcpにcreateIfEmptyが付いていないかを見ます。 - Qセッションは対話式のCLIですか?答えがいいえのとき答えがはい
VS Codeのチャット画面や
-pの非対話実行では、plan modeの確認は維持されるのが仕様です。 - Qbypass permissions modeが使える状態で起動していますか?答えがいいえのとき答えがはい
起動時にbypassを有効にしていないと、確認は消えません。上の起動フラグか
defaultModeを見直します。
フラグ取得の状態を確認する
テレメトリ関連の変数を入れていなければ、フラグ取得はオンのままで、確認が出るのが仕様です。
注意したいのは、確認が出ないほうが「意図した状態」とは限らないことです。bypassは権限確認と安全チェックの両方を外すモードで、ドキュメントは、コンテナやVMなど隔離された環境でだけ使うよう警告しています。Chromeの確認を消すためだけにbypassを有効にする運用は、確認を減らす対価としては大きすぎます。
bypass以外で確認を減らす道
plan modeの確認を、権限の仕組みの外から消す方法はドキュメントに書かれていません。確認の回数を減らしたいときは、Chrome連携側の既存の仕組みを使うことになります。
サイト単位の許可はChrome拡張機能に残る
サイト単位の許可は、Chrome拡張機能の設定から引き継がれます。どのサイトをClaudeが閲覧・クリック・入力してよいかは、拡張機能の設定で管理します。plan modeの確認とは別の層なので、サイトを許可しても、GIF録画や新規タブの確認が自動で消えるわけではありません。
許可プロンプトの「保存」の中身
確認ダイアログで選べる「今後は聞かない」系の選択肢が何を保存するかは、別の記事に整理があります。Chromeの確認で同じ許可を繰り返したくなったら、許可プロンプトで何が保存されるかを先に読むと、期待と実際のずれを避けられます。
確認を入れたまま使う
plan modeの確認は、計画段階で意図しないブラウザ操作が走るのを防ぐ安全装置です。実運用では、確認を受け入れる前提で指示を組むほうが現実的です。
たとえば、GIF録画を含む操作は計画の最後にまとめます。調査はplan modeのうちに読み取りだけで済ませ、録画や新規タブを要する作業は、計画を承認して通常のモードに入ってから実行する、という分け方です。plan modeそのものの使い方はPlan modeの解説記事にあります。
指示の書き方で確認の回数を減らす
確認の回数は、Claudeに渡す指示の組み立てでも変わります。公式の説明を組み替えた例として、次のような指示の分け方が考えられます。
plan modeでのブラウザ作業の指示
1つの指示にまとめる
「ログインページから決済確認画面までをGIFで録画して、失敗したらコンソールログも見て」と一度に頼みます。録画の確認と新規タブの確認が、計画の途中で割り込みます。
読み取りと録画を分ける
先に「現在のタブのコンソールログとDOMの状態を読んで、原因の候補を計画に書いて」と頼みます。録画は承認後の実行フェーズで頼みます。
上の例は、確認が出る操作と出ない操作の線引きから組み立てた使い分けです。公式がこの分け方を勧めているわけではないため、手元の運用に合わせて調整してください。
つまずいたときの見分け方
よくある疑問は3つあり、いずれも症状から入ると見分けやすくなります。
新規タブを開かない指示でも確認が出た
指示にタブの作成が含まれていなくても、tabs_context_mcp が createIfEmpty を付けて呼ばれていれば確認が出ます。Chromeにタブが1枚もない状態で始めると起きやすい形です。作業前にChromeを起動して、何かページを開いておくと避けられる場合があります。
バッチ呼び出しが丸ごと止まった
browser_batch は、中の操作を1つでも確認対象に含むと全体が確認の対象になります。確認ダイアログで承認すれば、バッチは通常どおり進みます。承認を拒否したときの細かな挙動は、ドキュメントに記載がありません。
auto modeを使っていると状況が変わるか
plan modeの中の「シェルコマンド」の扱いは、auto modeが使えて useAutoModeDuringPlan が有効な場合、分類器が審査する形に変わります。ただし、この説明はシェルコマンドについてのものです。Chromeのブラウザツールがplan modeでこの分類器の対象になるかどうかは、Chrome連携のページには書かれていません。
接続自体が失敗するときの切り分けは、plan modeとは別の話です。Chromeに接続できないときの原因と対処を参照してください。
まとめ
plan modeでブラウザの確認が出るのは、GIF録画・新規タブ・ショートカットと、それらを含む tabs_context_mcp の createIfEmpty や browser_batch の呼び出しです。読み取りだけの調査は止まりません。確認が消えるのは、対話式のCLIでbypassが使え、かつフラグ取得がオフの場合に限られます。
確認を消すためにbypassを選ぶ前に、操作を「読み取り」と「録画・タブ作成」に分けて、後者を承認後に回せないかを検討する流れが、いちばん副作用の少ない進め方です。GIF録画そのものの手順はGIF録画の記事にあります。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。