Флаг Codex CLI —search: как включить веб-поиск

Флаг Codex CLI --search применяется для включения веб-поиска во время работы агента: с его помощью Codex может искать актуальную информацию в интернете, проверять документацию, находить свежие версии библиотек и сопоставлять сведения из нескольких источников. Это особенно полезно в тех случаях, когда встроенных знаний модели недостаточно или когда важна информация, изменившаяся после обучения модели.

--search добавляет к работе Codex доступ к веб-поиску, но не превращает каждый ответ в автоматически проверенное исследование. Агент всё равно должен правильно сформулировать запрос, выбрать подходящие источники и критически оценить найденные данные.

Важно понимать границы этого режима. Флаг не предназначен для поиска по локальному проекту — для такой задачи используются обычные команды оболочки и инструменты работы с файлами. --search нужен именно тогда, когда Codex требуется обратиться к внешней, потенциально обновляемой информации: официальной документации, страницам релизов, спецификациям, issue-трекерам, справочным материалам и другим веб-источникам.

Как использовать --search

В этом разделе разберём базовый синтаксис, место флага в команде и условия, от которых зависит результат. Сам по себе параметр прост, но его полезность сильно связана с тем, насколько точно сформулирована задача для агента.

Флаг включает возможность поиска, а не формулирует поисковую задачу за пользователя. Чем конкретнее цель, тем меньше времени Codex потратит на случайные результаты.

В простейшем варианте флаг указывается при запуске Codex CLI перед текстом запроса:

codex --search "Проверь актуальный способ настройки OAuth в официальной документации библиотеки"

Текст запроса можно передать и без кавычек, если оболочка корректно обрабатывает аргументы, но для длинных фраз кавычки безопаснее. Они сохраняют пробелы, знаки препинания и единый смысл запроса. На практике запрос лучше формулировать не как короткое ключевое слово, а как задачу с ожидаемым результатом: «найди», «сравни», «проверь», «укажи источник», «сопоставь с текущей версией».

Вариант запуска	Пример	Когда использовать
Короткий запрос	codex --search "Найди документацию по API"	Для быстрой проверки факта или ссылки
Подробная задача	codex --search "Сравни способы настройки кэширования в официальной документации Redis"	Для аналитической работы
Поиск с ограничением источников	codex --search "Используй только официальные страницы проекта"	Когда важна надёжность и происхождение данных
Поиск с привязкой к версии	codex --search "Проверь API для версии 3.2 и укажи дату источника"	При работе с быстро меняющимися библиотеками

Если Codex уже запущен в интерактивном режиме, конкретное поведение зависит от версии CLI и режима сессии. В некоторых конфигурациях флаг задаётся при запуске и действует для всей сессии. Поэтому для предсказуемого результата лучше явно запускать новую сессию с --search, особенно если предыдущая сессия была начата без доступа к веб-поиску.

Базовая форма команды

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

codex --search "Найди официальную документацию по настройке переменной окружения и кратко объясни пример"

Хороший запрос обычно содержит три элемента: объект поиска, ограничение по источникам или версии и формат результата. Например, можно попросить не просто найти информацию, а привести ссылку, назвать дату публикации и отдельно указать, какие сведения подтверждены официальной документацией.

Запуск с рабочей папкой проекта

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

cd ~/projects/shop-api
codex --search "Изучи зависимости проекта, затем проверь в интернете актуальный способ настройки используемой версии фреймворка"

Здесь поиск и анализ локального кода выполняют разные роли. Проект показывает, что используется сейчас, а интернет помогает понять, соответствует ли эта конфигурация современной документации и рекомендациям разработчиков.

Поиск с указанием нужного источника

Если вопрос связан с безопасностью, совместимостью или официальным API, полезно заранее ограничить круг источников. Это не гарантирует идеальный ответ, но уменьшает риск, что агент будет опираться на случайный блог, устаревший форум или SEO-страницу с пересказом чужой документации.

codex --search "Проверь только официальные источники проекта и ответь, как в текущей версии включить функцию миграций"

Ограничение лучше задавать естественным языком внутри запроса. Флаг --search сам по себе не означает «использовать только официальные сайты» и не заменяет редакторскую проверку результата.

Формулировка запроса	Ожидаемый результат	Риск неоднозначности
«Найди информацию о библиотеке»	Общий обзор и случайные результаты	Высокий
«Проверь официальную документацию библиотеки версии 4»	Более точная подборка материалов	Средний
«Сравни официальную документацию версии 4 с текущим кодом проекта и укажи несовместимости»	Проверка с практическим выводом	Ниже среднего

