結論：更新と復旧確認は別の作業
Claude Code 2.1.291は、2.1.290で発生したcloud sessionのpermission prompt回答欠落と、2.1.288で発生した終了時の最後のメッセージ欠落を修正しました。これは公式Claude Code changelogに記載された回帰修正です。更新後に「必ずデータが復元される」と保証するものではありません。
まず、実行面をcloud session、ローカル端末、Remote Control、CIなどに分けます。次に公式エラー分類で認証・接続・組織ポリシーのどこに該当するかを見ます。インストールやPATHが疑わしい場合は公式トラブルシュートを使います。既存のbackground sessionへのattach記事は接続方法が主題であり、本稿は2.1.291の回答欠落を検証する記事です。
2.1.291で確認する二つのケース
| ケース | 公式更新の要点 | 記録する証跡 |
|---|---|---|
| cloud session | permission promptへの回答が落ちる回帰を修正 | prompt表示時刻、回答、session ID、再開結果 |
| 終了処理 | quit時に最後のメッセージが失われる回帰を修正 | 送信時刻、表示時刻、終了方法、保存済みtranscript |
| 接続・認証 | 修正とは別の失敗経路 | 401、network、proxy、組織policyの分類 |
二つを同じテストに混ぜると、promptに回答できたのか、回答後のsessionが保存されたのかが分かりません。回答内容、受信した表示、再接続後に見える内容を別欄にします。個人情報や社内コードをそのままログへ貼らず、再現用の短いダミー入力に置き換えます。
8手順で再現と復旧判断を行う
claude --version、インストール経路、更新日時を保存し、2.1.291かを確認します。- 本番repositoryを使わず、秘密情報のない検証用repositoryを作ります。
- cloud sessionかローカルか、利用中のprovider、proxy、実行端末を台帳へ記録します。
- 短い質問を送って、通常回答が表示される時刻とsession IDを保存します。
- 許可が必要なread-only操作を一つだけ行い、prompt表示、回答、実行結果を順に記録します。
- 同じ条件で終了直前に短い最終メッセージを送信し、終了前の表示と再開後のtranscriptを比較します。
- 接続を切ったケース、認証を失効させたケース、権限を拒否したケースを混ぜずに再実行します。
- 欠落があれば再送を繰り返さず、version、session ID、時刻、ログ、再現手順を保全して停止担当へ渡します。
復旧の合格条件は、回答が見えることだけではありません。再開後に同じ依頼が二重実行されず、拒否した操作が実行されず、最終メッセージの存在をtranscriptで説明できることです。外部送信や破壊的操作を含む再現は行わず、サービス側の障害と自社の権限設定を分けて報告します。
原因の切り分けを比較する
| 兆候 | 優先して見る場所 | 暫定判断 |
|---|---|---|
| promptの回答だけが消える | version、cloud session、権限応答、接続再試行 | 2.1.290回帰または通信を分離 |
| 終了直前だけ欠落する | quit方法、transcript、再開結果 | 2.1.288回帰または保存処理を分離 |
| 401・ログイン要求 | 認証、有効期限、組織policy | エラー分類に沿って復旧 |
| 同じ操作が再実行される | 再接続処理、job ID、副作用台帳 | 自動retryを止めて人間確認 |
既存の権限設定ガイド、Remote Controlのfork条件も参照できますが、prompt応答の欠落を直す記事ではありません。更新後も同じ現象が続くなら、CLIのversionを戻す前に、短い再現とログの整合性を確認します。
再開ボタンを押す前の判断票
再開前には、sessionが止まった時点で副作用のあるtoolが動いていなかったかを確認します。表示が欠けているだけなら、同じ入力を再送する前にtranscript、job ID、外部システムの受付番号を照合します。受付番号が残っていれば二重実行を避け、結果が確定していなければ担当者の承認を待ちます。cloud sessionを別端末で開く場合も、同じsessionを二人が操作していないかを確認します。
サポートへ上げる証跡は、CLI version、実行面、発生時刻、UTCとJSTの対応、最後に見えたメッセージ、promptの回答、再接続の回数、再現率を最低限とします。ログの中身を増やすより、欠落した範囲と欠落していない範囲を明示する方が、復旧判断と責任分界に役立ちます。
対応の優先度は、欠落した表示の重要度だけでなく、実行済みか不明な副作用の有無で決めます。請求、公開、削除、権限変更のような操作は、表示が戻ったとしても自動で再送しません。担当者が外部システムの状態を確認し、未実行・実行済み・不明を決めてから次の操作を承認します。これを復旧runbookの停止条件にします。
また、障害報告のタイトルには「回答が見えない」だけでなく、どの実行面で、どの操作の前後に、何が欠けたかを書きます。再現しない場合も、再現しなかったversionと条件を残します。これにより、更新を急ぐ端末と、影響がない端末を分けて案内できます。利用者が独自に再送する前に、窓口へ連絡するルールも明文化します。
更新後の案内には、利用者が行ってよい確認と、管理者だけが行う確認を明記します。復旧済みと判断する基準を先に共有することで、同じsessionへの無秩序な再接続を減らせます。
公開前チェックリスト
- 2.1.291、provider、実行面、更新日時を記録した
- cloud sessionとローカルを別ケースにした
- prompt表示・回答・実行結果を時系列で保存した
- 終了前の表示と再開後のtranscriptを比較した
- 認証、proxy、組織policyを別の原因欄にした
- 二重実行を防ぐjob IDと停止担当を決めた
- 秘密情報を除いた再現ログを共有できる
企業利用では、復旧の速さだけでなく「何が実行されたか」を説明できることが重要です。利用者が見た表示と、監査担当が確認するsession記録を同じ時刻基準にそろえ、再送・再実行の判断を人間の承認へ置きます。2.1.291への更新は、その台帳を省略する理由にはなりません。
FAQ
- 2.1.291へ更新すれば回答欠落はなくなりますか？
- 公式changelogの修正対象は特定の回帰です。更新後も接続、認証、停止時刻、sessionの再開結果を自社の再現条件で確認します。
- permission promptを自動承認してよいですか？
- 一律の自動承認は避けます。対象操作、実行主体、データ範囲、停止条件を分け、必要なものだけ人間確認へ置きます。
- セッション障害の切り分けを相談できますか？
- できます。version、実行面、権限、ログ、再現手順を無料診断（60秒）で整理します。