Ручной вызов при этом остаётся. Агента зовут комментарием в пул-реквесте и просят починить падения, а можно назвать конкретную проверку, например упавший линтер. Разница практическая, а не косметическая: адресная просьба сужает область, и агент не начинает разбираться со всей матрицей сборки ради одной строки. Тот же путь выручает, когда автоматика промолчала по одному из своих условий, а починка всё-таки нужна.

Выключается всё это на двух уровнях. Целиком для своих облачных агентов - в панели управления Cursor, в разделе облачных агентов, в личных настройках, где снимается опция автоматической починки падений сборки. Точечно для одного пул-реквеста - комментарием @cursor autofix off, обратно включается комментарием @cursor autofix on. Второй уровень на практике важнее первого: он позволяет не отключать полезный контур насовсем ради одного пул-реквеста, где автоматика мешает.

Цена складывается из трёх частей. Каждое продолжение - это прогон агента и следом полный прогон сборки, то есть минуты и деньги; десять продолжений на один пул-реквест уже заметная величина, особенно на длинных матрицах. Дальше идёт шум в истории ветки: серия правочных коммитов поверх осмысленного изменения читается хуже, чем одно. И главное - риск подгонки: агент, у которого критерий успеха сформулирован как зелёная проверка, вправе сделать её зелёной любым способом, включая ослабление самой проверки.

Оправдан контур там, где падения массовые и механические: формат, линтер, типы, забытый снимок, несобранный сгенерированный файл. На таких падениях он экономит ровно тот вид внимания, который тратится зря. В проектах, где сборка нестабильна сама по себе, включать его до починки нестабильности бессмысленно - он будет чинить погоду. Проверяют результат не по цвету значка, а по содержимому правочных коммитов: смотрят, что именно изменилось после автоматической починки, и отдельно смотрят, не тронуты ли сами тесты, пороги покрытия и конфигурация линтера.

Отдельно стоит помнить про доступность: контур раскатан на командные аккаунты, для остальных он заявлен как готовящийся, и планировать на него процесс до этого не стоит. Типичные провалы предсказуемы. Включить автоматику на проекте с нестабильными тестами и получить серию продолжений на каждом пул-реквесте. Принять зелёный значок за доказательство, не прочитав правочные коммиты. Запушить свой коммит в ветку агента и ждать, что он продолжит чинить, - после человеческого коммита контур молчит по правилу, а не по ошибке. Выключить механизм целиком из-за одного шумного пул-реквеста вместо точечного комментария. И оставить агенту право править конфигурацию проверок, а потом удивляться, что упавший тест исчез вместо того, чтобы пройти.