Передача многоэтапной задачи

--search особенно полезен не только для поиска одной страницы, но и для последовательного исследования. Однако задачу следует разбить на этапы: сначала найти источники, затем проверить их актуальность, после этого сопоставить сведения с кодом и только потом предложить изменения.

codex --search "Сначала найди официальную документацию по функции, затем проверь дату актуальности, сравни API с нашим кодом и предложи изменения без редактирования файлов"

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

Запуск с запросом о версии

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

codex --search "Проверь, поддерживается ли параметр в Node.js 22, и приведи ссылку на официальную документацию"

Если версия неизвестна, сначала попросите Codex определить её по проекту, а затем искать документацию именно для неё. Поиск по слову «последняя» иногда приводит к путанице: актуальная версия на момент запроса может отличаться от версии, установленной у пользователя.

Когда применять --search

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

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

Типичные случаи применения можно разделить на несколько групп:

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

Ситуация	Нужен ли --search	Почему
Прочитать локальный файл	Обычно нет	Источник уже находится в рабочей директории
Найти причину ошибки конкретной версии пакета	Часто да	Решение может находиться в свежем issue или changelog
Сгенерировать простую функцию по известному условию	Не обязательно	Поиск не добавит существенной пользы
Проверить изменившийся API	Да	Старые знания модели могут быть недостаточны
Запустить тесты	Нет, если поиск не нужен отдельно	Тестирование выполняется локальными инструментами

Полезно включать поиск при подготовке миграции. Например, проект может использовать старую версию библиотеки, а в интернете уже опубликованы руководство по обновлению, список удалённых методов и рекомендации по обратной совместимости. Без веб-поиска агент способен предложить решение, основанное на устаревшем API.

Вопросы безопасности требуют особой осторожности. Поиск может помочь найти CVE, advisory или официальный патч, но окончательное решение должно учитывать конкретную версию, способ установки и окружение проекта. Название уязвимости само по себе ещё не доказывает, что конкретное приложение ей подвержено.

Задача	Какие источники искать	Что проверить дополнительно
Уязвимость зависимости	Официальный advisory, база CVE, changelog	Версию, диапазон затронутых релизов, наличие фикса
Изменение API	Документация, migration guide, release notes	Сигнатуры методов и поведение по умолчанию
Ошибка сборки	Issue-трекер, документация, сообщения релиза	ОС, версия компилятора и способ установки
Выбор инструмента	Официальные документы, репозиторий, benchmark	Дату данных и соответствие вашим требованиям

Актуальная документация

Веб-поиск оправдан, когда нужно узнать, как функция работает сегодня, а не несколько лет назад. Это особенно важно для облачных сервисов, SDK, языковых фреймворков и инструментов, которые активно меняют интерфейсы.

codex --search "Найди актуальную официальную документацию по настройке rate limit в используемом SDK и укажи пример для текущей версии"

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

Миграция между версиями

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

codex --search "Сравни миграцию с версии 2.8 на 3.0, перечисли удалённые методы и покажи, что нужно проверить в нашем проекте"

После получения рекомендаций полезно попросить Codex составить список проверок, а не сразу переписывать весь код. Миграция — это не конкурс на максимальное количество изменённых строк.

Поиск исправления известной ошибки

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

codex --search "Найди официальное issue или исправление для ошибки 'connection reset' в версии 5.4, учитывая Linux и запуск в контейнере"

Не копируйте первое найденное решение без проверки. Issue может быть закрыта, перенесена, исправлена только в nightly-сборке или относиться к другой платформе.

Исследование безопасности

Для безопасности полезно просить Codex разделять подтверждённые факты, предположения и действия по устранению. Это делает ответ проверяемым и не позволяет смешать общую рекомендацию с доказанным риском.

codex --search "Проверь официальные сообщения о безопасности для версии пакета, отдели подтверждённые факты от предположений и предложи безопасный план обновления"

Не передавайте в поисковый запрос секреты, токены, приватные URL и содержимое закрытого исходного кода. Любой внешний поиск следует рассматривать как потенциальный канал передачи текста за пределы локальной среды.

Сравнение технологий

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

codex --search "Сравни два инструмента для фоновых задач по официальной документации: поддержка повторов, мониторинг, транзакции, лицензия и сложность развёртывания"

Сравнение не должно ограничиваться количеством звёзд на GitHub. Для практического выбора важнее совместимость с текущим стеком, зрелость нужных функций и стоимость эксплуатации.

Проверка стандартов

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

