Если Roo Code слишком часто прерывает работу запросами подтверждения, не включайте все разрешения сразу: начните с чтения, затем добавляйте ограниченное редактирование и только после проверки — отдельные команды и MCP-инструменты. Для постоянной или безоператорной работы используйте изолированную удалённую среду, а ручное подтверждение сохраняйте для секретов, системных каталогов, публикации и разрушительных действий.

Эта схема подходит тем, кто хочет меньше отвлекаться на подтверждения при обычной разработке. Она также нужна командам, которые планируют запускать Roo Code на удалённом Mac, в облачной среде или в CI-подобном рабочем процессе. Если вы отвечаете за безопасность, дополнительно проверяйте границы файлов, сетевой выход, журналы и возможность быстрого отзыва разрешений.

Почему полное автоодобрение — плохая отправная точка

В Roo Code автоматическое разрешение разделено по типам действий: чтение файлов, редактирование, запуск команд, браузерные операции, MCP, переключение режимов и повтор запросов. При включённом разрешении действие выполняется без отдельного подтверждения пользователя. Это ускоряет работу, но одновременно расширяет автономность агента. (github.com)

Главная ошибка — считать все галочки одинаковыми. Чтение README из тестового репозитория и запуск скрипта миграции базы данных имеют совершенно разный радиус последствий. Даже редактирование файлов нельзя автоматически считать безопасным: оно может изменить конфигурацию агента, сценарии сборки или файл, из которого затем будет запущена команда.

Есть как минимум пять скрытых ограничений:

  • Область файлов. Нужно проверить, видит ли Roo Code только рабочий каталог или может обратиться к соседним путям, домашнему каталогу и файлам через символические ссылки.
  • Параметры команд. Разрешённый префикс команды не гарантирует безопасный результат, если аргументы, переменные окружения или текущий каталог могут меняться.
  • Секреты. API-ключи, токены, SSH-ключи и переменные окружения могут попасть в контекст, вывод терминала или результат MCP-вызова.
  • Внешние действия. Браузер и MCP могут не просто читать данные, а отправлять письма, менять записи, создавать задачи, публиковать код или обращаться к внутренним API.
  • Отзыв и восстановление. Если разрешения сохранены, а репозиторий, MCP-сервер или сценарии изменились, первоначальная настройка уже не является достаточной гарантией.

Официальная документация Roo Code отдельно описывает группы read, edit, command и mcp, а пользовательские режимы могут получать разные наборы инструментов. Например, режим, предназначенный только для анализа, не должен иметь доступ к редактированию и терминалу. (github.com)

Важно. Изолированная среда уменьшает радиус ущерба, но не делает ошибочную команду или вредоносный prompt injection безопасными. Изоляцию нужно проверять вместе с правами, сетью, секретами и откатом.

Матрица разрешений перед запуском

Перед изменением настроек составьте короткую матрицу. В ней должен быть не только ответ «разрешить или запретить», но и условие, при котором разрешение можно оставить включённым.

Тип действия Базовое решение Когда можно автоматизировать Что проверять
Чтение файлов Разрешить первым Только ограниченный репозиторий без секретов Пути, ссылки, скрытые каталоги
Редактирование Разрешить ограниченно Тестовая ветка, чистый Git diff, рабочий откат Область файлов, .roo, конфигурация
Терминал Разрешать по списку Предсказуемые и повторяемые команды Префикс, аргументы, каталог, окружение
Браузер Обычно вручную Только заранее определённые домены и чтение URL, авторизация, отправка форм
MCP По отдельному инструменту Узкий список без чувствительных операций Входные параметры, токены, отзыв
Публикация и удаление Не автоматизировать Только отдельный контролируемый процесс Двойная проверка и журнал

Эта матрица отражает не обещание безопасности со стороны Roo Code, а рабочий способ ограничить последствия. В официальных материалах автоматическое разрешение описывается как функция, которую следует включать постепенно и регулярно пересматривать. (github.com)

Оценка вариантов запуска

