まず切り分けたいのは、いま見ている EADDRINUSE が「自分の環境でも再現する、同じ系統の問題かどうか」です。今回の issue 群では、症状の出方が 2 通りあります。
ひとつは、Linux 上の daemon supervisor が control socket の bind() に失敗して落ちるケースです。#72334 では、EADDRINUSE で control.sock を掴めず、transient 側の分岐がそのまま致命的終了する、という報告でした。コメントでは、同じ症状が 2.1.196 と 2.1.197 でも続いていたこと、~52s 間隔で supervisor が再起動し、競合が起きるときは control.sock まわりでレースが起きることが書かれています。実際のログ断片も示されています。
[supervisor] bg manager failed to start: [EADDRINUSE] listen EADDRINUSE: address already in use /tmp/cc-daemon-1000/<hash>/control.sock — c
もうひとつは、Claude in Chrome の bridge が、同時に接続している MCP クライアントへ tool_response を全部配ってしまうというものです。#87767 では、要求と応答の対応付けがなく、各クライアントが「次に届いたフレーム」を自分の応答だとみなすため、同時セッションが互いの結果を静かに取り違えると報告されています。こちらは EADDRINUSE そのものではなく、同時実行時に別セッションの結果を受け取ってしまうタイプです。
つまり、EADDRINUSE で疑うべきなのは前者です。control.sock の bind に失敗しているログが出ているか、あるいは daemon の起動や再起動が重なっているかを見ます。逆に、ブラウザ操作の結果が別セッションに混ざるだけなら、症状は別です。
今回の一次情報としては、こちらの環境情報だけを確認できています。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-09T08:51:42+09:00
この出力だけでは、EADDRINUSE が実際にどのプロセスで起きたかまでは分かりません。少なくとも、Linux 環境での報告であることは issue 側と整合しています。EADDRINUSE を見たら、まずは control.sock の取り合いか、daemon の多重起動が絡んでいないかを確認するのが近道です。もしログに listen EADDRINUSE: address already in use /tmp/cc-daemon-.../control.sock のような行が出ているなら、#72334 の系統を疑ってよさそうです。現時点では、これ以上の切り分けは手元の出力だけではできません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-09T08:51:42+09:00