teleportの「Failed to fetch session」とは — 再実行と報告の手順
claude --teleportの「Failed to fetch session from Sessions API」は、セッションは見つかったのに履歴を読めない状態です。他のエラーとの見分け方と再実行・報告の手順です。
Failed to fetch session from Sessions API: Failed to fetch session logsは、Claude Codeがクラウドセッション自体は見つけたものの、会話履歴をAnthropicのサーバーから読み出せなかったときのメッセージです。履歴を読めないので、セッションは端末に開きません。対処は2段階で、同じteleportをもう一度実行し、同じ失敗が続くなら報告します。
認証の問題でも、リポジトリ違いでもありません。teleportの他のエラーとは出る位置が違うので、先に見分け方を押さえると無駄な再ログインを避けられます。
このメッセージは何が起きた状態か
Claude Codeが「端末に引き込むよう指示されたクラウドセッション」を見つけた後で、その会話履歴の読み取りに失敗した状態を指します。メッセージ全体は次の形です。
Failed to fetch session from Sessions API: Failed to fetch session logs後半のFailed to fetch session logsが実際の失敗箇所で、読めなかったのはセッションのログ、つまり会話履歴です。teleportは「リポジトリの確認、ブランチの取得、会話履歴の読み込み」の順に進むので、このエラーは最後の段階で起きます。
エラーリファレンスはこの項目を「Network」に分類しています。ただし、原因として挙がっているのは再実行と報告だけで、個別の原因の一覧はありません。
どの入口から出て、何が返るか
メッセージが出る入口は3つあります。
| 入口 | 操作 |
|---|---|
claude --teleport | 操作起動時にセッションを選ぶ。IDを渡す形もある |
/teleport(/tp) | 操作起動済みのセッションの中から引き込む |
/tasks | 操作一覧でクラウドのセッションを選ぶ |
claude --teleport <session-id>でIDを直接指定した場合は、メッセージを出力して終了コード1で終わります。ほかの入口の終了コードは、記載がありません。
シェルスクリプトから呼ぶ場面では、終了コードを読むと失敗を検出できます。次は確認用の例です。
claude --teleport <session-id>
echo "exit code: $?"入口ごとのセッションの選び方や、5つの入口の使い分けはClaude Code teleportの使い方にまとめています。
他のteleportエラーとはどこが違うか
teleportで止まる原因は複数あり、メッセージで分かれます。このエラーの特徴は「セッションが見つかった後」に出ることです。見つける前に止まるものは別系統になります。
| メッセージ | 止まる位置 | 対処の方向 |
|---|---|---|
Unable to get organization UUID | 止まる位置認証の段階 | 対処の方向claude auth loginか/loginでclaude.aiアカウントに入り直す |
ピッカーのError loading Claude Code sessions | 止まる位置セッション一覧の取得 | 対処の方向上と同じ。ID無しの--teleportで出る |
Remote Control session expired / Access denied | 止まる位置接続の段階 | 対処の方向/loginで更新し、セッションを作った本人のアカウントか確認する(詳しくはこちら) |
Nothing was stashed: ... | 止まる位置チェックアウトの整理 | 対処の方向フォルダーをコミットか退避してから再実行する |
Failed to fetch session from Sessions API | 止まる位置会話履歴の読み込み | 対処の方向同じ操作を再実行し、続くなら報告する |
上4行はいずれも、手元の状態か認証を直せば進みます。最後の1行だけは、手元に直すものが書かれていません。ここで/loginを繰り返しても、このエラーの対処にはなりません。認証の失敗なら別の文言で出るので、見分けは上の表で付きます。組織のポリシーで弾かれている疑いがあるなら、Cloud sessions拒否の切り分けが入口になります。
teleportが止まったときの切り分け
- Qメッセージに Sessions API と session logs が入っているか?答えがいいえのとき答えがはい
別のteleportエラーです。上の表で該当する行を探します。
- Q同じteleportをもう一度実行したか?答えがいいえのとき答えがはい
まず1回再実行します。同じ文言が出たら次へ進みます。
報告する
/feedbackで会話と状況を送ります。手順は次の節にあります。
再実行しても直らないときの報告手順
対処は、同じteleportをもう一度実行し、同じ失敗が続いたら報告することです。報告の窓口は、エラーリファレンスの「Report an error」にまとまっています。
同じ失敗が続くときの流れ
- 1
ステータスページを確認する
status.claude.comで進行中のインシデントがないかを見ます。障害の最中なら、報告の前に復旧を待つ判断もできます。
- 2
/feedbackで送る
Claude Code内で
/feedbackを実行すると、会話の記録と説明がAnthropicに届きます。GitHubのIssueを事前入力した状態で開く選択肢も出ます。Anthropicへの送信には認証が必要です。 - 3
環境を診断する
シェルで
claude doctorを実行すると、インストールの状態を読み取り専用で診断できます。セッション内なら/doctorです。 - 4
既存のIssueを探す
GitHubのclaude-codeリポジトリで、同じ文言のIssueがないか検索します。
Amazon BedrockなどのサードパーティプロバイダーやAnthropicの資格情報がない環境では、/feedbackはローカルにアーカイブを保存します。それをAnthropicの担当者に渡す形です。ただしteleport自体がclaude.aiの認証を前提にしているため、この環境でこのエラーに行き当たること自体が少ないはずです。
送信そのものが失敗することもあります。Couldn't send feedbackと出たら、ダイアログには入力した文章が残っているので、そのまま再送できます。末尾がnot signed in. Run /login, then retry.なら、送信の時点で使える認証がありません。ここは/loginが正しい対処で、teleportのエラーとは扱いが逆になります。(request timed out)や(couldn't reach the service)のようにネットワークの失敗を示す表記なら、接続を確かめてから送り直します。(server returned <status>)の数字は、サービスが返した応答コードです。報告の文面にそのまま書き写しておくと、状況が伝わります。繰り返し失敗するときは、メッセージのとおりGitHubのclaude-codeリポジトリにIssueとして提出します。
v2.1.296より前は「空の会話で成功」に見えた
v2.1.296(2026年10月9日)で、--teleportは履歴を読めないときに空の会話を開く不具合が修正されました。それ以前の挙動は次のとおりです。
履歴の読み取りに失敗したときのteleport
v2.1.296より前
読み取りの再試行がありません。失敗した後に、空の会話でセッションを開き、成功として扱うことがありました。
v2.1.296以降
読み取りに失敗すると、このエラーメッセージが出ます。セッションは開きません。
つまり、いまこのメッセージが出るのは、むしろ正しい動作です。以前は黙って空のセッションに入っていた失敗が、見える形になりました。
古いバージョンのまま使っているときは、teleport後の会話が空だったら、この失敗が裏にあった可能性があります。まずバージョンを確認し、更新してからやり直します。
claude --version
claude update更新後にもう一度teleportを試し、それでも同じ文言が出たら報告に進みます。
報告に添える情報と、セッションIDの取り方
報告の質は、再現の手がかりがどれだけ付くかで決まります。報告では次の情報があると、再現しやすくなります。
- Claude Codeのバージョン(
claude --version)。v2.1.296より前かどうかで挙動が違うため、最初に書く価値があります - 出た入口。
claude --teleport、/teleport、/tasksのどれか - IDを指定したかどうか。指定した場合は終了コード1が確認できます
- 同じ操作を再実行した結果。再実行で同じ文言が続いたことは、報告に書いておきます
セッションIDを手で指定する場合の取り方です(Claude Code Web版の使い方ガイドも参照)。クラウドセッションの中で/teleportと入力すると、そのセッション用のclaude --teleport <session-id>コマンドが返ってきます。リポジトリのチェックアウトから実行する形で、v2.1.223以降のClaude Codeがセッション側の環境にあることが条件です。/tasksの一覧でtキーを押してもテレポートできます。
IDを渡す形と一覧から選ぶ形で、履歴の読み取り処理が同じかどうかは、公式の記述にありません。入口を変えて試すのは自由ですが、それで直る保証は書かれていないので、報告にはどの入口で試したかまで書いておくと伝わります。
履歴を読めたあとにteleportが引き継ぐもの
エラーを避けられたときにteleportが何をするかを知っておくと、失敗の意味が分かりやすくなります。Web版のドキュメントでは、teleportは正しいリポジトリにいるかを確認し、クラウドセッションのブランチを取得してチェックアウトし、会話履歴を丸ごと端末へ読み込みます。
引き込んだ後の端末側は、クラウドセッションの独立したコピーです。手元で続けた作業はclaude.aiやモバイルアプリのセッションには反映されません。履歴の読み込みは、この「コピーを作る」工程の入口にあたります。履歴が読めなければコピー元がないので、セッションを開かずにエラーで止めるのは筋が通っています。
引き込んだ後もスマホから操作したい場合は、ローカル側で/remote-controlを始めます。この組み合わせはteleportとRemote Controlの違いの節で比べています。
まとめ
Failed to fetch session from Sessions APIは、セッションを見つけた後の履歴読み込みで起きる失敗で、手元の設定を直しても変わらない種類のエラーです。同じteleportをもう1回走らせ、それでも同じなら/feedbackで送る、という2手で足ります。
v2.1.296以降はこの失敗が空の会話ではなくエラーとして表に出ます。teleport後に会話が空だった経験があるなら、更新してからもう一度試す価値があります。