OpenAI усиливает защиту Codex, предотвращая разрушительные действия с помощью более безопасной очистки и контроля разрешений

OpenAI усиливает защиту Codex: добавлены механизмы очистки и контроля разрешений для предотвращения разрушительных операций

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

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

По словам Тибо «Тибо» Соттио, руководителя инженерного направления Codex в OpenAI, компания расследовала небольшое количество случаев, когда GPT-5.6 выполнял в Codex разрушительные операции, выходящие за рамки запрошенного. Один из повторяющихся сценариев был связан с очисткой временных каталогов, особенно при запуске сессий с широкими правами доступа и ослабленной песочницей.

Последние меры OpenAI действуют сразу на нескольких уровнях:

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

Ключевое изменение — не единый список запретов. OpenAI одновременно ужесточает и инструкции модели, и окружающую среду выполнения.

Расследование сосредоточено на очистке временных каталогов

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

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

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

Соттио описал один из сценариев отказа: модель повторно использует системную переменную окружения (например, $HOME) как временный рабочий каталог. Если последующая команда очистки неверно интерпретирует эту переменную, команда, предназначенная для удаления временного каталога, может указать на реальный домашний каталог пользователя.

Эту цепочку сбоя можно представить на высоком уровне следующим образом:

Создание или определение временной рабочей области
        ↓
Повторное использование широкой системной переменной
        ↓
Формирование команды очистки
        ↓
Интерпретация ошибочного целевого пути
        ↓
Выполнение разрушительной операции с широкими правами
        ↓
Удаление файлов за пределами ожидаемой области

В сессиях без ограничений этот риск особенно высок.

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

Текущая документация Codex от OpenAI четко указывает на это различие: обычный режим workspace-write ограничивает повседневное редактирование текущей рабочей областью,

а режим danger-full-access снимает ограничения файловой системы и сетевой песочницы.

Codex теперь более явно проверяет разрушительные цели

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

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

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

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

Новый подход снижает зависимость от неявных допущений.

Перед выполнением высокорисковой операции с файловой системой система должна более тщательно продумать следующие вопросы:

• На какой именно каталог повлияет эта команда?
• Является ли этот каталог временным местоположением, созданным для данной задачи?
• Указывает ли путь в пределах ожидаемой рабочей области?
• Не является ли цель случайно слишком широкой?
• Обратимо ли удаление?
• Достаточно ли четко определена область действия, чтобы продолжить без запроса пользователю?

Это улучшение безопасности на уровне поведения агента.

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

Выделенные временные каталоги вместо рискованного повторного использования переменных

OpenAI также меняет подход Codex к временной работе.

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

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

Использование выделенного временного пути дает два преимущества.

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

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

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

Более безопасный шаблон выглядит так:

Создание нового временного каталога
        ↓
Хранение временных файлов задачи там
        ↓
Отслеживание точного пути
        ↓
Проверка того же пути перед очисткой
        ↓
Удаление только проверенного временного каталога

Цель — не допустить, чтобы широкое состояние окружения становилось целью очистки.

Обнаружение и проверка опасных команд усиливаются

Проверка пути — лишь один уровень защиты.

OpenAI также усиливает механизмы выявления рискованных команд и передачи их на проверку.

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

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

Команда удаления может полностью соответствовать правилам синтаксиса shell, но оставаться опасной, поскольку она может:

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

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

Они также оценивают, должна ли эта команда быть выполнена должна ли она выполняться при текущих разрешениях и авторизации пользователя.

Полный доступ становится сложнее включить случайно

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

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

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

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

OpenAI теперь устанавливает более высокий порог для включения этого режима.

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

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

Описание основных режимов разрешений

Ключевой момент: автоматическая проверка и полный доступ — это не одно и то же.

Автоматическая проверка сохраняет механизм песочницы. Она меняет лишь то, кто оценивает запросы на пересечение границ песочницы.

Полный доступ напрямую снимает сами границы песочницы.

Автоматическая проверка теперь строже выявляет разрушительные операции

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

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

Нормальный процесс выглядит следующим образом:

Основной агент Codex работает внутри песочницы
        ↓
Для некоторой операции требуются дополнительные права
        ↓
Codex создаёт запрос на одобрение
        ↓
Автоматическая проверка оценивает этот запрос
        ↓
Одобрено → продолжение выполнения
Отклонено → Codex должен найти более безопасный путь или спросить пользователя

Документация OpenAI показывает, что автоматическая проверка может оценивать запросы, связанные с:

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

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

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

Однако OpenAI прямо заявляет, что автоматическая проверка не заменяет механизм песочницы.

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

OpenAI воспроизводит сбои в новых оценках

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

Сотио заявил, что OpenAI создала целевые оценки, воспроизводящие различные типы сбоев, обнаруженных в ходе расследования. Компания также добавляет задачи обучения с подкреплением и скоринговые модели, направленные на эти риски.

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

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