Вариант Удобство, 5 баллов Контроль, 5 баллов Рекомендуемое применение Итоговая оценка
Всё разрешено на рабочем компьютере 5 1 Только краткий эксперимент без секретов 1/5
Чтение и ограниченное редактирование локально 4 4 Личные задачи в тестовой ветке 4/5
Команды по списку в отдельном рабочем каталоге 4 4 Сборка, тесты, статический анализ 4/5
MCP по отдельным инструментам в удалённой среде 3 4 Контролируемая автоматизация 4/5
Безоператорный запуск с секретами и публикацией 5 1 Не использовать без отдельного контура 1/5

Этап 1. Сначала разрешите чтение и ограниченное редактирование

Создайте отдельную тестовую ветку или копию репозитория. Не начинайте с основной ветки, каталога с рабочими ключами или проекта, где локальные скрипты автоматически публикуют результат.

Порядок проверки:

  1. Откройте настройки автоодобрения Roo Code и оставьте включённым только чтение файлов.
  2. Укажите рабочий каталог с минимальным набором файлов.
  3. Попросите Roo Code перечислить доступные каталоги, включая скрытые.
  4. Создайте тестовый файл и измените одну строку в безопасном исходнике.
  5. Проверьте git diff, список незапланированных файлов и содержимое .roo.
  6. Создайте символическую ссылку на файл за пределами рабочего каталога и убедитесь, что обращение к ней блокируется или явно фиксируется.
  7. Выполните восстановление через Git и убедитесь, что состояние возвращается к исходному.

Условие прохождения: агент изменяет только ожидаемые файлы, diff читаем, тестовая ветка восстанавливается, а попытка выйти за пределы рабочей области не проходит незаметно.

Условие остановки: Roo Code читает соседние каталоги, меняет конфигурацию без явного запроса, создаёт неожиданные файлы или не удаётся определить полный diff.

Доказательства: снимок настроек, исходный и итоговый git diff, запись запрещённого обращения к внешнему пути и результат восстановления.

Важный отдельный пункт — конфигурационные файлы Roo Code. В опубликованном advisory описывался сценарий, при котором изменение MCP-конфигурации в проекте в сочетании с авторазрешением записи могло привести к выполнению произвольной команды; исправление добавило дополнительный уровень согласия для записи в конфигурационные файлы Roo Code. (github.com) Поэтому папку .roo не следует автоматически приравнивать к обычному исходному коду.

Если вы используете удалённый Mac, сначала настройте отдельного пользователя и рабочий каталог. Общие рекомендации по доступу к аренде Mac mini для удалённой разработки полезны именно на этом этапе: сначала ограничьте среду, затем переносите в неё агента, а не наоборот.

Этап 2. Терминал открывайте по командам, а не глобальным переключателем

После чтения и редактирования переходите к терминалу. Тестируйте команды по отдельности, потому что одинаковый исполняемый файл может быть безопасным в одном режиме и опасным в другом.

Проведите минимум четыре проверки:

  1. Сборка. Запустите команду с фиксированным рабочим каталогом и проверьте, не создаёт ли она файлы за его пределами.
  2. Модульные тесты. Убедитесь, что тесты не используют реальные внешние сервисы и не отправляют данные.
  3. Установка зависимостей. Проверьте lock-файл, сетевые адреса и сценарии post-install.
  4. Очистка. Используйте отдельную тестовую копию и убедитесь, что команда не превращается в удаление родительского каталога при ошибке пути.

К автоматическому списку можно относить только команды с понятным эффектом, фиксированными параметрами и возможностью повторного запуска. Команды публикации, удаления, изменения прав, работы с секретами, миграции продакшн-базы и обращения к домашнему каталогу должны оставаться ручными.

Для каждого разрешённого шаблона зафиксируйте:

  • точное имя исполняемого файла;
  • допустимый рабочий каталог;
  • допустимые аргументы;
  • запрещённые флаги;
  • пользователя, от имени которого выполняется команда;
  • ожидаемый код завершения;
  • способ остановки и восстановления.

Официальный CLI Roo Code имеет режим, требующий ручного подтверждения действий, включая команды, браузер и MCP. Это полезный контрольный режим для сравнения: если задача ведёт себя иначе при ручном подтверждении и при автоматическом, остановите расширение списка разрешений и ищите причину. (github.com)

