Восстановить запрос без дублей
Loading, Applying, Retry и проверка исходной операции.
В этой главе · 5 разделов
Пустой Request, зависшее Applying или сообщение без ответа требуют проверки исходной операции. Главная задача — восстановить её состояние, сохранив связь с исходной Task, компьютером и запросом, а не создавать новые копии текста.
Loading the request#
Push может прийти раньше зашифрованного содержимого. В таком случае открытый Request сначала запрашивает данные у компьютера. До получения исходного текста и вариантов решения кнопки не должны выдавать догадки за настоящий запрос.
- Проверьте доступность компьютера в Devices.
- Дождитесь завершения текущего чтения или его ошибки.
- Используйте Retry, когда он доступен: это повторное получение исходного Request.
- Если вопрос уже решён в другом месте, прочитайте терминальное состояние вместо повторного ответа.
- Вернитесь в исходный чат и проверьте, к какой Task относится запрос.
Недоступный компьютер не исправляется многократным открытием push. Старое уведомление может относиться к уже завершённому решению. Список Needs you и конкретный Request имеют отдельную свежесть.
Applying после решения#
Выбор Allow, Reject, ответа на вопрос или режима автоматического разрешения требует подтверждения компьютера. Сохранение решения на реле ещё не означает применение в нативном агенте. Если окно остаётся Applying, проверьте текущую операцию и не подменяйте её обычным сообщением «да».
- Прочитайте команду и контекст перед решением.
- Параметры чата и Governance проекта проверяются отдельно.
Переключатель Auto allow in this chat относится к последующим действиям этого чата. Текущий запрос всё ещё требует собственного решения. Project Governance и глобальные запреты продолжают действовать независимо от настройки чата.
Send now и Retry#
Send now ускоряет готовность уже сохранённой записи очереди. Он не должен означать создание нового сообщения с другим ID. Refresh status перечитывает подтверждения исходного сообщения. Retry после ошибки требует понимания, что успел сделать компьютер.
Если одновременно видны две одинаковые фразы, сравните идентификаторы, время и состояния. Одинаковый текст сам по себе не доказывает повторное исполнение: одна запись может быть локальным отображением ожидаемой операции, другая — нативной историей. Но и скрывать реальный второй запрос по совпадению текста нельзя.
Для диагностики сохраните Message ID, Task, провайдера и компьютер. Не повторяйте публикацию, платёж, удаление или другую необратимую просьбу, пока не проверили исходный результат. Различия Cancel и Delete описаны в очереди.
Компьютер получил, а агент молчит#
Посмотрите отдельно Received by computer и Agent activity received. Компьютер мог принять операцию, но провайдер ещё ждёт входа, разрешения, свободного хода или ресурса. Проверьте авторизацию, нативный чат и текущую ошибку. Состояние Working во время отправки не является доказательством начала модели.
Для Claude Code мобильное продолжение может записаться в ту же историю через отдельный CLI-процесс. Живой desktop-сеанс получает непрочитанный журнал и краткий контекст на следующем prompt через поддержанный hook. Это помогает восстановить понимание, но не является мгновенной перерисовкой уже открытого окна. См. источники активности.
Stop и оборванный запуск#
Stop относится к доступному владельцу конкретного исполнения. Он не отменяет уже выполненную команду и не выключает будущую автоматизацию. Если доставочный запуск остановлен ограничением времени, прочитайте итоговый digest: что было запрошено, что успело измениться и почему ход завершился. В описанном модуле есть ограничение длительности такого запуска; его нельзя принимать за предел существования всего desktop-чата.
Для обращения в поддержку используйте диагностику; никогда не включайте коды входа и ключи подключения.