エージェントが信頼確認やサインインを待っている場合：指示を保持し、元のセッションを復旧して実際の結果を検証する

iPhone で開発マシンのプロジェクトを開き、「既存のサインイン方法を維持したまま、サインインページがスクロールできるように修正してください」と入力しました。送信をタップすると、アプリはエージェントがまだメッセージを受信できない状態であると通知します。しかし、ターミナルには画面が表示されており、プロセスが終了した形跡もありません。

このとき答えるべき問いは 2 つあります。エージェントは何を待っているのか？ 送信しようとした指示はどうなったのか？ 片方だけを解決しても不十分です。サインインを完了しても、保持されたメッセージに対する判断が残っている可能性があります。また、ネットワーク復旧後に、先ほどのリクエストがすでに実行され始めている可能性もあります。

Tactic Remote 1.11 では、アップデートされたホスト側コンパニオンと連携して、認識された入力ブロックの要因を説明し、拒否されたメッセージを保持します。以下の 3 つの操作シナリオで復旧手順を説明します。これらは復旧の流れを解説するための例であり、実際に発生したユーザー事例を報告するものでも、すべてのエージェント画面を同一に表現するものでもありません。

プロセスの稼働、入力準備の完了、タスク完了を区別する

ターミナルプロセスが稼働していることと、プログラミング指示を受け付けられる状態にあることは異なります。プロジェクトの確認中であったり、プロバイダーへのサインインを待っていたり、入力画面を初期化中であったりする可能性があります。逆に、画面がアイドル表示になっていても、コードの修正が完了した証明にはなりません。単に現在実行中のタスクがないだけかもしれません。

ツールの実行権限はタスク実行中の承認メカニズムであり、必ずしも「送信拒否」に該当するわけではありません。エージェントの種類、実行モード、バージョンによってプロンプトは異なります。実際のターミナル表示とアプリの案内に従ってください。

シナリオ 1：新しいプロジェクトでディレクトリの信頼確認待ちになる

新しいリポジトリに切り替えた直後、ターミナルに現在のディレクトリを信頼するかどうかの確認が表示されることがあります。対話型セッションにおいて、Claude Code は未信頼のディレクトリに対してワークスペースの信頼確認ダイアログを表示します。公式セキュリティドキュメントにこの動作が説明されています。

まずターミナル内の完全なパスを確認してください。意図したリポジトリでしょうか？ 自分のコードか、同僚のプロジェクトか、それともダウンロードしたばかりの未知のコードでしょうか？ 同名ディレクトリであっても、別のブランチ、複製、独立したワークスペースの可能性があります。セッション名だけで判断してはなりません。

1.11 がこの待機状態を認識している場合、復旧入口としてターミナルを開くよう案内されます。画面の選択肢に従って信頼の可否を決定した後、エージェントが入力画面に遷移したか確認します。待機中のプロセスを再起動しても、多くの場合、同じ確認が再び表示されます。

次に、保持された指示を確認します。元の指示にファイル変更やコミットが含まれていた場合は、入力欄に戻して範囲を絞り込むことができます：

このリポジトリの起動方法、関連するサインイン画面、既存のテストを読み取り専用で調査してください。変更が必要と思われるファイルと維持すべき挙動をリストアップしてください。まず方針を提示し、ファイルの編集、依存関係のインストール、コミットは行わないでください。

返答内のパスが現在のリポジトリと一致していることを確認した上で、実装に進みます。その後のツールの権限要求についても、アクションごとに個別に判断する必要があります。ディレクトリの信頼確認は、その後のすべてのアクションを無条件に承認することを意味しません。権限ドキュメントに操作ごとの認可ルールが記載されています。

シナリオ 2：コンピューターは接続されているが、エージェントがサインインを要求する

Tactic アカウントは開発マシンとの連携とアクセス権限を管理します。一方、Claude Code、Codex、Amp、Droid は開発マシン上の独自のアカウントを使用します。スマートフォンからプロジェクトを開けたとしても、それらのプロバイダー認証が完了しているとは限りません。

まず、どのプログラムがサインインを求めているかを確認します。エージェントのターミナルプロンプトであれば、その手順に従って認証を完了します。コンピューターのブラウザでの操作が必要な場合は、ブラウザ側で完了させた後、同じセッションに戻ります。サインイン URL やワンタイムコード、アカウントの資格情報を通常のチャットメッセージに貼り付けないでください。

サインイン完了後、ターミナルが認証画面を抜け、入力を受け付けられる状態になったことを確認します。実際のエラーがアカウント権限、サブスクリプション、ネットワークアクセス、設定に起因する場合は、そのエラーに沿って対処してください。Tactic への再ログインやコンピューターの再紐付けを繰り返しても、プロバイダー認証の代わりにはなりません。

