ERR_SOCKET_CLOSED が出るときの Claude Code と HTTPS プロキシまず、これが自分のケースかどうかを切り分けます。issue 報告を見る限り、ERR_SOCKET_CLOSED は少なくとも 2 系統で出ています。ひとつは起動時の接続確認で落ちるケースで、#81611 では HTTPS_PROXY=https://user:pass@proxy.corp.example:8443 のような企業内 HTTPS プロキシ配下で、起動直後に Checking connectivity... のあと Failed to connect to api.anthropic.com: ERR_SOCKET_CLOSED になっています。もうひとつは #91703 のように、起動時の確認は通るのに、OAuth トークンの自動更新だけが ERR_SOCKET_CLOSED で失敗するパターンです。
前者については、コメントに「2.1.222 で修正済み」とあります。実際、#81611 の代表コメントには、起動時の connectivity check が HTTPS プロキシ越しで失敗する問題は 2.1.222 で直った、と明記されています。つまり、もしあなたが「起動直後に止まる」「Unable to connect to Anthropic services が出る」「api.anthropic.com への接続で ERR_SOCKET_CLOSED が出る」という症状なら、少なくともその issue 群とかなり近いです。
引用すると、#81611 ではこうなっています。
✻ Checking connectivity...
Unable to connect to Anthropic services
Failed to connect to api.anthropic.com: ERR_SOCKET_CLOSED
Please check your internet connection and network settings.
一方で、#91703 は少し違います。ここでは起動時チェックは通るのに、POST https://platform.claude.com/v1/oauth/token の silent refresh が約 15.4 秒止まって ERR_SOCKET_CLOSED になり、15〜17 秒ごとに再試行しても成功しない、と報告されています。issue 文面では「同じプロセス、同じプロキシ、同じ時間帯で、通常の API 通信は成功している」とされているので、少なくとも「プロキシ全体が死んでいる」わけではなさそうです。
ここで大事なのは、現時点で確認できる範囲では「ERR_SOCKET_CLOSED という同じ文字列でも、壊れている経路がひとつとは限らない」ことです。起動前の接続確認で落ちるのか、OAuth 更新だけ落ちるのかで、見ている場所が違います。前者は #81611 の修正対象だったとコメントされていますが、後者の #91703 は open のままです。したがって、少なくともこの報告群からは「全部同じ修正で解決した」とは言えません。
手元で切り分けるなら、まずは次の2点だけ見れば足ります。起動直後に Checking connectivity... で止まるなら #81611 側、起動は通るが後からトークン更新で ERR_SOCKET_CLOSED が出るなら #91703 側、という見方です。報告された事実だけに限ると、前者は 2.1.222 での修正報告があり、後者はまだ解決済みとは書かれていません。
なお、コメント欄には「local http-proxy workaround worked」という報告もありますが、どの設定や手順で動いたかはこの issue 文面だけでは分かりません。再現条件が企業内 HTTPS プロキシ、または https:// CONNECT プロキシであることは明記されていますが、こちらから具体的な回避手順までは断定できません。
今回あなたが見るべき一次情報はこの2つです。起動時に死ぬなら #81611、OAuth 更新だけ死ぬなら #91703 です。少なくとも、公開 issue 上では後者は未解決、前者は 2.1.222 で修正済みとされています。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-12T08:52:25+09:00