Веб-поиск и браузер в задачах Codex

Веб-поиск отвечает на вопрос об актуальной внешней информации, а браузер проверяет реально отрисованный интерфейс и пользовательский сценарий.

Краткий ответ

Веб-поиск отвечает на вопрос об актуальной внешней информации, а браузер проверяет реально отрисованный интерфейс и пользовательский сценарий. Их доступность зависит от поверхности и настроек: встроенный Browser доступен в ChatGPT web и desktop app, но не является встроенной возможностью Codex CLI или IDE extension.

Веб-поиск отвечает на вопрос об актуальной внешней информации, а браузер проверяет реально отрисованный интерфейс и пользовательский сценарий. Это разные инструменты. Их доступность зависит от поверхности и настроек: встроенный Browser доступен в ChatGPT web и desktop app, но не является встроенной возможностью Codex CLI или IDE extension.

Когда нужен веб-поиск

Используйте поиск, если факт мог измениться:

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

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

Локальные Codex-клиенты поддерживают режимы поиска. Кешированный поиск снижает, но не устраняет риск prompt injection; для действительно текущих данных нужен live search, если он разрешён конфигурацией.

Когда нужен реальный браузер

DOM, CSS, загрузочные состояния и навигация зависят от runtime. Браузер нужен, чтобы:

• воспроизвести визуальный дефект;
• проверить гостя и авторизованного пользователя;
• увидеть console errors и сетевые ответы;
• проверить focus, keyboard navigation и адаптивность;
• сравнить live DOM с prerendered HTML;
• подтвердить состояние loading, empty, error и success.

Чтение компонента не доказывает, что элемент помещается при ширине 360 px. Snapshot одного desktop-экрана не проверяет мобильный layout.

Сценарий браузерной проверки

Маршрут: http://localhost:5173/rating
Состояние: новый профиль браузера, без cookie и localStorage.

1. Открыть маршрут напрямую.
2. Дождаться завершения публичного запроса.
3. Проверить отсутствие персональной нижней плашки и её loader.
4. Убедиться, что публичная таблица видна.
5. Проверить console errors.
6. Повторить после входа и убедиться, что персональная плашка появляется.

Сценарий фиксирует исходное состояние. Без него сохранённая cookie может случайно превратить «гостевой» тест в авторизованный.

Внешняя страница — недоверенный контекст

Текст сайта может содержать вредоносные инструкции: попросить раскрыть секрет, изменить разрешения или выполнить команду. Разрешение открыть домен не означает доверие содержимому и не подтверждает каждое действие.

Правила:

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

Как совместить код и интерфейс

После воспроизведения сохраните наблюдение: viewport, роль, шаг, console/network сигнал. Затем найдите соответствующий путь в коде и создайте автоматический тест на устойчивое правило. После изменения повторите тот же браузерный сценарий.

Браузерная проверка не должна оставаться единственным тестом для простой логики авторизации. И наоборот, jsdom-тест не заменяет реальный layout.

Практика: двойная проверка

Выберите зависимость, версия которой недавно менялась, и UI-баг:

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

Сравните, какие факты дал поиск, а какие можно было получить только из runtime.

Частые вопросы

Почему Browser не появляется в Codex CLI?

Официальная документация указывает, что встроенный Browser доступен в ChatGPT web и desktop app, но не в CLI или IDE extension. В этих средах браузерная автоматизация возможна только через отдельно подключённый инструмент или MCP, если он настроен.

Достаточно ли кешированного поиска для документации?

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

Нужно ли проверять каждую UI-правку вручную?

Проверка должна быть пропорциональна риску. Изменение layout, auth state или интерактивности требует браузера; чистое переименование внутреннего типа без UI-эффекта — нет.

Что важно запомнить

• Поиск даёт актуальные внешние факты, браузер — runtime-поведение.
• Доступность Browser зависит от поверхности и конфигурации.
• Всегда задавайте начальное состояние, роль и viewport сценария.
• Веб-контент остаётся недоверенным даже после разрешения открыть сайт.

https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-10