Команда codex sandbox («песочница») в Codex CLI служит для запуска отдельных команд внутри изолированной среды с ограниченными правами, чтобы проверить их поведение и снизить риск воздействия на операционную систему, файлы пользователя и сеть. Это полезно, когда нужно выполнить сборку, тест, просмотр файлов или другую операцию, но не хочется запускать процесс с теми же возможностями, что есть у обычного терминала.
Песочница не делает команду «хорошей» или безопасной сама по себе: она ограничивает последствия её работы, но не отменяет необходимость проверять саму команду, аргументы и результаты выполнения.
В Codex CLI песочница особенно важна потому, что CLI может работать с проектом, запускать инструменты разработки и обращаться к локальным ресурсам. Ограниченный запуск помогает отделить такие действия от обычной работы оболочки. Ниже разберём синтаксис codex sandbox, поддерживаемые платформенные варианты, связь с правами доступа и реальные сценарии использования.
- Обзор команды codex sandbox
- Синтаксис команды codex sandbox
- Аргумент <platform>
- Аргумент --
- Аргумент <command>
- Аргументы запускаемой команды
- Параметр -c и конфигурационные переопределения
- Как работает песочница Codex
- Для чего ограничивается выполнение команд
- Связь песочницы с правами доступа
- Платформенные варианты
- Вариант macos
- Вариант linux
- Windows и WSL
- Практические примеры
- Пример 1. Просмотр текущего каталога
- Пример 2. Просмотр файлов проекта
- Пример 3. Проверка версии инструмента
- Пример 4. Запуск Python-скрипта без сетевого доступа по замыслу программы
- Пример 5. Запуск тестов
- Пример 6. Запуск npm-тестов
- Пример 7. Проверка Git без изменения файлов
- Пример 8. Проверка доступности сетевого запроса
- Пример 9. Сборка проекта
- Пример 10. Запуск shell-скрипта
- Пример 11. Проверка записи во временный файл
- Пример 12. Просмотр переменной окружения
- Ограничения и типичные причины ошибок
- Чем codex sandbox отличается от обычного запуска
- Рекомендации по безопасной работе
- Итоги
Обзор команды codex sandbox
Команда codex sandbox предназначена не для настройки постоянной виртуальной машины и не для управления контейнерами. Она запускает указанную команду через один из поддерживаемых механизмов песочницы Codex CLI. Иными словами, это оболочка над запуском процесса: Codex CLI подготавливает ограничения, передаёт им команду и возвращает её вывод и код завершения.
Важная особенность
codex sandboxзапускает конкретную команду, а не открывает универсальную «защищённую консоль». Если нужно выполнить несколько действий, их следует явно объединить в команду оболочки или скрипт.
Команда полезна в ситуациях, где нужно быстро проверить операцию с меньшим уровнем доверия: например, запустить тестовый скрипт из репозитория, выполнить компилятор, посмотреть, какие файлы доступны процессу, или убедиться, что программа не может произвольно обратиться к внешней сети.
| Задача | Подходит ли codex sandbox |
Почему |
|---|---|---|
| Запустить одну команду с ограничениями | Да | Это основной сценарий команды. |
| Проверить сборку проекта | Да | Сборщик можно запустить внутри ограниченной среды. |
| Постоянно хранить отдельную виртуальную машину | Нет | Песочница не является полноценной виртуальной машиной. |
| Настроить сетевой прокси | Нет | У команды нет отдельного интерфейса управления прокси. |
| Изменить права доступа произвольными флагами | Нет | Нельзя считать codex sandbox универсальным менеджером разрешений. |
| Запустить интерактивную команду | Ограниченно | Возможность зависит от самой команды и терминала; песочница не гарантирует полноценную интерактивность. |
Смысл команды лучше всего виден в сравнении с обычным запуском. При прямом выполнении операционная система предоставляет процессу права текущего пользователя, если другие ограничения не наложены отдельно. При запуске через песочницу Codex CLI добавляет платформенные ограничения, поэтому команда может видеть не всё, что доступно пользователю, и не обязательно может выполнить все системные операции.
| Характеристика | Обычный запуск | Запуск через codex sandbox |
|---|---|---|
| Права пользователя | Обычно используются права текущего пользователя | Дополняются ограничениями песочницы |
| Файловая система | Доступ определяется правами ОС и самой команды | Часть путей может быть недоступна или доступна только для чтения |
| Сеть | Обычно доступна согласно настройкам ОС и сети | Может быть ограничена политикой песочницы |
| Системные вызовы | Разрешаются обычными механизмами ОС | Некоторые вызовы блокируются платформенным механизмом |
| Изоляция | Специальной изоляции нет | Процесс запускается в ограниченном контексте |
| Совместимость | Максимальная для текущей системы | Некоторые инструменты и операции могут не работать |
Синтаксис команды codex sandbox
Синтаксис состоит из названия команды, платформенного варианта и команды, которую нужно выполнить. Разделитель -- помогает отделить аргументы самого Codex CLI от аргументов запускаемой программы. Это особенно важно, если внутренняя команда использует параметры, похожие на параметры Codex.
codex sandbox <platform> -- <command> [arguments...]
На поддерживаемых системах используются платформенные варианты macos и linux. Они не являются декоративными словами: каждый вариант включает механизм изоляции, соответствующий данной операционной системе.
Аргумент <platform>
Аргумент <platform> указывает, какой платформенный адаптер песочницы следует использовать. В актуальном интерфейсе для прямого запуска через codex sandbox применяются варианты macos и linux.
| Значение | Для какой среды | Механизм | Практический смысл |
|---|---|---|---|
macos |
macOS | Системная модель ограничений macOS, основанная на Seatbelt | Ограничивает доступ процесса к ресурсам через профиль песочницы |
linux |
Linux | Комбинация механизмов Linux, включая Landlock и seccomp, когда они доступны | Ограничивает файловый и системный доступ на уровне ядра |
Платформенный аргумент не следует подменять названием операционной системы в произвольной форме. Например, darwin, ubuntu или windows не являются равнозначными заменами в синтаксисе этой команды. На Windows типичный путь использования Codex CLI связан с Linux-средой, например WSL, где используется Linux-вариант, если он поддержан конкретной конфигурацией.
Аргумент --
Разделитель -- показывает, что следующие элементы относятся уже к запускаемой программе, а не к команде codex sandbox. Его стоит использовать почти всегда: так команда становится однозначной и не зависит от того, как CLI интерпретирует параметры внутреннего процесса.
codex sandbox macos -- ls -la
В этом примере macos относится к Codex CLI, а ls -la — к программе, которую нужно выполнить в песочнице.
| Часть строки | Кому принадлежит | Назначение |
|---|---|---|
codex |
Операционной системе | Запуск исполняемого файла Codex CLI |
sandbox |
Codex CLI | Выбор режима песочницы |
macos или linux |
Codex CLI | Выбор платформенного механизма |
-- |
Интерфейсу командной строки | Разделение аргументов Codex и дочерней команды |
ls -la |
Запускаемой программе | Команда и её собственные параметры |
Аргумент <command>
Аргумент <command> — это программа, которую нужно запустить в песочнице. Это может быть системная команда, интерпретатор, компилятор, тестовый раннер или скрипт. Codex CLI не превращает произвольный текст в команду автоматически: программа должна существовать в среде и быть доступной через PATH либо указываться корректным путём.
codex sandbox linux -- python3 --version
Здесь песочница запускает программу python3, а параметр --version передаётся самой программе Python.
Аргументы запускаемой команды
После имени программы можно передать любое количество аргументов, которые поддерживает сама программа. Их смысл определяется не Codex CLI, а этой программой. Например, pytest -q означает тихий режим pytest, а npm test — запуск сценария test из проекта.
| Команда | Что выполняется | Кому передаются параметры |
|---|---|---|
ls -la |
Просмотр файлов | -la получает ls |
python3 script.py |
Запуск Python-файла | script.py получает Python |
npm test |
Запуск npm-сценария | test получает npm |
git status --short |
Проверка состояния Git | status и --short получает Git |
Параметр -c и конфигурационные переопределения
В Codex CLI может использоваться общий параметр конфигурации -c, также записываемый как --config. Он задаёт конфигурационные переопределения CLI в формате key=value, если такая настройка поддерживается установленной версией Codex CLI. Это не специальный параметр песочницы и не механизм выдачи процессу произвольных прав.
codex sandbox macos -c model="gpt-5" -- pwd
При практическом использовании следует сверяться с локальной справкой: набор конфигурационных ключей меняется быстрее, чем основной синтаксис запуска команд.
| Запись | Роль | Что важно помнить |
|---|---|---|
-c key=value |
Переопределение настройки CLI | Не является разрешением на запись, сеть или системный доступ |
--config key=value |
Полная форма того же параметра | Поддержка конкретного ключа зависит от версии |
-- |
Разделитель | Не является конфигурацией |
Чтобы увидеть справку именно установленной версии, используйте:
codex sandbox --help
Для справки по конкретному платформенному варианту:
codex sandbox macos --help codex sandbox linux --help
Это предпочтительнее случайного копирования параметров из старых публикаций: интерфейс CLI развивается, а операционная система может не поддерживать часть механизмов, доступных в другой среде.
Как работает песочница Codex
Песочница создаёт для дочернего процесса ограниченный контекст выполнения. Процесс получает обычные аргументы и окружение настолько, насколько это допускает механизм платформы, но его действия дополнительно фильтруются. Ограничения могут касаться файловой системы, сети, системных вызовов, устройств и других ресурсов.
Главная идея песочницы — не спрятать процесс от компьютера полностью, а уменьшить набор последствий, которые процесс способен вызвать.
На macOS Codex CLI использует системный механизм Seatbelt. Он применяет профиль, описывающий разрешённые и запрещённые операции. На Linux используются возможности ядра, в том числе Landlock для ограничений файловой системы и seccomp для фильтрации системных вызовов, когда среда и версия ядра позволяют это сделать.
Это не означает, что две платформы ведут себя совершенно одинаково. Одна и та же команда может успешно работать на macOS, но завершаться ошибкой на Linux, если ей требуется системный вызов или путь, который там закрыт. И наоборот, особенности прав, файловой системы и установки инструментов могут привести к различиям в обратную сторону.
| Уровень | Что ограничивается | Как это выглядит для пользователя |
|---|---|---|
| Файлы | Чтение и запись отдельных путей | Ошибка доступа или отсутствие файла |
| Сеть | Создание сетевых соединений | Сбой запроса, невозможность подключиться |
| Системные вызовы | Потенциально опасные операции ядра | Ошибка выполнения или завершение процесса |
| Процессы | Некоторые операции управления другими процессами | Ограниченная работа дочерних инструментов |
| Устройства | Доступ к специальным системным ресурсам | Команда не видит устройство или не может его открыть |
Песочница не обязательно создаёт копию проекта. Поэтому нельзя автоматически считать, что все изменения «исчезнут» после завершения команды. Если процесс получил разрешённый доступ к рабочей директории и записал туда файл, результат может остаться. Изоляция определяет, куда процесс может обратиться, но не обещает откат изменений.
codex sandbox macos -- sh -c 'printf "temporaryn" > sandbox-check.txt; cat sandbox-check.txt'
Этот пример показывает важный принцип: разрешённая запись может быть настоящей записью в доступный каталог. После эксперимента файл необходимо удалить вручную, если он больше не нужен.
Для чего ограничивается выполнение команд
Ограничения нужны прежде всего для снижения риска. Любая команда может содержать ошибку, вызвать неожиданную зависимость, выполнить скрипт из проекта или обратиться к внешнему ресурсу. Если запускать её с обычными правами пользователя, последствия могут оказаться шире, чем предполагалось.
Безопасность здесь строится по принципу минимально необходимого доступа: процессу дают достаточно возможностей для задачи, но не обещают ему полный контроль над системой.
Особенно полезна песочница при работе с незнакомыми репозиториями. Файл вроде package.json, Makefile, pyproject.toml или скрипт сборки может запускать дополнительные команды. Ограниченный режим не делает такой код безопасным, но уменьшает вероятность того, что случайный скрипт получит полный доступ к домашнему каталогу или сети.
- проверка тестов и линтеров;
- сборка проекта из непроверенного репозитория;
- анализ поведения локального скрипта;
- просмотр доступных файлов и переменных окружения;
- проверка того, требуется ли программе сеть;
- безопасный пробный запуск инструмента перед обычным выполнением.
| Риск | Что может произойти при обычном запуске | Как помогает песочница |
|---|---|---|
| Ошибочная запись | Перезапись доступных файлов | Сужает область доступной записи |
| Нежелательный сетевой запрос | Отправка данных или загрузка содержимого | Может блокировать сетевые соединения |
| Опасный системный вызов | Изменение системных ресурсов | Фильтрует часть вызовов средствами ОС |
| Скрипт из зависимости | Запуск неизвестного кода | Уменьшает доступ этого кода к ресурсам |
| Неверный путь | Работа не в том каталоге | Не исправляет путь автоматически, но может ограничить видимые ресурсы |
При этом песочница не заменяет резервное копирование, контроль версий и проверку команд. Если команда имеет доступ к рабочему каталогу и вы запускаете её с правами пользователя, она всё ещё может повредить файлы в разрешённой области. Для потенциально разрушительных операций безопаснее сначала работать с копией проекта.
codex sandbox linux -- git status --short
Проверка состояния Git — хороший безопасный первый шаг перед более сложной операцией. Она помогает понять, есть ли незакоммиченные изменения, которые можно случайно затронуть.
Связь песочницы с правами доступа
Песочница и права доступа — связанные, но разные уровни защиты. Права доступа операционной системы определяют, что разрешено пользователю и процессу в принципе. Песочница добавляет дополнительные запреты поверх этих прав. Если пользователь не может прочитать файл без песочницы, песочница не должна превращать его в доступный. Если пользователь может прочитать файл, песочница всё равно может запретить чтение.
Полезно представить это как два фильтра. Первый — учётная запись пользователя и разрешения файловой системы. Второй — профиль песочницы. Итоговое право — это пересечение обоих наборов разрешений, а не сумма возможностей.
Песочница может отнять доступ, но не должна рассматриваться как способ получить привилегии. Она не предназначена для обхода разрешений пользователя или запуска команд от имени администратора.
| Ситуация | Права пользователя | Песочница | Итог |
|---|---|---|---|
| Файл доступен пользователю и разрешён профилем | Есть | Разрешён | Доступ возможен |
| Файл доступен пользователю, но закрыт профилем | Есть | Запрещён | Доступ блокируется |
| Файл недоступен пользователю, но не упомянут в профиле | Нет | Не запрещён явно | Права пользователя всё равно не позволяют доступ |
| Команда требует административных прав | Нет | Не даёт их | Команда завершается ошибкой |
| Файл разрешён для чтения, но не для записи | Чтение есть | Запись может быть ограничена | Чтение возможно, запись — нет |
Например, запуск команды через sudo и запуск в песочнице — это не взаимозаменяемые действия. Повышение привилегий увеличивает возможности процесса, а песочница, напротив, пытается их ограничить. Комбинация вроде запуска административной команды внутри песочницы требует особой осторожности и не превращает операцию в безопасную по умолчанию.
codex sandbox linux -- id
Команда id позволяет увидеть идентификатор пользователя, от имени которого работает процесс. Песочница не должна восприниматься как отдельный пользователь: изоляция и учётная запись — разные понятия.
Платформенные варианты
Поддержка песочницы зависит от операционной системы, версии ядра и возможностей, доступных Codex CLI. На macOS и Linux используются разные системные технологии, поэтому результаты и ограничения могут немного различаться. Команда должна запускаться с соответствующим платформенным словом.
Вариант macos
Вариант macos предназначен для macOS и использует механизм Seatbelt. Он позволяет применять системный профиль ограничений к запускаемому процессу. На практике это означает, что отдельные пути, операции и сетевые действия могут быть запрещены независимо от того, что они доступны обычному процессу пользователя.
codex sandbox macos -- /bin/pwd
Запуск простых команд вроде pwd обычно удобен для первичной проверки среды. Более сложные программы могут обратиться к каталогам, системным сервисам или библиотекам, которые профиль песочницы не разрешает.
Вариант linux
Вариант linux предназначен для Linux. Codex CLI может использовать Landlock для ограничений файловой системы и seccomp для ограничения системных вызовов. Реальный набор возможностей зависит от ядра, конфигурации безопасности и того, какие функции доступны текущему пользователю.
codex sandbox linux -- uname -a
Если среда Linux слишком старая или в ней отсутствуют нужные функции ядра, команда может работать с ограничениями, отличающимися от ожидаемых, либо не запуститься. Сообщение об ошибке в таком случае следует рассматривать как указание на несовместимость среды, а не как доказательство неисправности самой запускаемой программы.
Windows и WSL
У codex sandbox нет отдельного универсального варианта windows, который можно было бы считать аналогом macos или linux. При использовании Codex CLI на Windows обычно рассматривают Linux-среду WSL, если она поддерживается установленной конфигурацией. Тогда команда выполняется внутри WSL и относится к Linux-варианту.
codex sandbox linux -- bash -lc 'printf "running in Linux environmentn"'
Важно не смешивать ограничения WSL, ограничения Windows и ограничения Linux-песочницы. Это несколько уровней среды, и итоговое поведение определяется всеми ими одновременно.
| Среда | Используемый вариант | Комментарий |
|---|---|---|
| macOS | macos |
Используется механизм песочницы macOS. |
| Linux | linux |
Используются доступные механизмы ядра Linux. |
| Windows без Linux-среды | Нет отдельного универсального варианта | Нельзя автоматически подставлять windows. |
| Windows через WSL | linux |
Команда запускается в Linux-среде WSL при соответствующей поддержке. |
Практические примеры
Ниже собраны сценарии, показывающие не только синтаксис, но и ожидаемый смысл работы. Все команды следует запускать из каталога проекта или из другого каталога, к которому действительно нужен доступ. Если команда изменяет файлы, песочница не гарантирует автоматический откат этих изменений.
Пример 1. Просмотр текущего каталога
Самый простой тест — вывести рабочий каталог. Он помогает убедиться, что команда запускается из ожидаемого места.
codex sandbox macos -- pwd
Пример 2. Просмотр файлов проекта
Команда ls позволяет проверить, какие файлы видны процессу. Это полезно перед запуском сборки или тестов.
codex sandbox linux -- ls -la
Пример 3. Проверка версии инструмента
Проверка версии почти не затрагивает проект и подходит для диагностики доступности программы внутри песочницы.
codex sandbox macos -- node --version
Пример 4. Запуск Python-скрипта без сетевого доступа по замыслу программы
Скрипт можно запустить в ограниченной среде, если он не должен обращаться к внешним сервисам. Это не гарантирует блокировку каждого возможного канала связи, поэтому результат следует проверять по выводу и документации текущей версии CLI.
codex sandbox linux -- python3 scripts/check_config.py
Пример 5. Запуск тестов
Тесты часто являются хорошим кандидатом для песочницы: им обычно нужны исходники, зависимости и временные файлы, но не полный доступ ко всей системе.
codex sandbox linux -- pytest -q
Пример 6. Запуск npm-тестов
Сценарии npm могут вызывать дочерние процессы и обращаться к кэшу. Если такой запуск завершается ошибкой, это может быть следствием ограничений песочницы, а не ошибки тестов.
codex sandbox macos -- npm test
Пример 7. Проверка Git без изменения файлов
Команда git status помогает проверить состояние рабочего дерева. Такой запуск удобен перед экспериментом с генераторами, сборщиками и миграциями.
codex sandbox linux -- git status --short
Пример 8. Проверка доступности сетевого запроса
Эта команда показывает, что сетевой доступ может быть ограничен. Не следует трактовать любой сетевой сбой как поломку curl: причиной может быть профиль песочницы.
codex sandbox macos -- curl -I https://example.com
Пример 9. Сборка проекта
Сборку можно выполнять в песочнице, если компилятору разрешены нужные каталоги и временные файлы. Перед этим стоит проверить, не требует ли сборочная система загрузки зависимостей из сети.
codex sandbox linux -- make test
Пример 10. Запуск shell-скрипта
Если нужно выполнить несколько связанных команд, их можно передать оболочке. Важно помнить, что оболочка не снимает ограничений: все команды внутри неё остаются дочерними процессами песочницы.
codex sandbox macos -- sh -c 'set -eu; printf "startn"; pwd; printf "donen"'
Пример 11. Проверка записи во временный файл
Этот пример показывает, что разрешённая рабочая область не обязательно является неизменяемой. Файл создаётся явно, поэтому после проверки его следует удалить.
codex sandbox linux -- sh -c 'printf "sandbox testn" > ./sandbox-test.txt; cat ./sandbox-test.txt; rm ./sandbox-test.txt'
Пример 12. Просмотр переменной окружения
Окружение процесса может отличаться от окружения обычного терминала. Проверка помогает понять, какие переменные доступны запускаемой программе.
codex sandbox macos -- sh -c 'printf "PATH=%sn" "$PATH"'
| Сценарий | Команда | Что проверяет |
|---|---|---|
| Каталог запуска | pwd |
Текущую рабочую директорию |
| Файлы | ls -la |
Видимость содержимого каталога |
| Инструмент | node --version |
Наличие программы |
| Тесты | pytest -q |
Работу тестового раннера |
| Git | git status --short |
Состояние репозитория |
| Сеть | curl -I ... |
Результат сетевого ограничения |
| Сборка | make test |
Совместимость сборочной системы |
Ограничения и типичные причины ошибок
Песочница способна нарушить работу программ, которые рассчитывают на полный доступ к системе. Это не обязательно недостаток: именно ограничение возможностей является её назначением. Однако при диагностике важно отличать ошибку программы от отказа среды.
Ошибка «permission denied» внутри песочницы не доказывает, что у пользователя нет прав вообще: доступ мог быть закрыт именно дополнительным профилем изоляции.
Наиболее часто проблемы возникают у программ, которым нужны:
- запись в системные каталоги или произвольные каталоги домашней директории;
- подключение к интернету для загрузки пакетов;
- доступ к Unix-сокетам, Docker daemon или другим локальным сервисам;
- создание специальных устройств и изменение системных параметров;
- запуск низкоуровневых инструментов, использующих запрещённые системные вызовы;
- интерактивный ввод, терминальные возможности или длительно работающие фоновые процессы.
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
Permission denied |
Путь закрыт профилем или правами ОС | Каталог, владельца и режим доступа |
| Сетевой timeout | Ограничение сети или отсутствие маршрута | Работу той же команды без песочницы |
| Команда не найдена | Программы нет в PATH |
command -v tool и окружение |
| Сборка не видит зависимость | Зависимость не установлена или закрыт её путь | Каталог установки и кэш |
| Не работает Docker | Недоступен сокет или daemon | Требования инструмента и доступ к сокету |
| Процесс завершается сразу | Запрещён системный вызов или ресурс | Вывод ошибки и системные журналы |
Первый диагностический шаг — запустить минимальную команду, не меняющую файлы: pwd, ls, проверку версии или git status. Затем можно добавлять элементы по одному. Такой подход напоминает проверку электропроводки: не стоит сразу подключать весь сервер, если ещё неизвестно, работает ли розетка.
codex sandbox linux -- sh -c 'command -v python3 && python3 --version && pwd'
Если минимальная проверка успешна, но сборка нет, проблема, вероятно, связана с требованиями сборочной системы: сетью, каталогом кэша, дочерними процессами или системными библиотеками.
Чем codex sandbox отличается от обычного запуска
Обычный запуск через оболочку передаёт программе права текущего пользователя и стандартное окружение. Если набрать npm test, make или python3 script.py напрямую, программа работает в обычном контексте операционной системы. Команда codex sandbox добавляет слой ограничений до передачи управления дочернему процессу.
При этом песочница не меняет автоматически логику самой программы. Она не анализирует, является ли команда полезной, не исправляет опасные аргументы и не отменяет запись файлов, если запись разрешена. Разница заключается в доступных ресурсах и системных операциях.
| Вопрос | Обычный запуск | codex sandbox |
|---|---|---|
| Кто запускает процесс? | Оболочка напрямую | Codex CLI с платформенным ограничителем |
| Можно ли обратиться к любому доступному пользователю пути? | Обычно да, если хватает прав | Не обязательно |
| Можно ли изменить файл проекта? | Да, если есть права | Да, если путь разрешён песочницей |
| Гарантируется ли отсутствие сетевого доступа? | Нет | Доступ может быть ограничен, но детали зависят от среды |
| Есть ли автоматический откат? | Нет | Нет, если это отдельно не обеспечено внешним инструментом |
| Можно ли использовать любую системную функцию? | В пределах прав ОС | Некоторые операции блокируются дополнительно |
Не следует путать codex sandbox с контейнером, виртуальной машиной или временной файловой системой. Контейнер обычно имеет собственную модель образов, томов и сетей; виртуальная машина эмулирует отдельную операционную систему; временная файловая система может удалять изменения после завершения. Песочница Codex CLI решает более узкую задачу — ограничивает выполнение процесса средствами текущей платформы.
Рекомендации по безопасной работе
Перед запуском команды определите, какие ресурсы ей действительно нужны. Если тестам не нужен интернет, не стоит считать сетевой доступ обязательным. Если скрипту требуется только один каталог, не запускайте его из домашней директории без необходимости.
- Проверьте команду и все её аргументы.
- Убедитесь, что выбрали правильный вариант:
macosилиlinux. - Используйте разделитель
--. - Начните с безопасной диагностической команды.
- Проверьте состояние Git до и после запуска.
- Не ожидайте автоматического отката изменений.
- Если команда требует сети или системного сервиса, заранее учитывайте возможный отказ.
- Для незнакомого проекта используйте копию или отдельную рабочую ветку.
- Проверяйте локальную справку установленной версии.
codex sandbox linux -- git status --short codex sandbox linux -- python3 --version codex sandbox linux -- pytest -q codex sandbox linux -- git status --short
Такой последовательный сценарий показывает состояние репозитория до и после тестов. Если тесты изменяют файлы, разницу можно увидеть через Git, а затем принять решение, какие изменения оставить.
| Проверка | Зачем нужна | Рекомендуемая команда |
|---|---|---|
| Версия CLI | Понять актуальный интерфейс | codex --version |
| Справка песочницы | Увидеть доступные варианты | codex sandbox --help |
| Текущий каталог | Не запустить команду не там | codex sandbox linux -- pwd |
| Состояние Git | Зафиксировать исходное состояние | codex sandbox linux -- git status --short |
| Доступность инструмента | Исключить ошибку PATH |
codex sandbox linux -- command -v tool |
Итоги
codex sandbox — это команда для запуска конкретной программы в ограниченном контексте, а не универсальная система управления изоляцией. Её базовая форма включает платформенный вариант, разделитель -- и команду с аргументами: codex sandbox macos -- <command> или codex sandbox linux -- <command>.
На macOS используется системный механизм Seatbelt, а на Linux — доступные механизмы ядра, включая Landlock и seccomp. Windows не следует указывать как отдельный вариант без подтверждения локальной справки; при работе через WSL используется Linux-среда и соответствующий Linux-вариант, если он доступен.
Песочница уменьшает поверхность риска, ограничивая доступ к файлам, сети и системным операциям, но не гарантирует полного уничтожения последствий. Она не выдаёт привилегии, не делает проект неизменяемым и не выполняет автоматический откат. Поэтому лучший результат достигается в сочетании с понятной командой, резервной копией или Git, проверкой справки и принципом минимально необходимого доступа.