Проход: команда выполняется только в заданном каталоге, не получает неожиданные секреты, а результат можно повторить и отменить.

Стоп: в аргументах появляются подстановки, цепочки команд, сетевые загрузки, неограниченные пути или обращение к изменённому скрипту.

Этап 3. MCP подключайте как набор отдельных полномочий

MCP нельзя оценивать по принципу «сервер известный, значит всё внутри безопасно». Один сервер может одновременно предоставлять чтение документации, запись данных, вызов внешнего API и доступ к чувствительным ресурсам.

Практически полезно разделить инструменты на четыре класса:

  • Чтение: поиск, получение схемы, просмотр статуса.
  • Запись: создание или изменение задач, файлов, записей и настроек.
  • Внешнее действие: отправка сообщений, публикация, запуск задачи или изменение облачного ресурса.
  • Чувствительный доступ: секреты, внутренние API, персональные данные и производственные системы.

Для каждого MCP-инструмента запишите:

  1. какие входные параметры он принимает;
  2. может ли параметр задавать путь, URL, идентификатор или команду;
  3. откуда берутся учётные данные;
  4. какие данные возвращаются в контекст модели;
  5. как отключить сервер;
  6. как отозвать токен;
  7. какой журнал подтверждает вызов.

Здесь важно проверять два независимых слоя. Первый — имеет ли текущий режим Roo Code доступ к группе MCP. Второй — разрешено ли конкретное MCP-действие автоматически. Это практическое следствие того, что Roo Code разделяет группы инструментов и отдельный тип автоодобрения MCP; включение одного уровня не должно автоматически считаться разрешением всех операций второго уровня. (github.com)

Если MCP не нужен для конкретной задачи, отключите его. Документация Roo Code прямо рекомендует не включать MCP без необходимости, поскольку подключённые серверы увеличивают контекст и могут влиять на расход токенов. (github.com)

Проход: разрешены только необходимые инструменты, параметры ограничены, токены не находятся в рабочем каталоге, а отзыв проверен отдельным действием.

Стоп: сервер получает больше данных, чем нужно задаче, инструмент может писать в производственную систему или невозможно установить, какой токен использовался.

Напоминание. Allowlist должен описывать не только сервер, но и конкретный инструмент, диапазон входных данных и допустимый результат. «Доверенный MCP» — это начало проверки, а не её итог.

FAQ: что проверять перед постоянной работой

Какие действия Roo Code можно безопасно автоматизировать

Наиболее подходящая стартовая группа — чтение файлов и каталогов в ограниченном репозитории. После этого можно добавить редактирование тестовой ветки, если каждый diff проверяется, а откат через Git уже подтверждён. Команды следует разрешать только по узким шаблонам. Секреты, публикацию, удаление, системные каталоги и внешние операции оставляйте под ручным подтверждением.

Какие риски создаёт автоматический запуск терминала

Риск определяется не названием команды, а всей строкой запуска. Текущий каталог, аргументы, переменные окружения и содержимое скрипта могут расширить действие. Особенно опасны цепочки команд, очистка, установка зависимостей с post-install, миграции и публикация. Для каждого разрешения нужны ограничения пути, пользователя, аргументов и способ остановки.

Как формировать список разрешённых MCP-инструментов

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

Нужна ли изоляция для безоператорного запуска

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

Этап 4. Удалённую среду проверяйте двумя сценариями

Для удалённого разработческого окружения подготовьте две задачи:

  • Разрешённая: чтение проекта, изменение одного тестового файла, запуск тестов и возврат к исходному состоянию.
  • Запрещённая: обращение к родительскому каталогу, чтение заранее созданного файла-маркера с секретом, вызов неразрешённого MCP-инструмента или попытка выполнить запрещённую команду.

Проверяйте результаты по шести направлениям:

  1. рабочий каталог и права файлов;
  2. сетевой выход и список доступных адресов;
  3. переменные окружения и доступные ключи;
  4. журнал команд и MCP-вызовов;
  5. остановка по тайм-ауту;
  6. восстановление репозитория и удаление временных данных.

