Claude CodeのRemote-SSHでsdk_stream_ended_no_resultが出るとき

VS CodeのRemote-SSHでつないだ先でClaude Codeを使っていると、応答の途中で処理が止まり、Outputのログに sdk_stream_ended_no_result という行が残ることがあります。これはユーザー向けのエラーメッセージではなく、拡張機能が記録するイベント名です。GitHubのissue #91773では、同じ並びのログが出たあとに Claude Code process terminated by signal SIGKILL でセッションが落ちたと報告されています。このissueでは原因がまだ特定されていません。このイベントは「ストリームが結果なしで終わった」ことしか示さないので、落ちた位置を見て切り分けるのが現実的な進め方です。

sdk_stream_ended_no_resultは何を記録しているのか

issueに貼られたログでは、このイベントは次の形で出ています。

[info] Received message from webview: {"type":"request", ... "request":{"type":"log_event","eventName":"sdk_stream_ended_no_result","eventData":{"had_error":true,"subagent_count":0,"message_count":8}}}

読み取れるのは3点です。

• イベント名のとおり、ストリームが最終結果(result)なしで終わった
• had_error が true で、エラーを伴って終わった
• message_count は会話に積まれたメッセージ数、subagent_count は動いていたサブエージェント数

原因までは、このイベントだけでは分かりません。issueの報告者も「単一の再現手順は見つからない」と書いています。ログに出る前後の行を見て、どこで止まったかを確かめるのが次の作業です。

画面に出るエラーとは別物です。VS Code拡張のパネルには、プロセスが途中で切れたときの文言として The connection to Claude Code ended before this message completed があります。メッセージがClaude Codeのプロセスに渡った後、エラーなしに接続が切れたときに出る文言で、「処理されたかどうか分からないので、もう一度送ってください」という内容です。対処としては、エラーと一緒に出る「View output logs」のリンクからログを開くよう案内されています。sdk_stream_ended_no_result は、そのログの中で探す行です。

Remote-SSHで報告されている状況

#91773は、2026年9月3日に起票されたバグ報告です。環境と症状を表にまとめます。

報告者は、リモート側のリソース不足を先に潰しています。

• メモリは503GB、128コアで、ディスクの空きも十分
• ulimit に厳しい制限はない
• cgroupのメモリ上限は10GiBだが、memory.events の oom_kill は0で、OOMキラーは動いていない
• ssh -O check でControlMasterのセッションが生きていることを確認し、落ちた時刻に切断や再接続は見えなかった

後から付いたコメントには、落ちた時刻の前後でVS Codeのステータスバーに「Reconnecting to SSH」が出ていた、という追記があります。報告者は、これが拡張ホストの状態を知る手がかりになるかもしれないと書いています。ただし、これは1件のコメントで、原因とは断定されていません。

2種類のログパターン

issueには、落ち方の違う2つのログがあります。

パターン1: Bashの起動直後に落ちる

tool_dispatch_start tool=Bash の後に、シェルのスナップショット作成と環境変数の取得(Spawn-env probe captured 72 keys)まで進み、そこでプロセスが消えています。

パターン2: Bash完了後の次のストリームで落ちる

tool_dispatch_end ... outcome=ok durationMs=87 でBashは正常に終わり、次の /v1/messages へのリクエストも出ています。Stream started - received first chunk が出て、最初のバイトは約1.4秒で届いています。その約3秒後に sdk_stream_ended_no_result が記録されています。

2つを並べると、ネットワークだけでは説明しにくい点が見えます。パターン2ではAPIから最初のチャンクが届いています。パターン1ではAPI呼び出しの前、ローカルのツール実行の段階で落ちています。落ちる場所が一定しないことが、報告者が「ストリーム処理の問題かもしれない」と書いた理由です。

ローカル環境で起きる同名イベントとの違い

同じ文字列は、Remote-SSHを使わない環境でも2026年5月に報告されています。#91773はそのissue #59374に関連づけて立てられました。

#59374の環境は、Windows 11のローカルマシンです。症状の順序は次のとおりです。

1. Stream started - received first chunk が出る
2. [Stall] stream_idle_partial lastChunkAgeMs=15000 bytesTotal=656 idleDeadlineMs=300000 が出る
3. 15〜30秒ほどの無通信の後に sdk_stream_ended_no_result が記録される

報告者は、同じマシン・同じネットワーク・同じ認証で、ターミナルから claude --print "say hi" を実行すると再現しないことを確かめています。切り分けの足がかりとして、同じバイナリでも拡張機能を経由しない場合は問題が出ない、という事実があります。#59374は、MCPサーバーの再接続と時間的に重なるという仮説を挙げていましたが、そのissueの上では確定していません。issueは「not planned」でクローズされ、その後ロックされています。

