No deferred tool marker found in the resumed session. Either が出て claude --resume できないときまず切り分けたいのは、このエラーが「セッションの再開に失敗している」話なのか、「再開先のセッションに deferred tool の印が残っていない」話なのかです。今回の症状クラスタでは、どちらも claude --resume <id> で同じエラーに見えます。
issue #77313 では、バックグラウンドの deferred agents を使う Task tool と plan-mode approvals を組み合わせたセッションが、途中で中断されると claude --resume <id> が再接続できなくなり、その状態が恒久的に続くと報告されています。報告者は macOS の Apple Silicon 環境で再現し、ssh の素の対話シェルでも terminal multiplexer 経由でも同じ挙動だったと書いています。SSH 接続枯渇ではないことも確認済みでした。
一方、issue #80954 では、headless 実行 claude -p --output-format stream-json で終わったセッションに対して、あとから Remote Control を付けて会話したい、という用途で同じエラーにぶつかっています。こちらは Windows 11 上の native claude.exe、claude.ai subscription auth の環境です。つまり、症状の見え方は似ていても、発生の入口は「途中中断された deferred tool セッション」と「完了済み headless セッション」で違います。少なくとも issue の記述だけでは、同じ根本原因だとまでは断定できません。
実際に issue #80954 で引用されているエラーは次のとおりです。
Error: No deferred tool marker found in the resumed session. Either the session w
この issue では、claude --resume <uuid> --remote-control "name" を実行すると約 6 秒で失敗したと書かれています。ただし、解決策として確認できるものは本文中にはありませんでした。代表 issue に付いたコメントも、「しばらく未活動だったので閉じる。まだ関連があるなら新しい issue を開いてほしい」という内容で、修正済みであることは示していません。
現時点で言えるのは、少なくともこのエラーは「再開しようとしている session に deferred tool marker が見つからない」場合に出る、ということだけです。どの条件で marker が消えるのか、あるいは最初から付かないのかは、渡された issue だけでは分かりません。なので、Task tool のバックグラウンド利用や plan-mode approval、headless 実行後の再接続をまたぐ運用をしているなら、今回の症状に当てはまる可能性があります。逆に、そうした機能を使っていないなら別件の可能性が高いです。
再現や切り分けを進めるなら、少なくとも issue に書かれている範囲では、次のような観点で見ていくのが自然です。途中で中断されたセッションなのか、完了済みの headless 実行なのか。そこに deferred tool の使用や plan-mode approvals が絡んでいたか。ssh や terminal multiplexer の有無で挙動が変わるか。今回引用できる情報では、これ以上の手順は確立していません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-30T08:55:28+09:00