ERR_INVALID_ARG_TYPE が出て Chrome / Brave の native host が落ちるときの切り分け最初に見ておきたいのは、これが Windows 系の issue に寄っているかどうかです。今回の報告はどちらも Windows 11 上で、Claude Code の Chrome 連携まわりの native host が起動直後に ERR_INVALID_ARG_TYPE で落ちる、という形でした。ひとつは #57846、もうひとつは #76556 です。
#57846 では、claude --chrome で起動した Claude Code から mcp__claude-in-chrome__* 系の tool を呼ぶたびに "Browser extension is not connected." が返っていました。報告文には、拡張機能はインストール済み・有効・On all sites に設定済み・正しいアカウントで claude.ai にサインイン済み、そして Chrome も再起動済み、とあります。それでもつながらず、環境には Windows 11 Pro 26200、PowerShell 7、Claude Code 2.1.138、Bun v1.3.14 が書かれていました。さらに、ワークスペースのパスに ! が含まれていると明記されています。
#76556 では、claude.exe --chrome-native-host が起動直後に落ち、ブラウザ側のハンドシェイクが始まる前に named pipe の listener 作成で ERR_INVALID_ARG_TYPE を出していました。こちらも Windows 11 Pro (10.0.26200)、Claude Code 2.1.207、Bun v1.4.0 が報告されています。ブラウザは Brave ですが、コメント欄の主旨は Chrome 系の native messaging host で同種のクラッシュが起きる、というものでした。
この症状に当たっているかは、かなりはっきりしています。Claude Code の Chrome 連携を使った瞬間に、拡張機能が「接続されていない」扱いになる。あるいは native host 自体がすぐ死んで、ERR_INVALID_ARG_TYPE が見える。どちらも issue 側では Windows 上の再現例でした。少なくとも、今回集められた報告からは macOS や Linux での同様事例は確認できません。
ただし、解決策はこの 2 件の本文からは確定できませんでした。どちらの issue も closed ですが、コメントには「inactive for too long」「7 days activity がないので locked」といったクローズ理由しか残っておらず、修正内容や回避策は読み取れません。なので、ここで書けるのは「Windows の Chrome / Brave 連携で native host が named pipe を作る段階で落ちる報告がある」というところまでです。
筆者の環境で取得できた出力は、今回の症状そのものではなく検証環境の記録だけでした。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-12T08:51:27+09:00
このため、少なくともこの手元の環境からは ERR_INVALID_ARG_TYPE の再現確認はできていません。今の時点では、報告されている問題は Windows 固有の native host / named pipe 周辺の不具合として扱うのが自然だと思われます。もし同じ文字列が出ているなら、まずは Windows 11 上で claude --chrome または claude.exe --chrome-native-host を使っているか、拡張機能の接続失敗なのか、native host の起動失敗なのかを見分けるのが先です。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-12T08:51:27+09:00