#chrome

最初に見ておきたいのは、これが Windows 系の issue に寄っているかどうかです。今回の報告はどちらも Windows 11 上で、Claude Code の Chrome 連携まわりの native host が起動直後に `ERR_INVALID_ARG_TYPE` で落ちる、という形でした。ひとつは [#57846](https://github.com/anthropics/claude-code/issues/57846)、もうひとつは [#76556](https://github.com/anthropics/claude-code/issues/76556) です。 この症状に当たっているかは、かなりはっきりしています。Claude Code の Chrome 連携を使った瞬間に、拡張機能が「接続されていない」扱いになる。あるいは native host 自体がすぐ死んで、`ERR_INVALID_ARG_TYPE` が見える。どちらも issue 側では Windows 上の再現例でした。少なくとも、今回集められた報告からは macOS や Linux での

Chromeのサイトデータ管理をめぐって、Googleのサイトだけが設定どおりに消えない問題が再び見つかった。しかも今回は、以前いったん直ったはずの話が、別の形で戻ってきたというのが厄介だ。ブラウザのプライバシー設定は、ユーザーが自分の履歴やCookieをどう扱うかを決める土台なので、こうした挙動のズレは見過ごしにくい。この記事では、何が起きたのかを整理したうえで、これをどう受け止めるべきかを考えたい。 記事を書いたJeff Johnson氏は、6年前に「Chrome exempts Google sites from user site data settings」という投稿を公開し、ChromeがGoogle所有のサイトだけを、ユーザーの「自動でサイトデータを削除する」設定から除外していたと報告した。彼によれば、そのときの問題はGoogleに届き、最終的には修正されたという。 今回彼が再び書いたのは、Chromeで似た現象を確認したからだ。Johnson氏はこの問題を2台のMacで再現できたとしており、使ったChromeのバージョンは 152.0.7977.83 だった。検証のため

ブラウザ拡張の世界で、Google が長年進めてきた移行が一つの区切りを迎えました。Chrome Web Store から Manifest V2 の拡張機能がすべて हटされ、その中には多くの人に使われてきた uBlock Origin も含まれています。広告や追跡を避けるために拡張機能を使っている人ほど、この変更の影響は小さくありません。しかも話は Chrome だけに閉じず、Chromium 系ブラウザ全体の使い勝手にも波及します。 元記事が伝えているのは、Google がブラウザ拡張の仕様移行における最後の節目に到達し、Chrome Web Store に残っていた Manifest V2 の拡張機能を削除した、という事実です。Manifest V2 は古い拡張機能プラットフォームで、これに対して Google は新しい Manifest V3 を推進してきました。今回の削除で、Chrome Web Store 上からは V2 の拡張機能を新たに見つけたり入れたりできなくなりました。 記事では、その中でも特に uBlock Origin が含まれている点を強調しています。uBl

読んでまず思ったのは、ここまで来たか、という驚きよりも、やっぱり一番むずかしいのは技術より権限設計だな、ということだった。ブラウザは人の生活にかなり近い場所にあるので、AIをそこに入れると便利さは一気に増す。でも同時に、メールを読む、フォームに触る、タブをまたぐ、という行為は、そのまま個人情報や業務データに触れることでもある。だから「できるようになりました」だけでは終わらない。 この記事で面白かったのは、Anthropicがかなり明確にブレーキを踏んでいるところだ。AIエージェントの話は、どうしても「全部自動でやってくれる未来」に寄りがちだけれど、実際にはその手前で止める工夫のほうが本体なのかもしれない。プロンプトインジェクション、つまりWebページやメールの中に紛れた“AIへの悪い指示”をどう防ぐか、という話は地味だけど核心だと思う。AIが賢くなるほど、悪用の入口も増える。ここを雑に扱うと、便利さより先に不安が勝つ。 もうひとつ引っかかったのは、これが「Chromeに入る」と言っても、すぐに何でもできる万能機能ではないことだ。Enterprise向けで、管理者が絞って使わせる

Claude Code の Claude in Chrome connector で、`navigate` や `computer` などの操作がすぐ失敗し、エラーが `Navigation to this domain is not allowed` になる症状が報告されています。今回の issue 群では、対象ドメインは 1 つに限られず、`mail.google.com`、`google.com`、`example.com`、`riverside.com`、`riverside.fm` まで含まれていました。つまり「特定サイトだけ弾かれる」より、承認プロンプト自体が出ないまま拒否されるケースとして読むのが近そうです。 まず切り分けたいのは、これが「そのドメイン固有の拒否」なのか、「Claude in Chrome 側でドメイン承認の状態が壊れている」のかです。報告を見る限り、後者を疑う材料が多いです。[#68891](https://github.com/anthropics/claude-code/issues/68891) では、どのドメインでも即失敗し、しかも承認プ

この症状は、issue の内容を見る限り「Claude in Chrome / Claude Code の MCP 経由で `navigate` を呼ぶと、許可済みのはずのドメインでも即座に拒否される」ケースが中心です。少なくとも報告されている範囲では、承認プロンプトが出ないまま `Navigation to this domain is not allowed` で止まっています。 たとえば [#58464](https://github.com/anthropics/claude-code/issues/58464) では、Claude in Chrome の設定で `Your approved sites` に入っていて、拡張機能のサイトアクセスも `On all sites` なのに、`mcp__Claude_in_Chrome__navigate` がそのドメインを拒否したと報告されています。手動で Chrome 上では普通に開けるのに、MCP 経由だけ失敗する、という切り分けです。 筆者の環境では Claude Code CLI の存在と MCP 管理コマンドの有無までは確

読んでまず思ったのは、これは派手なデモ機能というより、地味だけど現場で効く道具だな、ということだった。AIエージェントにブラウザーを操作させる話はもう珍しくないけれど、実際に困るのは「たまたま動いた」では終わらない場面だ。ログイン後の画面、位置情報の違い、CPUやネットワークの遅さ、拡張機能の挙動。人間が「さっきはこうだった」と言っても、AI側からするとそこが丸ごとブラックボックスになりやすい。そこをChrome DevTools経由で触れるようにする、というのはかなり筋がいい。 特に気になったのは、自動接続で“今使っているブラウザー”をそのまま使える点だった。新しい専用ブラウザーを立ち上げてテストするだけなら、それはそれで便利だけれど、認証済みのサイトや、手元の環境に強く依存する不具合はそれでは再現しきれない。結局、デバッグって「理想の環境」で起きたことより、「いつもの環境」でしか起きない不具合との戦いなので、この差は大きいと思う。 もうひとつ面白いのは、AIにサイトを“見せる”だけでなく、Lighthouseによる監査やメモリ分析まで渡しているところだ。ここまでくると、AIはただの

Chrome Dev（開発版）が 150.0.7846.4 に更新された 対象は Windows / Mac / Linux 変更点の詳細は、本文ではなく Git log に一覧がある 不具合を見つけたら bug報告 をしてほしい、と案内している Devチャンネルは、安定版より新機能が早く入るぶん、動作が変わりやすい Google Chrome の Dev channel が新しい版に更新された、というお知らせです。 今回は「大きな新機能ドーン！」というより、開発中のChromeを少しずつ前に進める定例アップデートという印象が強いです。こういう更新は、一般ユーザーには地味に見えるかもしれませんが、実はかなり重要です。というのも、Chrome はこうした段階的な更新を繰り返しながら、将来の安定版に向けて機能や修正を育てていくからです。 Chrome Releases の記事によると、2026年5月21日（木） に、Chrome Dev for Desktop が次のバージョンへ更新されました。 150.0.7846.4 対象

Chrome拡張のManifest V3（MV3）では、Service Workerがいつ死ぬかわからないので、昔のような「メモリに状態を持つ」設計が通用しない そのため、データの正本は chrome.storage.local に置く「disk-first」な作り方が重要になる オフラインや通信断を前提にし、ローカルとGoogle Drive上のデータを安全にマージする必要がある Googleの公式SDKを捨て、native fetch でDrive APIを叩くことで、軽量で速い拡張機能を目指している ただしその代わり、multipart/related のHTTPリクエストを手書きするという、なかなか骨の折れる作業が発生する 制約は面倒だが、うまく付き合うと「ブラウザに自然になじむ」設計に近づく、というのがこの記事の主張 Stack Overflowの記事「Building a Google Drive Sync Engine that Survives MV3 Service Workers」は、Chrome拡張の世界で起きている地味だけ