В обычной разработке речь идет прежде всего о работе с файлами, командах терминала, операциях Git и локальных инструментах. В проектах с MegaIndex BrowserAPI последствия шире: одна разрешенная команда может открыть удаленный браузер, восстановить сессию, войти в аккаунт, перейти по нескольким страницам, скачать данные или отправить форму.
Поэтому браузерную автоматизацию нужно контролировать на двух уровнях:
- Разрешения Claude Code определяют, что агент может запускать в локальной среде.
- Ограничения BrowserAPI определяют, что разрешено удаленному браузеру.
Первый уровень отвечает за запуск задачи. Второй — за действия после подключения к браузеру.
Почему для удаленного браузера одних разрешений Claude Code недостаточно
Рассмотрим команду:
node scripts/check-account.mjs
На первый взгляд она безопасна: запускается обычный процесс Node.js.
Но внутри скрипта MegaIndex BrowserAPI может открыть удаленный Chromium и выполнить целую последовательность действий:
- загрузить сохраненные cookies;
- войти в аккаунт;
- перейти по редиректам;
- открыть внутренние страницы;
- собрать данные;
- скачать отчет;
- нажать кнопку подтверждения.
Claude Code видит команду терминала, но не всегда понимает назначение каждого действия, которое выполняет браузер.
Режим разрешений может запретить запуск неподтвержденного скрипта. Но он не определит, что именно делает кнопка Confirm: применяет фильтр, публикует страницу, удаляет запись или подтверждает платеж.
Поэтому разрешения Claude Code — это внешний уровень защиты, а не полноценная политика управления браузером.
Как выбрать режим для проекта с BrowserAPI
Claude Code поддерживает несколько режимов разрешений. Каждый из них подходит для своего типа задач.
| Режим | Когда использовать |
|---|---|
| Manual | Аудит, проверка кода, работа с производственными аккаунтами и чувствительными сценариями |
| Accept edits | Реализация уже согласованного сценария на Playwright или Puppeteer |
| Plan | Проектирование многоэтапной автоматизации до изменения файлов |
| Auto | Продолжительная разработка в изолированной тестовой среде |
| Don’t ask | CI, регулярные проверки и другие задачи без участия человека |
| Bypass permissions | Только изолированные одноразовые контейнеры или виртуальные машины |
При выборе режима важно учитывать не только объем изменений в коде, но и сам браузерный сценарий:
- какой аккаунт используется;
- есть ли в сессии сохраненные cookies;
- может ли сценарий изменить данные;
- где он выполняется — в staging или production;
- будет ли кто-то проверять запросы на подтверждение;
- можно ли тестами доказать, что браузер выполнил нужное действие.
Manual — для проверки и чувствительных сессий
Manual — наиболее безопасный режим для начала работы с BrowserAPI.
Он подходит, когда Claude должен проверить:
- код подключения к браузеру;
- селекторы;
- логику авторизации;
- восстановление сессии;
- скриншоты;
- трейсы Playwright;
- логи выполнения;
- повторные попытки и тайм-ауты.
Manual также следует использовать при работе с:
- производственными аккаунтами;
- административными панелями;
- платежными разделами;
- персональными данными;
- интерфейсами публикации;
- настройками аккаунта;
- необратимыми действиями.
Проверка не должна незаметно превращаться в редактирование и запуск. Если Claude анализирует BrowserAPI-скрипт, он не должен одновременно переписывать его и выполнять в рабочем аккаунте без отдельного подтверждения.
Первый запуск любого авторизованного сценария лучше проводить вручную, даже если код выглядит простым.
Plan — перед сложной браузерной автоматизацией
Plan стоит использовать, если задача сложнее небольшой правки селектора.
Начинайте с этого режима, когда сценарий:
- затрагивает несколько файлов;
- восстанавливает авторизованную сессию;
- работает с несколькими доменами;
- загружает или скачивает файлы;
- содержит повторные попытки или резервные ветки;
- изменяет состояние аккаунта;
- обрабатывает редиректы;
- использует постоянный профиль браузера.
Хороший план должен описывать не только изменения в коде, но и весь браузерный маршрут.
В него следует включить:
- начальный URL;
- разрешенные домены;
- условия авторизации;
- источники учетных данных и cookies;
- действия только для чтения;
- действия, изменяющие данные;
- лимиты повторных попыток и тайм-аутов;
- условие успешного выполнения;
- скриншоты, трейсы и логи, которые нужно сохранить;
- порядок закрытия сессии.
Так проблемы можно заметить до начала реализации.
Например, задача «скачать последний счет» может потребовать открыть платежный аккаунт, восстановить профиль, пройти внешний редирект авторизации и перейти на страницу, где рядом с кнопкой скачивания находятся элементы управления оплатой.
Это должно быть отражено в плане заранее.
Accept edits — для реализации согласованного сценария
После проверки плана можно перейти в режим Accept edits.
В нем Claude может работать с:
- Playwright- и Puppeteer-скриптами;
- модулем подключения к BrowserAPI;
- вспомогательными функциями навигации;
- логикой извлечения данных;
- повторными попытками;
- логированием;
- тестовыми фикстурами;
- созданием скриншотов;
- закрытием сессий.
Так Claude сможет менять файлы без постоянных запросов, а запуск чувствительных команд останется под отдельным контролем.
После завершения работы обязательно проверьте diff. Особое внимание стоит обратить на:
- слишком общие селекторы вроде button или text=Confirm;
- отсутствие проверки hostname;
- бесконечные циклы повторных попыток;
- повторное использование постоянного профиля;
- попадание учетных данных в логи;
- автоматическую отправку форм;
- резервные клики по неточным селекторам;
- обработчики ошибок, которые продолжают выполнение после неожиданного состояния страницы.
Разрешение на изменение файлов не означает согласия со всеми действиями, которые после этого выполнит браузер.
Auto — только для тестовой среды
В режиме Auto Claude может менять код, запускать команды, анализировать ошибки и продолжать работу без подтверждения каждого шага.
Для MegaIndex BrowserAPI этот режим полезен, но только в контролируемом окружении.
Безопасная среда для Auto должна включать:
- тестовый сайт;
- отдельные тестовые аккаунты;
- одноразовые браузерные сессии;
- строгий список разрешенных доменов;
- учетные данные с ограниченными правами;
- лимиты переходов и действий;
- автоматические тесты;
- скриншоты или трейсы после ключевых шагов.
Auto подходит для таких задач:
- исправление селекторов после изменения интерфейса;
- настройка ожиданий и тайм-аутов;
- повторный запуск браузерных тестов;
- сравнение скриншотов;
- поиск причин ошибок при извлечении данных;
- проверка и улучшение закрытия сессий.
Для производственных аккаунтов использовать Auto по умолчанию не стоит.
Система может распознать явно опасную команду, например принудительный push или развертывание в production. Но обычный клик в браузере с точки зрения терминала выглядит безобидно, даже если на странице он подтверждает критическое действие.
Например:
await page.getByRole("button", { name: "Confirm" }).click();
Риск этой команды зависит не от кода, а от контекста страницы.
Поэтому Auto нужно дополнять ограничениями на стороне браузера и автоматической проверкой результата.
Don’t ask — для автоматических запусков
Режим Don’t ask предназначен для задач, которые выполняются без участия человека.
Типичные сценарии:
- плановые проверки доступности;
- ночные тесты рендеринга;
- сравнение скриншотов;
- браузерные smoke-тесты в CI;
- извлечение данных с заранее разрешенных страниц;
- регрессионные тесты после развертывания.
В таком режиме должны выполняться только заранее разрешенные команды. Все остальные действия должны завершаться ошибкой, а не ожидать подтверждения.
Не используйте слишком широкие правила:
Bash node * npm * git
По такой конфигурации невозможно понять, какие именно действия разрешены автоматическому процессу.
Лучше разрешить конкретную команду:
Bash(npx playwright test tests/browser/staging*)
То же правило действует для браузерных скриптов. Если CI только проверяет отображение страницы, ему не нужны данные административного аккаунта или доступ к постоянному профилю.
Bypass — только при полной изоляции
Режим Bypass отключает обычные проверки разрешений.
Использовать его можно только в изолированном контейнере или виртуальной машине, где:
- находится временная копия проекта;
- используются только тестовые учетные данные;
- не подключен домашний каталог;
- нет производственных SSH-ключей;
- нет личных cookies;
- нет доступа к рабочей базе данных;
- используется одноразовый профиль BrowserAPI;
- ограничен исходящий сетевой трафик.
Сам по себе контейнер не гарантирует безопасность.
Если передать ему производственные секреты, постоянную браузерную сессию и неограниченный доступ к сети, он все равно получит доступ к рабочей инфраструктуре.
Изоляция должна охватывать обе части системы:
- среду, в которой работает Claude;
- удаленный браузер, которым он управляет.
Разрешения Claude Code не управляют действиями внутри браузера
Распространенная ошибка — считать, что Claude понимает назначение каждого действия Playwright или Puppeteer.
Обычно это не так.
Для Claude Code весь процесс может выглядеть как одна разрешенная команда:
npm run browser:check
Но внутри браузера скрипт может:
- открыть другой домен;
- восстановить cookies аккаунта;
- перейти на закрытую страницу;
- загрузить файл;
- отправить форму;
- выполнить необратимое действие.
Поэтому ограничения нужно добавлять непосредственно в интеграцию с BrowserAPI.
Ограничьте список доменов
Проверяйте hostname перед каждым переходом и после каждого редиректа.
Недостаточно проверить только начальную страницу. Внешняя авторизация, ссылки на скачивание, реклама, скомпрометированная страница или неожиданный редирект могут отправить браузер на другой домен.
Пример:
const allowedHosts = new Set([
"staging.example.com",
"accounts.example.com"
]);
function assertAllowedUrl(rawUrl) {
const url = new URL(rawUrl);
if (!allowedHosts.has(url.hostname)) {
throw new Error(`Navigation to unapproved host: ${url.hostname}`);
}
}
page.on("framenavigated", frame => {
if (frame === page.mainFrame()) {
assertAllowedUrl(frame.url());
}
});
Такая проверка должна находиться в браузерном коде. Тогда смена режима Claude Code не позволит ее обойти.
Разделяйте чтение и изменение данных
Не стоит объединять все действия в один универсальный скрипт.
Лучше использовать отдельные точки входа для:
- чтения и извлечения данных;
- отправки форм;
- публикации;
- изменения аккаунта;
- удаления;
- операций, связанных с оплатой.
Скрипт только для чтения не должен содержать универсальную функцию, способную нажать любой элемент по переданному тексту.
Разделение также упрощает настройку разрешений:
scripts/browser/read-dashboard.mjs scripts/browser/update-profile.mjs scripts/browser/publish-page.mjs
Первый скрипт можно разрешить в CI. Для запуска скрипта публикации должно требоваться отдельное подтверждение.
Используйте аккаунты с минимальными правами
Аккаунт браузера должен иметь только те права, которые нужны для конкретной задачи.
Тесту, проверяющему загрузку панели управления, не требуется доступ к:
- платежным разделам;
- управлению пользователями;
- API-ключам;
- удалению аккаунта;
- публикации;
- способам оплаты.
Это ограничивает последствия неправильного селектора, неожиданного редиректа или ошибки в логике сценария.
Используйте временные сессии для автономных задач
Постоянные профили удобны: они сохраняют cookies и состояние авторизации.
Но вместе с этим они увеличивают риск.
В профиле могут находиться активные сессии других сервисов, история аккаунта и чувствительные cookies. Для автономных запусков лучше создавать временный профиль под одну задачу и удалять его после завершения.
Постоянные сессии стоит использовать только тогда, когда без них нельзя обойтись, и только с отдельными тестовыми аккаунтами.
Задайте жесткие лимиты
Браузерный сценарий не должен работать бесконечно, если не может определить, выполнена ли задача.
Ограничьте:
- общее время выполнения;
- количество переходов;
- число открытых страниц;
- повторные попытки для каждого шага;
- размер скачиваемых файлов;
- количество скриншотов;
- общее число браузерных действий;
- количество доменов, открытых через редиректы.
Пример:
const limits = {
maxNavigations: 10,
maxActions: 40,
maxRetriesPerStep: 2,
maxRuntimeMs: 120000
};
После достижения лимита сессию нужно остановить, а трейс сохранить для проверки.
Сохраняйте подтверждение результата
Нулевой код завершения означает только то, что процесс не сообщил об ошибке. Он не доказывает, что браузер выполнил нужную задачу.
После важных запусков сохраняйте:
- трейсы Playwright;
- скриншоты;
- конечные URL;
- ошибки консоли;
- неудачные сетевые запросы;
- журнал действий;
- извлеченные данные;
- результаты проверок.
Если сценарий меняет данные, фиксируйте состояние страницы до и после действия.
Добавьте Stop hook
Auto оценивает действие до запуска. Stop hook проверяет результат после того, как Claude закончил работу.
В проекте с BrowserAPI такой hook может запускать линтер и браузерные тесты в staging.
Пример файла .claude/settings.json:
{
"permissions": {
"defaultMode": "plan",
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./browser-data/**)",
"Bash(git push --force*)",
"Bash(git remote add *)",
"Bash(git remote set-url *)"
],
"ask": [
"Bash(node scripts/browser/run-production.mjs *)"
],
"allow": [
"Bash(npx playwright test tests/browser/staging*)"
]
},
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/verify-browser-tests.sh",
"timeout": 300
}
]
}
]
}
}
Пример файла .claude/hooks/verify-browser-tests.sh:
#!/usr/bin/env bash
set -uo pipefail
cat >/dev/null
cd "${CLAUDE_PROJECT_DIR:?CLAUDE_PROJECT_DIR is not set}"
if npm run lint && npx playwright test tests/browser/staging; then
exit 0
fi
echo "Browser verification failed." >&2
exit 2
Сделайте файл исполняемым:
chmod +x .claude/hooks/verify-browser-tests.sh
Тесты должны проверять не только доступность страницы, но и фактический результат сценария:
- конечный hostname входит в список разрешенных;
- использован нужный тестовый аккаунт;
- страница находится в ожидаемом состоянии;
- не была случайно отправлена другая форма;
- получен нужный результат;
- все страницы и сессии закрыты.
Рекомендуемый порядок работы
| Задача | Рекомендуемый режим |
|---|---|
| Проверка репозитория | Manual |
| Проектирование сценария | Plan |
| Реализация | Accept edits |
| Первый авторизованный запуск | Manual |
| Регулярная разработка в staging | Auto с тестами и Stop hook |
| CI и плановые проверки | Don’t ask с точным списком разрешенных команд |
| Одноразовые эксперименты | Bypass только в изолированном контейнере или виртуальной машине |
| Изменения в production | Manual |
Промпт для Claude Code
Проверь проект с MegaIndex BrowserAPI и подготовь безопасный план браузерной автоматизации. 1. Оставайся в режиме Plan. Не изменяй файлы и не запускай браузер. 2. Найди все файлы, связанные с подключением к BrowserAPI. 3. Укажи начальный URL, разрешенные хосты, возможные редиректы и внешние endpoints. 4. Отдели действия только для чтения от действий, которые меняют состояние удаленной системы. 5. Покажи, где в сценарий передаются учетные данные, cookies, профили браузера и токены сессии. 6. Определи лимиты переходов, повторных попыток, браузерных действий, скачиваний и общего времени выполнения. 7. Укажи, какие скриншоты, трейсы, логи и проверки нужны для подтверждения результата. 8. Перечисли команды staging, которые можно запускать автоматически. 9. Отметь все производственные, административные, платежные, удаляющие и публикующие действия как требующие подтверждения. 10. Верни план реализации, список затрагиваемых файлов, основные риски, тесты и точную команду для первого контролируемого запуска.
Главное правило
Разрешения Claude Code определяют, может ли агент запустить задачу BrowserAPI. Они не контролируют каждое действие внутри удаленного браузера.
Используйте Plan для проектирования, Accept edits — для реализации, Manual — для первого авторизованного запуска и любых действий в production. Auto подходит только для staging, а Don’t ask — для строго ограниченных автоматических проверок.
На стороне браузера все равно нужны разрешенные домены, аккаунты с минимальными правами, лимиты выполнения, временные сессии и тесты, которые подтверждают фактический результат.
Обсуждение