Сетевой доступ Codex: как открыть интернет под задачу и не потерять границы

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

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

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

Почему интернет не должен быть молчаливым режимом

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

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

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

Что документация Codex говорит о сетевом доступе

В официальной документации OpenAI Codex сетевой доступ описан рядом с sandbox и approvals. Это важно: интернет не рассматривается отдельно от разрешений.

У Codex есть два разных слоя управления. Sandbox mode определяет, что агент технически может делать: где писать файлы, может ли выполнять команды, может ли выходить в сеть. Approval policy определяет, когда агент должен остановиться и спросить разрешение.

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

Есть ещё важная логика allowlist. Можно разрешать конкретные домены, а запрет имеет приоритет над разрешением. Локальные и приватные адреса по умолчанию требуют отдельного внимания: это не просто «ещё один сайт», а возможный доступ к внутренним сервисам.

Отдельно документация предупреждает про web search и внешние страницы: найденный текст может быть недоверенным. Значит, внешний источник должен быть источником фактов, а не новым начальником для агента.

Когда доступ действительно нужен

Сетевой доступ нужен не всегда. Большую часть работы Codex может сделать по локальному репозиторию, README, тестам, ошибкам сборки и уже сохранённым артефактам.

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

Интернет не нужен, если вопрос можно решить локально: прочитать код, найти файл, прогнать тест, собрать проект, сравнить diff, оформить инструкцию по уже имеющимся материалам.

Есть простой фильтр. Перед доступом спросите: «Что Codex должен получить извне, чего нет в проекте?» Если ответ расплывчатый, доступ рано включать. Сначала нужно сузить задачу.

Что дать Codex на вход

Хорошая задача с сетевым доступом начинается с пяти пунктов.

Первое — цель. Например: «проверь актуальный синтаксис настройки», «открой страницу релиза», «получи ответ от test endpoint», «скачай зависимости для сборки».

Второе — разрешённые направления. Лучше назвать конкретные домены или URL. Не «поищи где-нибудь», а «используй официальную документацию OpenAI», «используй npm registry», «обратись к этому staging API».

Третье — запреты. Например: не ходить в сторонние блоги, не открывать локальные приватные адреса, не отправлять секреты, не использовать результаты из рекламных страниц, не расширять список доменов без вопроса.

Четвёртое — формат отчёта. Codex должен после сетевого шага сказать, куда он ходил, зачем, что получил и как это повлияло на решение.

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

Как должен выглядеть результат

Хороший результат после сетевого шага — это не просто «нашёл» или «скачал».

Он должен быть проверяемым:

Такой отчёт нужен не ради бюрократии. Он превращает сетевой доступ из невидимого фона в понятный рабочий шаг.

Как проверить границы без кода

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

Первое: понятно ли, зачем Codex просит интернет? Если он не может объяснить цель одним предложением, доступ лучше не давать.

Второе: назван ли список направлений? «Официальная документация OpenAI» звучит лучше, чем «интернет». «api.example.com» лучше, чем «внешний сервис».

Третье: есть ли запреты? Особенно на локальные и приватные адреса, секреты, cookie, токены, внутренние панели и случайные сайты.

Четвёртое: после шага есть ли отчёт? Если Codex использовал сеть, он должен сказать, что именно использовал.

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

Где остаётся человеческое решение

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

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

Самый здоровый режим — не запрещать интернет навсегда и не включать его всегда. Здоровый режим — давать доступ под конкретную задачу, с понятной целью, узким списком направлений и коротким отчётом.

Шаблон запроса

Можно писать Codex так:

Для этой задачи может понадобиться сетевой доступ.

Цель:
[что нужно проверить, скачать или открыть]

Разрешённые направления:
[домены, URL или официальный источник]

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

Перед сетевым шагом:
1. объясни, зачем нужен доступ;
2. перечисли, куда именно собираешься обратиться;
3. скажи, можно ли решить задачу офлайн.

После сетевого шага:
1. перечисли фактические обращения;
2. выдели полученные факты;
3. объясни, как они повлияли на результат;
4. если нужен новый доступ, остановись и спроси.

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