Если вы обновили Cursor и включили функцию Computer use, вы ожидаете, что автономный ассистент сможет сам запустить интерфейс вашего проекта, нажать нужные кнопки и проверить верстку. На практике управление рабочим столом устроено иначе: агент действительно умеет двигать курсор и делать снимки экрана, но его поведение кардинально зависит от того, где именно он запущен. На изолированном облачном сервере он свободно управляет браузером, на собственном компьютере требует ручной выдачи скрытых системных прав, а в мобильных симуляторах клики могут вовсе теряться по дороге.
Пользователи рассчитывали, что ассистент станет полноценным тестировщиком, которому можно поручить прогон интерфейса перед созданием pull request. Однако на практике выяснилось: даже если нейросеть присылает аккуратный снимок экрана открытой программы, это ещё не значит, что её физическое нажатие мыши дошло до нужного элемента.
Три разных мира, где ассистент двигает мышь
Главная путаница возникает из-за того, что под одной вывеской скрываются три принципиально разные среды исполнения. Первая — управляемые облачные агенты (Cloud Agents). Они живут на изолированных виртуальных машинах в облаке Cursor, поднимают тестовый сервер, открывают браузер и проверяют веб-страницу. В этом окружении агент свободен от ограничений: подтверждения действий не запрашиваются, так как виртуальная машина уничтожается сразу после выполнения задачи.
Вторая среда — ваши собственные машины (My Machines), когда вы подключаете свой компьютер в качестве исполнителя. Здесь управление экраном по умолчанию выключено: сервер Cursor не трогает рабочий стол, пока вы прямо не передадите параметр —computer-use при запуске воркера. На Linux для этого создается отдельный изолированный графический стол, который не пересекается с вашей сессией и передает картинку только по исходящему каналу.
Третья среда — настольное приложение Cursor на Windows, где управление программами появилось в рамках поэтапного развертывания через специальный встроенный MCP-инструмент. Здесь ассистент пытается нажимать кнопки прямо в вашей активной пользовательской сессии.
Почему клики в симулятор смартфона пропадают по пути
Самый наглядный сбой проявился при попытке проверить мобильное приложение на Mac. Разработчики заметили парадоксальное поведение: агент запускает симулятор iOS через Xcode, делает четкие скриншоты и бодро отчитывается, что нажал на кнопку. Однако при детальном разборе видно, что экран приложения не изменился — между кадрами до и после клика сдвинулись лишь цифры системных часов в статусной строке.
При этом эмулятор Android на том же самом компьютере без проблем принимает нажатия и ввод текста. Для разработчика возникает опасная иллюзия: отчет помечен успешным статусом, скриншот в окне редактора выглядит убедительно, а реальный сценарий внутри интерфейса так и остался не проверенным.
Если вы следите за тем, как автономные агенты учатся взаимодействовать с реальными программами и где они спотыкаются на практике, подписывайтесь на канал Ковчег: там мы без лишнего шума разбираем изнанку современных AI-инструментов.
Скрытые системные права и ловушка разрешений на Mac
Если вы настраиваете воркер на собственном Mac, стандартной выдачи прав доступа будет недостаточно. При запуске команды с флагом —computer-use консольная утилита Cursor скачивает в служебную папку отдельное приложение Cursor Computer Use. Именно этой вспомогательной программе требуются разрешения на запись экрана и универсальный доступ в системных настройках macOS.
Выдача прав терминалу или самому редактору Cursor ничего не дает: без разрешений для фонового помощника клики и скриншоты просто падают с ошибкой. Ситуация осложняется тем, что встроенная команда диагностики проверяет только наличие скачанного пакета, но не видит реальные права в операционной системе. В итоге процесс сообщает о готовности, а на первом же нажатии спотыкается о системный запрет.
Сюрприз на Windows: действия без лишних вопросов
Еще более неожиданная картина открылась на Windows. В настройках редактора есть раздел Computer Use, где указано: система спросит подтверждение при первой попытке агента обратиться к сторонней программе. На деле ассистент открывает инструменты разработчика в браузере Chrome и кликает по элементам вообще без единого вопроса.
Как пояснили разработчики Cursor на форуме, отдельного окна подтверждения на каждое приложение на Windows сейчас нет. Управление экраном работает как инструмент протокола MCP и подчиняется общему режиму выполнения. При автоматической проверке классификатор может посчитать действие безопасным и пропустить его втихую. При этом строгий режим подтверждения каждого шага вывели из эксплуатации еще в мае 2026 года, поэтому для полной блокировки кликов приходится либо очищать белый список, либо вовсе выключать MCP-сервер управления компьютером.
Как безопасно проверять работу ассистента
Пока технология взаимодействия с рабочим столом проходит обкатку, доверять отчетам ассистента вслепую не стоит. В обновлении 3.27 разработчики исправили ошибку с передачей контроля, из-за которой завершение одного шага сбрасывало управление экраном у следующего действия, но механика подтверждений все еще требует внимания.
Если вы поручаете агенту проверку интерфейса, подтверждайте результат не картинками в окне диалога, а кодами завершения тестов и проверкой измененных файлов. А перед запуском сценариев на собственной рабочей машине всегда проверяйте список активных MCP-инструментов и права доступа фоновых служб.