Если задача использует Xcode, macOS SDK, симулятор, подписывание или физические интерфейсы, не переносите выводы из обычного контейнера на удалённый Mac. Такой сценарий нужно тестировать отдельно: важны доступ к брелоку ключей, сертификатам, симуляторам, SSH и локальным инструментам сборки.

Перед передачей ключей изучите собственную схему разделения конфиденциальных данных в удалённой среде. Roo Code должен получать не «весь набор секретов пользователя», а минимальные временные полномочия под одну задачу.

Этап 5. Установите лимит запросов и журналирование

Даже корректные разрешения могут привести к длинной цепочке действий. В документации Roo Code описан параметр максимального числа автоматически одобренных запросов: после достижения лимита выполнение приостанавливается и требует продолжения. Это не заменяет проверку команд, но создаёт дополнительную точку остановки для зависших или повторяющихся задач. (github.com)

Для первой удалённой проверки выбирайте конечный лимит, а не бессрочный режим. В журнале должны быть видны:

  • начало и завершение задачи;
  • все команды и аргументы;
  • изменённые файлы;
  • вызванные MCP-инструменты;
  • ошибки и повторные попытки;
  • причина остановки;
  • результат отката.

Не считайте отсутствие ошибки доказательством безопасности. Важнее убедиться, что журнал позволяет ответить на вопрос: что именно агент сделал, с какими полномочиями и какой внешний результат получил.

Этап 6. После изменений возвращайтесь к исходной проверке

Автоодобрение нельзя настраивать один раз навсегда. Повторную проверку запускайте после:

  • обновления Roo Code;
  • изменения MCP-сервера или его схемы;
  • изменения скриптов сборки;
  • добавления нового ключа или переменной окружения;
  • переноса проекта на другой удалённый Mac;
  • изменения режима или списка доступных инструментов;
  • перехода с тестовой ветки на основную.

Правило принятия решения простое:

  • Сохранить разрешение, если область действия прежняя, diff и журналы предсказуемы, а обе тестовые задачи прошли.
  • Сузить разрешение, если изменились параметры, скрипты, MCP-схема или сетевые требования.
  • Отозвать разрешение, если появился доступ к секретам, публикации, удалению, системным каталогам или невозможно доказать корректный откат.

Для постоянных задач полезно разделять профиль повседневной разработки и профиль безоператорного запуска. Не переносите настройки рабочего чата на удалённую машину автоматически. Отдельный аккаунт, отдельный репозиторий и отдельный набор ключей дают более понятную границу ответственности; дополнительные материалы по управлению аккаунтом доступны в разделе SSHMac для пользователей.

Когда текущая среда хуже отдельного Mac для Roo Code

Если Roo Code запускается прямо на вашей рабочей станции, у него часто оказывается слишком широкий контекст: домашний каталог, личные ключи, браузерные сессии, локальные конфигурации и доступ к нескольким проектам. Контейнер в облаке, напротив, может не иметь нужного Xcode, macOS SDK, симулятора или стабильного доступа к инструментам Apple. Локальный Hackintosh добавляет проблемы с обновлениями, совместимостью и восстановлением.

Для короткого теста подойдёт локальный запуск с ручным контролем. Для постоянной работы с macOS-инструментами разумнее вынести Roo Code на отдельный удалённый Mac, где можно выделить пользователя, рабочий каталог, сетевые ограничения и отдельные ключи. Такой вариант имеет смысл рассматривать не как способ включить все разрешения, а как основу для контролируемого тестового контура: сначала низкорисковая задача, затем проверка журналов, блокировки неразрешённых действий и отката, и только после этого — расширение allowlist.

Начните с одной тестовой ветки и чтения, добавьте ограниченное редактирование, затем проверьте четыре класса терминальных команд и каждый MCP-инструмент отдельно. Если хотя бы один из трёх контрольных результатов — журнал, блокировка запрещённого действия или восстановление — не подтверждён, возвращайтесь к предыдущему уровню разрешений, а не включайте глобальное автоодобрение.