次に、保持されたメッセージ、入力欄、保留キューを確認します。指示がまだ送信されていない場合は、どの指示で続行するか選択します。新しい出力がすでにその指示に対応している場合は、現在の結果を確認します。サインイン成功直後に画面が静かだからといって、タスク全体を再度貼り付けてはいけません。

復旧アクションを選択する際、そのメッセージに何が起きるかを確認する

1.11 の復旧アクションは、認識された状態に応じて適切な選択肢を提供します。明示的に未稼働の場合は Start & Send（起動して送信） を選択できます。信頼待ち、サインイン待ち、起動待ちと認識されている場合は、Open Terminal（ターミナルを開く） から現在のプロンプトに対応します。

同じ保持メッセージに対して、Queue（キューに追加） や Edit（編集） を選択することも可能です：

入力欄にすでに文字が入力されている場合、新しい下書きが保持メッセージで上書きされるのを防ぐため、Edit ボタンは無効化されます。また、キューが一時停止中であったり、承認待ちであったり、タスクの状態が不確定である場合、ネットワークが再接続されたという事実だけでキュー内のメッセージが送信されたと判断することはできません。

古いホスト側コンパニオンでは待機状態の分類が完全ではない可能性があり、アプリに汎用的な Start & Send ボタンが表示されることがあります。このボタンはプロセスが停止したことを証明するものではありません。起動を選択する前にターミナルで実際の状態を確認し、実際に使用しているホスト側コンパニオンをアップデートしてください。

シナリオ 3：送信後に切断された場合、まず届いているかを確認する

アプリがコンピューター側から明確な拒否応答を受け取った場合、そのメッセージは未受領メッセージとして復旧できます。しかし、送信途中のタイムアウトや切断は異なります。リクエストはすでにコンピューターに届いており、スマートフォン側で結果を受信できていないだけの可能性があります。

同じコンピューター、プロジェクト、セッションに戻り、そのリクエストに対応する最新の出力を探してください。エージェントがサインインページを編集中であれば、そのまま作業を継続させます。すでに結果が出力されていれば、まずそれを確認します。チャット画面で新しい吹き出しが見当たらない、あるいは過去の履歴しか表示されていない場合でも、リクエストが実行されていない証拠にはなりません。バックグラウンドで処理が受理されている可能性があります。

例えば、直前の指示が「修正してコミットして」であった場合、安易に再送信すると余計な変更が発生したり、2 つ目のコミットが作成されたり、重いコマンドが重複実行されたりする恐れがあります。状態が明確になるまで、「もう一度試す」をデフォルトの復旧動作にすべきではありません。

現在のセッションがアイドル状態であることを確認した上で、進行状況を尋ねることができます：

直前のタスクがすでに開始されているか、現在どのファイルが変更されたか、実際にどのチェックが実行されたか、コミットが作成されたかを説明してください。直前のタスクを再実行したり、さらなる変更や公開を行ったりしないでください。

これはステータス確認の問い合わせです。ターミナルが信頼確認、サインイン、権限選択で止まっている場合は、まずそのプロンプトを解決してください。そうしないと、この問い合わせ自体が拒否される可能性があります。元のセッションが読み込めない場合は、コンピューター側で該当プロジェクトとプロセスを確認してから復旧方法を検討してください。

復旧後はステータス表示だけでなく、実際の結果でタスクを検証する

まず小規模なリクエストで元のセッションが正常に応答することを確認してから、実装指示を出します。冒頭のスクロール問題の例であれば、達成目標と維持すべき条件を明確に指定します：

小さい画面でサインインページがスクロールできない問題を修正してください。既存のサインイン方法、サインインからの復帰フロー、認証キャンセル時の表示は維持してください。まず最小限の変更範囲を説明してください。完了後、実際に行った変更、実行したチェック、失敗した項目、手動での確認が必要な操作を報告してください。まだ公開はしないでください。

結果を検証する際は、少なくとも意図したリポジトリ内で変更が行われていること、ページが実際にスクロールできること、既存のサインインおよびキャンセル処理が要件を満たしていることを確認します。テスト結果は今回の変更に対応している必要があります。テスト後にコードを再編集した場合は、影響を受ける挙動を再検証してください。返信が届いたことは応答性の回復を示すだけであり、これらの検証の代わりにはなりません。

元のセッションが存在しないか継続不能であることが確定した場合にのみ、新しいセッションを作成してください。その際は事前に、タスクの要約、変更済みファイル、実行済みチェック、未解決の課題を記録しておきます。同じディレクトリで新しいセッションを作成したり、別エージェントに切り替えたりしても、以前のタスクコンテキスト全体が自動的に引き継がれるわけではありません。

再びコンピューターに接続できなくなった場合は接続トラブルシューティング手順に戻り、接続できても有効な返信が得られない場合は、エージェント名、双方のバージョン、具体的な待機プロンプト、直前のメッセージ状態を記録してサポートに問い合わせてください。アップデートの前提条件や本リリースのその他の変更点については、Tactic Remote 1.11 の詳細解説を参照してください。