codex --search "Проверь по официальной спецификации, допустимо ли такое значение поля и какие ограничения действуют для формата даты"

В результате попросите привести точный раздел или ссылку на источник. Это позволит разработчику самостоятельно открыть первоисточник и проверить контекст.

Примеры использования --search

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

Лучший запрос для Codex — это не «поищи что-нибудь», а короткое техническое задание с контекстом, ограничениями и ожидаемым результатом.

Пример 1. Поиск официального API

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

codex --search "Найди официальную документацию по API загрузки файла, покажи минимальный пример запроса и перечисли ограничения размера"

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

Пример 2. Проверка версии зависимости

Перед обновлением пакета можно попросить Codex сопоставить установленную версию с последним стабильным релизом и сообщить о возможных изменениях.

codex --search "Определи версию зависимости в проекте, найди её официальные release notes и укажи важные изменения после этой версии"

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

Пример 3. Поиск причины ошибки сборки

Для ошибки сборки полезны точное сообщение, версия инструмента и операционная система. Чем меньше контекста, тем выше вероятность получить универсальный, но бесполезный совет вроде «переустановите пакет».

codex --search "Проанализируй эту ошибку сборки, найди похожие официальные issue и предложи исправление с учётом версии компилятора и ОС"

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

Пример 4. Поиск migration guide

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

codex --search "Найди официальный migration guide для перехода с версии 1 на 2, выдели breaking changes и составь чек-лист проверки"

После этого чек-лист можно использовать как основу отдельной задачи: проверить конфигурацию, тесты, зависимости и документацию проекта.

Пример 5. Проверка команды CLI

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

codex --search "Проверь в официальной документации синтаксис команды CLI для экспорта данных в текущей версии и объясни назначение каждого аргумента"

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

Пример 6. Поиск информации об уязвимости

Вместо общего запроса «уязвим ли пакет» лучше указать пакет, версию и желаемые источники.

codex --search "Проверь официальные security advisories для пакета и версии из проекта, укажи затронутые диапазоны и безопасную версию для обновления"

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

Пример 7. Сравнение двух API

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

codex --search "Сравни API двух сервисов для отправки сообщений: лимиты, повторные попытки, идемпотентность, webhooks и официальная поддержка"

Запрос задаёт критерии заранее, поэтому результат будет ближе к техническому анализу, а не к рекламному обзору.

Пример 8. Проверка актуального примера конфигурации

Конфигурационные файлы особенно подвержены устареванию: название поля может сохраниться в старом примере, но перестать работать в новой версии.

codex --search "Проверь актуальный формат конфигурации сервиса, сравни его с нашим файлом и перечисли неизвестные или устаревшие поля без внесения изменений"

Фраза «без внесения изменений» полезна, когда сначала требуется аудит, а не автоматическая правка.

Пример 9. Поиск решения по issue-трекеру

Issue-трекер может содержать детали, которых нет в краткой документации: условия воспроизведения, временные обходные решения и ссылку на конкретный pull request.

codex --search "Найди issue по этому симптому, проверь статус исправления и укажи, в каком релизе оно появилось. Не предлагай неподтверждённые обходы"

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

Пример 10. Исследование совместимости

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

codex --search "Проверь совместимость библиотеки с текущей версией языка, Linux и контейнерным запуском; укажи известные ограничения и подтверждающие источники"

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

Цель запроса	Что добавить в формулировку	Какой результат запросить
Найти API	Название функции и версию	Пример вызова и ограничения
Разобрать ошибку	Полный текст, ОС, версии	Источники и проверяемые шаги
Проверить безопасность	Пакет, версия, тип окружения	Advisory, диапазон риска, исправление
Сравнить технологии	Критерии выбора	Таблицу различий и вывод
Подготовить миграцию	Исходную и целевую версии	Breaking changes и чек-лист

Чем --search отличается от похожих команд и возможностей

Пользователи часто смешивают веб-поиск, поиск по файлам, просмотр страницы и обычные команды оболочки. Различия важны: одинаковое слово «найти» может обозначать совершенно разные операции и источники данных.

Веб-поиск отвечает на вопрос «что есть во внешнем интернете», а поиск по проекту — на вопрос «что уже находится у меня на диске».

Ниже рассмотрены четыре близких сценария. Названия и доступность отдельных инструментов могут зависеть от версии Codex CLI и конфигурации среды, поэтому воспринимайте их как функциональное сравнение, а не как обещание одинакового синтаксиса во всех релизах.

--search и локальный поиск по файлам

--search предназначен для веб-источников. Для поиска слова в исходном коде применяются локальные инструменты вроде grep, rg или встроенные возможности редактора.

