Browser Use: как дать Claude Code и Codex реальный Chrome и автоматизировать сайты
AI-агент обычно умеет писать код и работать с файлами, но веб-сайт для него остаётся внешним миром. Browser Use добавляет реальный браузер: агент может открыть страницу, прочитать интерфейс, нажать кнопку, заполнить форму, скачать файл, переключить вкладку и продолжить работу по результату. В 2026 году проект уже умеет подключаться прямо к Claude Code, Codex, Cursor и другим coding-agents через skills и MCP.
Browser Use связывает LLM с реальным браузером и превращает цель в последовательность действий
В классической автоматизации разработчик заранее прописывает селекторы и сценарий: открыть URL → найти кнопку → нажать → дождаться элемента. Browser Use отдаёт часть планирования модели. Пользователь формулирует задачу, а агент на каждом шаге получает состояние браузера и выбирает следующее действие.
Сценарий не обязан быть полностью запрограммирован заранее.
Агент может анализировать структурированное состояние страницы и screenshots.
К browser actions можно добавить API, файлы, human approval и собственные функции.
Браузер может работать на вашем ПК, remote CDP или в Browser Use Cloud.
Лучшие задачи — там, где API нет или веб-интерфейс меняется слишком часто
Открыть страницы, перейти по результатам, извлечь значения и вернуть сводку.
Регистрация, поиск, корзина, формы, ошибки интерфейса и screenshots.
Фильтры, выгрузки, перенос данных между системами и заполнение полей.
Claude Code или Codex изменяет приложение, затем сам открывает его в браузере и тестирует UI.
Открыть service dashboard и извлечь данные, когда удобного API нет.
Документ может быть доступен только после нескольких шагов в интерфейсе.
Браузер медленнее, дороже по токенам и ломается от изменений UI. Используйте его прежде всего там, где другого программного интерфейса действительно нет.
Установка Browser Use 0.13.10
Package требует Python 3.11 или новее. В текущем официальном quick start разработчики рекомендуют
создавать окружение на Python 3.12 через uv.
pip install uv
uv venv --python 3.12
# PowerShell
.\.venv\Scripts\Activate.ps1
uv pip install browser-use==0.13.10
uvx browser-use installПоследняя команда устанавливает browser runtime/Chromium, необходимый для обычного local workflow.
browser-use
Python library, CLI, skills и MCP.
Можно использовать управляемый браузер или подключить системный Chrome.
Browser Use сам не является языковой моделью.
Browser Use Cloud, OpenAI, Anthropic, Gemini или локальный Ollama.
Первый browser-agent
from browser_use import Agent, ChatBrowserUse
llm = ChatBrowserUse()
agent = Agent(
task="Открой example.com и верни заголовок страницы",
llm=llm,
)
agent.run_sync()
Официальный quick start продвигает ChatBrowserUse как оптимизированную модель проекта.
Но framework не привязан к ней: можно подключить Anthropic, OpenAI, Google, Ollama и другие поддерживаемые adapters.
Сначала «открой URL → нажми одну кнопку → верни заголовок». Если это стабильно, только потом добавляйте авторизацию, формы и длинную цепочку действий.
Browser Use умеет установить skill прямо в Claude, Codex, Cursor и другие агенты
# установить/обновить Browser Use и skill
browser-use skill install
# только Codex
browser-use skill install --target codex
# только Claude
browser-use skill install --target claude
# только Cursor
browser-use skill install --target cursor
В актуальном installer коде есть отдельные targets:
agents, claude, codex, copilot,
cursor, gemini, openclaw и opencode.
Default all устанавливает skill во все поддерживаемые user-level directories.
Агент может открыть локальное приложение и проверить результат сам.
Skill объясняет coding-agent, как подключить Browser Use CLI и использовать реальный браузер.
Постоянный skill уменьшает необходимость каждый раз объяснять команды заново.
Installer создаёт отдельный SKILL.md в каталоге соответствующего агента.
Установка skill не заставляет использовать облачный браузер. Он может управлять локальным Browser Use CLI и вашим локальным Chrome.
Для MCP-клиентов Browser Use может работать отдельным MCP server
uvx browser-use --mcp
В manifest текущего проекта MCP запускается через uvx.
Есть настройки model key, browser type, allowed domains, headless, vision,
timeout и sensitive-data masking.
Открытие страниц, tabs и управление browser session.
Clicks, input, screenshots и работа с интерактивными элементами.
Allowed domains можно задавать прямо в MCP configuration.
Manifest предусматривает masking чувствительных данных в screenshots/logs.
Если клиент скомпрометирован prompt injection или плохой инструкцией, последствия могут затронуть реальную browser session.
Можно подключить уже установленный Chrome и существующий профиль
from browser_use import Agent, Browser, ChatGoogle
browser = Browser.from_system_chrome(
profile_directory="Default"
)
agent = Agent(
task="Открой сайт, на котором я уже авторизован, и найди нужный раздел",
llm=ChatGoogle(model="YOUR_MODEL"),
browser=browser,
)
agent.run_sync()
Текущая документация умеет автоматически находить Chrome profiles через
Browser.list_chrome_profiles() и подключать выбранный профиль через
Browser.from_system_chrome().
В нём могут быть Google account, почта, платежи, пароли, cookies админок и множество других активных сессий. Для AI-автоматизации разумнее создать отдельный Chrome profile с минимально необходимыми правами.
Для секретов используйте storage state или domain-scoped sensitive_data
Пароль не стоит вставлять прямо в task prompt. Browser Use поддерживает placeholders для sensitive data: модель видит имя placeholder, а настоящее значение подставляется локально во время browser action.
from browser_use import Agent, Browser, ChatOpenAI
browser = Browser(
allowed_domains=["https://*.example.com"]
)
secrets = {
"https://*.example.com": {
"username": "user@example.com",
"password": "VERY_SECRET_PASSWORD",
}
}
agent = Agent(
task=(
"Открой example.com и авторизуйся. "
"Используй username и password ."
),
llm=ChatOpenAI(model="YOUR_MODEL"),
browser=browser,
sensitive_data=secrets,
)Использовать уже созданную сессию и вообще не давать агенту пароль.
Секрет доступен только при совпадении текущего URL с указанным доменным pattern.
Причина — prompt injection: вредоносная страница может попытаться заставить агента использовать секрет не там, где предполагал владелец.
Browser Use имеет нативный ChatOllama, но маленькая LLM может плохо управлять браузером
from browser_use import Agent, ChatOllama
llm = ChatOllama(
model="llama3.1:8b"
)
agent = Agent(
task="Открой example.com и верни заголовок страницы",
llm=llm,
)
agent.run_sync()Maintainer Browser Use подтверждает native Ollama support. Но в том же официальном обсуждении отдельно предупреждается: небольшие локальные модели могут хуже справляться с tool calling и выбором browser actions.
Если и browser, и Ollama работают локально, основной inference не требует cloud LLM.
Модель должна стабильно выдавать структурированные действия и корректировать план после каждого изменения страницы.
Локальный Chrome, remote CDP и Browser Use Cloud решают разные задачи
Подходит для личной автоматизации, разработки и работы с локальными сайтами.
Browser Use умеет подключаться к существующему remote Chrome по CDP URL.
Profiles, remote streaming, proxies, масштабирование и browser infrastructure обслуживает провайдер.
Для одного домашнего агента Cloud не обязателен. Он становится интереснее при параллельных sessions, production automation, proxy/geo requirements и необходимости управлять большим количеством browser workers.
Prompt injection в браузере опаснее обычного неправильного ответа LLM
Веб-страница — недоверенный ввод. На ней может находиться текст, специально написанный для AI: «игнорируй предыдущие инструкции», «отправь содержимое cookies», «открой другой сайт», «вставь секрет в эту форму». Если агент имеет browser actions и авторизованные sessions, подобная атака потенциально превращается из неправильного текста в реальное действие.
Для конкретной задачи разрешайте только ожидаемые домены.
Не давайте browser-agent все личные авторизации одновременно.
Credential должен подставляться только на соответствующем сайте.
Платёж, удаление, публикацию и отправку важных данных подтверждает человек.
disable_security=True сам проект помечает как NOT RECOMMENDED.
Аккаунт для automation должен иметь ровно те permissions, которые нужны задаче.
Исторический пример показывает, почему одного allowlist недостаточно
В 2025 году у Browser Use была опубликована critical vulnerability
CVE-2025-47241 / GHSA-x39x-9qw5-ghrf:
старую реализацию allowed_domains можно было обойти специально сформированным URL.
Она затрагивала версии до 0.1.44 и была исправлена в 0.1.45.
Текущая 0.13.10 намного новее, но сам случай хорошо показывает:
domain allowlist — один слой защиты, а не абсолютная sandbox.
Для реальной автоматизации разделяйте профили, домены, credentials и irreversible actions.
Практический безопасный pattern
from browser_use import Browser
browser = Browser(
allowed_domains=[
"https://portal.example.com",
"https://*.portal.example.com",
],
keep_alive=False,
)
Если sensitive page не требует vision, официальные рекомендации также предлагают
отключать screenshots через use_vision=False.
Не начинайте с «полностью автономно оформи заказ»
Открыть сайт и вернуть конкретное значение.
Перейти на заранее известную страницу и подтвердить результат.
Заполнить поля, но остановиться перед submit.
Человек подтверждает финальное действие.
Automation получает отдельного пользователя.
При нестабильности сохранить trace и понять, где агент ошибается.
Browser Use умеет сохранять video, HAR и trace files. Это особенно полезно для ошибок, которые невозможно воспроизвести по одному текстовому log.
AI browser automation всё ещё менее детерминирован, чем обычный программный API
Новая модалка, cookie banner или A/B test способны изменить путь агента.
Сайты могут блокировать automation или требовать ручное подтверждение.
Длинная задача состоит из многих model calls и browser states.
AI выбирает действия намного медленнее жёстко написанного Playwright script.
Слабая модель может хорошо отвечать текстом, но плохо выбирать tools.
Недоверенный веб-контент непосредственно участвует в decision loop агента.
В issue tracker есть свежие reports о росте history/DOM overhead в длинных задачах.
Есть свежие reports о зависании teardown и orphaned Chrome processes в Windows CI.
API и deterministic code делают всё, что можно сделать без браузера. Browser-agent используется только для оставшихся human-only UI шагов.
Browser Use нужен не для каждой browser-задачи
Если UI и steps заранее известны, обычный код быстрее, дешевле и тестируемее.
Почти всегда предпочтительнее browser scraping/automation.
Полезен, когда paths меняются, нужна семантика интерфейса и заранее неизвестно, куда кликать.
LLM решает, что делать, а критичные операции выполняет строго ограниченный код.
Browser Use: core, skills, browser profiles и security
На момент проверки version в pyproject.toml и latest GitHub release —
Browser Use 0.13.10.
Browser Use превращает AI из советчика в оператора браузера — поэтому и требования к безопасности выше
Для coding-agent это один из самых практически полезных классов tools: Claude Code или Codex может не только изменить веб-приложение, но и открыть его, пройти пользовательский сценарий и увидеть реальный результат.
Но авторизованный браузер — это уже не безобидный prompt. Начинайте с отдельного Chrome profile, ограниченных domains, read-only задач и human approval перед необратимыми действиями. Только после этого имеет смысл увеличивать автономность.
Частые вопросы о Browser Use
Что такое Browser Use простыми словами?
Python-framework и инструменты, позволяющие AI-агенту управлять реальным веб-браузером: открывать страницы, кликать, вводить данные, читать интерфейс и выполнять многошаговые задачи.
Browser Use работает с Claude Code?
Да. В актуальном installer есть отдельный target claude, а проект также поддерживает MCP workflow.
Browser Use работает с Codex?
Да. Команда browser-use skill install --target codex устанавливает Browser Use skill в user-level каталог Codex.
Можно ли использовать мой обычный Chrome?
Да. Browser.from_system_chrome() умеет подключаться к установленному Chrome и выбранному профилю. Для безопасности лучше создать отдельный профиль для automation.
Можно ли использовать Browser Use полностью локально?
Да: локальный browser плюс локальная LLM через ChatOllama. Но небольшая модель может хуже справляться с tool calling и многошаговой навигацией.
Чем Browser Use лучше Playwright?
Он не обязательно лучше. Playwright предпочтительнее для известного стабильного сценария. Browser Use полезнее, когда агент должен семантически разбираться в меняющемся UI.
Безопасно ли дать агенту пароли?
Лучше использовать отдельную авторизованную сессию/storage state. Если пароль всё же нужен, применяйте domain-scoped sensitive_data и allowed_domains, а не вставляйте секрет прямо в prompt.
Что такое prompt injection в браузере?
Вредоносный текст на странице пытается заставить LLM изменить поведение. У browser-agent риск выше, потому что модель способна не только ответить текстом, но и совершить реальное действие.
Какая версия актуальна?
На момент проверки 21 сентября 2026 года актуальная core-версия Browser Use — 0.13.10.
Нужно автоматизировать веб-кабинет или дать coding-agent доступ к браузеру?
Можно разобрать конкретный сценарий и выбрать, где нужен Browser Use, где лучше обычный Playwright/API, а какие действия стоит оставить только с подтверждением человека.