もう一つ、Unhandled case: [object Object] というバナーが出る報告(#59306)があります。これは、ストリームが had_error: true で結果なしに終わったときに、画面描画側がエラーオブジェクトを文字列にしてしまう表示の問題です。#59306は重複としてクローズされました。バナーが出ていても、根は sdk_stream_ended_no_result と同じ場所にあります。

#91773が示しているのは、同名のイベントがWindowsのローカルでも、macOSからのRemote-SSHでも出ているという点です。ただしどちらも原因は特定されていないので、「Remote-SSHだからこれが原因」と言える材料はありません。

手元での切り分け手順

公式の手順は、VS Code拡張の「Claude Code never responds」に、インターネット接続の確認、新しい会話、ターミナルでの claude 実行の3つが載っています。Remote-SSHの場合は、これに「どちらのマシンで動いているか」の確認が加わります。以下は、issueの報告内容と公式の手順を組み合わせた順番です。

手順2のControlMasterの確認は、issueの報告者が使ったコマンドです。ホスト名は自分の ~/.ssh/config の Host に置き換えてください。

ssh -O check your-remote-host

手順3は、#59374の報告者が拡張機能の問題かどうかを見分けたときの方法と同じです。VS Codeの統合ターミナルで、リモート側から次を実行します。

claude --print "say hi"

結果の読み方は次のとおりです。

• ターミナルでは落ちず、拡張機能のパネルでだけ落ちる: 拡張機能側のストリーム処理が疑わしい。#59374の報告と同じ傾向で、作業はターミナルのCLIに移せる
• ターミナルでも途中で止まる: 拡張機能ではなく、リモートからAPIへの経路が疑わしい。公式のエラー一覧が案内する claude 実行時のエラーメッセージを確かめる
• 毎回ではなくときどきだけ起きる: 状態によって変わる問題で、再現手順が書けない。次の節の情報を集めておく

ストリームの待ち時間を調整する環境変数もあります。CLAUDE_STREAM_IDLE_TIMEOUT_MS は、イベント単位とバイト単位の2つの監視機構(ウォッチドッグ)が、止まった接続を閉じるまでの時間を決めます。明示した場合の最小値は300000(5分)で、それより小さい値は自動的にその値へ丸められます。ログの idleDeadlineMs=300000 と同じ値です。ただし #91773のログでは、最初のチャンクの数秒後にイベントが記録されていて、この監視機構が閉じた時間(5分)に達していません。この変数を触って直るという報告はなく、効果は確認されていません。

報告に添える情報

#91773は原因が特定されていません。同じ症状が出たときは、次の情報があると調べる側が状態を再構成しやすくなります。

• 拡張機能のバージョン。ログの cc_version= の行と、自分で把握しているバージョンの両方(#91773ではログとフォーム記入値が食い違っている)
• Remote-SSH接続の形: 接続先の種類(コンテナか物理ホストか)、ControlMaster の有無
• 落ちた位置: tool_dispatch_start の後か、tool_dispatch_end の後か、Stream started の後か
• 「Reconnecting to SSH」の表示が出たか
• リモートの統合ターミナルで claude を動かしたときに同じ症状が出るか
• 認証の種類(Consoleのアカウントか、claude.aiのサインインか)

ログには、ホームのパスやユーザー名が含まれます。issueに貼る前に、~ やプレースホルダに置き換えてください。

似た症状との違い

Remote-SSHやVS Code拡張で「動かない」ときの症状は、いくつかに分かれます。

sdk_stream_ended_no_result は、パネルが正常に出ていて、応答の途中でプロセスが落ちる点が他と違います。

まとめ

sdk_stream_ended_no_result は、ストリームが結果なしに終わったことを示すログ上のイベントで、それ自体に原因は書かれていません。Remote-SSHの報告(#91773)ではBashツールの前後でプロセスが落ち、リモートのリソース不足やSSH接続の切断では説明できていません。ローカルのWindowsでも同名のイベントが出ているので、Remote-SSH固有の問題と決めるのは早計です。

実務としては、リモートの統合ターミナルで claude を動かして落ちるかを比べ、拡張機能のパネルでだけ起きるなら作業をターミナルに移せます。落ちた位置とSSHの状態を控えておけば、issueに情報を足すときの材料になります。修正が入ったかどうかは、#91773のステータスとClaude Codeの更新履歴で追えます。