rg "deprecatedMethod" src/

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

Характеристика	--search	rg или grep
Источник	Внешний веб	Локальные файлы
Зависимость от сети	Обычно есть	Нет
Поиск по символам проекта	Не является основной задачей	Да
Актуальная документация	Да, при доступных источниках	Только если она сохранена локально
Контроль приватности	Нужно учитывать передачу запроса	Выше при локальном использовании

--search и просмотр конкретной веб-страницы

Поиск помогает обнаружить релевантные страницы, а просмотр конкретного URL нужен для внимательного чтения уже известного источника. Если у пользователя есть точная ссылка на документацию, полезно передать её в запрос и попросить анализировать именно её.

codex --search "Изучи указанную официальную страницу документации, выпиши обязательные параметры и сравни их с текущей конфигурацией проекта: https://example.org/docs"

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

--search и обычная команда curl

curl загружает указанный HTTP-ресурс и полезен для воспроизводимой проверки ответа сервера, заголовков или содержимого API. Это не то же самое, что интеллектуальный веб-поиск по нескольким источникам.

curl -I https://example.org/health

Используйте curl, когда URL, метод и параметры уже известны. Используйте --search, когда ещё нужно выяснить, где находится нужная информация, какие источники актуальны и как сопоставить их содержание с задачей.

--search и поиск по документации через браузер

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

codex --search "Проведи предварительное исследование темы, составь список источников и отметь, какие утверждения нужно проверить вручную"

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

Инструмент	Сильная сторона	Ограничение
--search	Поиск и связывание внешних сведений с задачей	Нужно проверять источники и актуальность
rg	Быстрый точный поиск в проекте	Не знает внешнюю документацию
curl	Воспроизводимое обращение к конкретному URL	Не выбирает источники и не объясняет их смысл
Браузер	Глубокая ручная проверка страниц	Требует больше времени на сбор и систематизацию

Типичные ошибки при использовании --search

Большинство проблем возникает не потому, что флаг «не работает», а потому что от него ожидают слишком многого. Ниже перечислены распространённые ошибки и способы сделать запрос надёжнее.

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

Ошибка 1. Ожидание поиска по локальному проекту

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

codex --search "Найди все места, где в моём проекте вызывается legacyMethod"

Для такой задачи сначала нужен локальный поиск:

rg "legacyMethod" .

А затем можно использовать веб-поиск для внешнего контекста:

codex --search "Проверь официальную документацию и release notes, когда legacyMethod был объявлен устаревшим и чем его заменить"

Ошибка 2. Слишком общий запрос

Фраза «расскажи про Docker» не определяет ни цель, ни версию, ни уровень подробности. Агент может выдать широкий обзор, который не поможет решить конкретную проблему.

codex --search "Расскажи про Docker"

Гораздо полезнее задать контекст и ожидаемый результат:

codex --search "Проверь официальную документацию Docker Compose для текущей версии и объясни, как задать healthcheck для веб-сервиса с зависимостью от базы данных"

Ошибка 3. Отсутствие версии

Если не указать версию, Codex может найти сведения для последнего релиза, тогда как проект работает со старым. Иногда это незаметно приводит к совету использовать параметр, которого в установленной версии ещё нет или уже нет.

codex --search "Как настроить маршрутизацию в фреймворке?"

Добавьте версию и попросите сопоставить её с проектом:

codex --search "Определи версию фреймворка в проекте и найди официальную документацию именно для неё; отдельно укажи отличия от последнего релиза"

Ошибка 4. Доверие первому найденному источнику

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

codex --search "Найди любое решение проблемы с авторизацией и сразу внеси его в проект"

Безопаснее разделить исследование и изменение:

codex --search "Найди минимум два источника по проблеме авторизации, приоритет отдавай официальной документации, сравни решения и сначала подготовь план без изменения файлов"

Ошибка 5. Передача секретов в поисковый запрос

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

codex --search "Почему токен sk-live-EXAMPLE не работает с нашим приватным endpoint?"

Замените чувствительные значения нейтральными обозначениями:

codex --search "Почему API-токен не проходит проверку на приватном endpoint? Ищи общие причины и не используй реальные секреты"

Если нужно анализировать внутреннюю инфраструктуру, сначала удалите идентификаторы, домены, ключи и данные пользователей.