• Распознаёт ли модель случайно слишком большую цель удаления?
• Избегает ли она повторного использования чувствительных переменных окружения?
• Останавливается ли она, когда область действия неясна?
• Предпочитает ли она обратимые операции, когда это возможно?
• Правильно ли автоматическая проверка повышает уровень запроса или отклоняет его?
• Повторят ли будущие модели тот же сбой?

Другими словами, этот инцидент преобразуется в покрытие регрессионными тестами.

Цель безопасности — не просто исправить один шаблон команды, а сделать так, чтобы будущие версии Codex с меньшей вероятностью воспроизводили более широкий класс сбоев.

Песочница и разрешения по-прежнему важнее простых подсказок

Расследование также подтвердило более широкую точку зрения о безопасности агентов кодирования.

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

Исполняемая песочница — является.

Собственные рекомендации OpenAI по развёртыванию описывают песочницу и одобрения как взаимодополняющие меры контроля:

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

Для большинства локальных работ OpenAI в настоящее время рекомендует конфигурацию в масштабе рабочей области, а не неограниченное выполнение.

Репрезентативная более безопасная конфигурация:

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

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

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

Эти конфигурации сохраняют границы на уровне операционной системы вокруг обычной рабочей области.

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

Что это обновление безопасности Codex означает для разработчиков

Для разработчиков это обновление не означает, что Codex никогда не совершит деструктивных ошибок.

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

Реальное изменение — это защита в глубину.

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

1. Модели предписано проверять цели.
2. Для временной работы ожидается использование более безопасных специализированных путей.
3. Высокорисковые шаблоны команд могут распознаваться исполняющей средой.
4. Границы песочницы могут блокировать доступ за пределы рабочей области.
5. Одобрение или автоматическая проверка могут оценивать запросы на пересечение границ.
6. Полный доступ требует более явных и осознанных действий пользователя.
7. Случаи сбоев добавляются в оценки и будущее обучение.

Это более надёжно, чем полагаться на любую отдельную меру безопасности.

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

Часто задаваемые вопросы

Почему Codex иногда удаляет файлы за пределами целевой директории?

Расследование OpenAI выявило сбой, связанный с очисткой временных директорий. В некоторых случаях широкие системные переменные, такие как $HOME, могли повторно использоваться во временной работе, а некорректно отформатированные пути очистки могли указывать на реальные пользовательские данные, а не на одноразовую директорию.

Что изменилось в Codex после расследования?

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

Что такое полный доступ Codex?

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

Автоматическая проверка — это то же самое, что полный доступ?

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

Может ли автоматическая проверка остановить деструктивные команды?

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

Какой режим разрешений следует выбрать большинству пользователей Codex?

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

Может ли Codex по-прежнему ошибаться после этих изменений?

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

Где я могу проверить настройки разрешений и песочницы Codex?

В настольном приложении ChatGPT или расширении IDE используйте элементы управления разрешениями, связанные с задачей. В Codex CLI команда /permissions показывает доступные режимы, а официальная документация по конфигурации описывает sandbox_mode, approval_policy и approvals_reviewer.

Связанные инструменты

• OpenAI Codex: официальная документация Codex для локальных, IDE, настольных и облачных рабочих процессов.
• Codex CLI: открытый исходный код командного агента кодирования OpenAI и история его релизов.
• Разрешения Codex: официальные объяснения режимов «запрос одобрения», «автоматическая проверка», «полный доступ» и связанных с ними режимов разрешений.
• Автоматическая проверка Codex: документация об автоматической проверке запросов на одобрение пересечения границ песочницы.
• Песочница Codex: документация о

read-only、workspace-write и danger-full-access — официальные справочные материалы.

• Правила Codex: управление политиками команд для разрешения, подсказки или блокировки выбранных шаблонов команд.

Связанные ссылки

• Обновление безопасности Codex от Тибо Соттьо: инженерное обновление OpenAI Codex с описанием хода расследования и новых выпущенных мер смягчения.
• Безопасный запуск Codex в OpenAI: обзор от OpenAI по песочнице, утверждению, контролю сети, конфигурации хостинга и аудируемости.
• Утверждение и безопасность агента: подробное руководство по границам песочницы, политикам утверждения, защищённым путям и автоматизированному рассмотрению утверждений.
• Автоматический обзор Codex: официальная документация, охватывающая условия срабатывания, процесс обзора, политики деструктивных операций и поведение при сбоях.
• Разрешения Codex: официальное описание пользовательских режимов разрешений и предупреждений о полном доступе.
• Журнал изменений Codex: история выпусков, фиксирующая более строгое принудительное обнаружение rm, подтверждение полного доступа и связанные улучшения безопасности.
• Репозиторий OpenAI Codex на GitHub: исходный код, вопросы, примечания к выпускам и реализация открытого исходного кода Codex CLI.

Резюме

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

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

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

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