Ошибка	Последствие	Как исправить
Поиск по локальному коду через --search	Нерелевантный внешний результат	Использовать rg, grep или инструменты проекта
Общий вопрос без цели	Поверхностный обзор	Указать задачу и формат ответа
Не указана версия	Совет для другого API	Назвать версию или попросить определить её
Доверие одному источнику	Устаревшее или ошибочное решение	Сравнить источники и открыть первоисточник
Секреты в запросе	Риск раскрытия данных	Заменить секреты и обезличить контекст

Как оценивать результаты поиска

Даже при правильно сформулированном запросе ответ Codex следует проверять. У веб-источников различаются дата обновления, авторитетность, полнота и соответствие конкретной версии продукта.

Начните с источника. Официальная документация, release notes и security advisory обычно имеют больший вес, чем пересказ в блоге. Но даже официальный сайт может содержать несколько веток документации, поэтому смотрите на версию, URL и дату публикации.

Признак	Хороший сигнал	Повод для проверки
Источник	Официальный сайт, репозиторий, advisory	Анонимный пересказ или сайт без даты
Версия	Явно указана и совпадает с проектом	Используются слова «последняя версия» без номера
Дата	Есть свежая дата обновления	Материал опубликован давно
Доказательства	Приведены ссылки, примеры, issue или спецификация	Только уверенные утверждения без подтверждений
Применимость	Совпадают ОС, режим запуска и зависимости	Пример относится к другой платформе

Попросите Codex разделять факты и выводы. Например: «что прямо сказано в источнике», «какой вывод можно сделать для нашего проекта» и «что ещё нужно проверить». Такое разделение особенно полезно в вопросах безопасности и совместимости, где небольшая разница в условиях меняет итог.

codex --search "Для каждого вывода укажи источник, отдели подтверждённые факты от предположений и перечисли проверки, которые нужно выполнить локально"

Наконец, проверяйте результат экспериментом: запустите тест, сверяйте команду с документацией, проверьте версию пакета и воспроизведите минимальный пример. Веб-поиск даёт гипотезу и контекст, а не автоматическую гарантию исправности.

Ограничения и вопросы безопасности

У веб-поиска есть технические и организационные ограничения. Страница может быть недоступна, закрыта от автоматического просмотра, требовать авторизации или содержать динамический контент. В таких случаях Codex не обязательно сможет получить ту же информацию, которую пользователь видит в браузере.

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

Ограничение	Как проявляется	Практический шаг
Недоступная страница	Источник не открывается или требует входа	Найти публичный первоисточник или проверить вручную
Устаревшая документация	Пример не работает в текущей версии	Сверить ветку документации и release notes
Противоречивые данные	Источники предлагают разные решения	Отдать приоритет спецификации и официальному issue
Ограничение сети	Поиск не выполняется из окружения	Проверить настройки сети и использовать локальные материалы
Чувствительные данные	В запросе есть внутренние сведения	Обезличить запрос до отправки

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

codex --search "Найди команду для очистки всех ресурсов окружения и выполни её без дополнительного подтверждения"

Более безопасная формулировка просит объяснение и сухой план:

codex --search "Найди официальную процедуру очистки тестового окружения, объясни последствия каждой команды и подготовь план без выполнения опасных действий"

Краткая памятка

Флаг Codex CLI --search включают, когда агенту нужно обратиться к внешней актуальной информации. Он особенно полезен для документации, миграций, issue-трекеров, security advisory, спецификаций и проверки совместимости.

• Запускайте поиск так: codex --search "ваша задача".
• Указывайте версию библиотеки, платформу и окружение.
• Просите ссылки и отдавайте приоритет официальным источникам.
• Не путайте веб-поиск с поиском по локальным файлам.
• Для поиска в проекте используйте rg, grep или встроенные инструменты.
• Не передавайте в запросах токены, пароли и закрытые данные.
• Не доверяйте первому результату без проверки даты и применимости.
• Разделяйте исследование, планирование и внесение изменений.
• Опасные команды сначала просите объяснить, а не выполнять.
• Проверяйте важные выводы вручную и подтверждайте их локальными тестами.

Вопрос перед запуском	Если ответ «да»	Действие
Информация могла измениться?	Да	Добавьте --search
Нужно найти строку в проекте?	Да	Используйте локальный поиск
Известна конкретная версия?	Да	Укажите её в запросе
Нужна высокая надёжность?	Да	Попросите официальные источники и ссылки
Запрос содержит секреты?	Да	Обезличьте данные до запуска

В итоге --search — это инструмент расширения контекста, а не кнопка «сделать ответ истинным». Он помогает Codex работать с меняющимся миром, но лучший результат получается тогда, когда пользователь задаёт точный вопрос, ограничивает область поиска и проверяет найденные сведения перед применением.