Codex "command failed; retry without sandbox": 6 решений (2026)

Codex просит «retry without sandbox» на каждой команде? Диагноз за 30 секунд

Вы запускаете Codex, он пытается отредактировать файл или выполнить команду, и вы получаете это:

command failed; retry without sandbox?

Прогоните эти три проверки по порядку. Первая, что вернётся неправильно, и есть ваше решение.

codex --version              # запомните версию; в 0.115–0.118 были регрессии
command -v bwrap             # Linux/WSL2: ожидаем путь; пусто = песочница не стартует
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml   # проверьте настройки

Эта статья про ошибки выполнения и песочницы/одобрений во время работы: промпт command failed; retry without sandbox и цикл «каждой команде нужно одобрение». Если ваша проблема — codex: command not found сразу после установки, это проблема PATH, а не песочницы; см. codex: command not found? 7 решений для npm install. Полный список ключей config.toml, которых касается этот пост, — в справочнике разбор config.toml в Codex CLI.

Что этот промпт на самом деле значит (песочница против одобрений)

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

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

• read-only: Codex может читать файлы и запускать команды, которые не пишут
• workspace-write: Codex может читать и править внутри текущего workspace и запускать рутинные локальные команды (это интерактивный дефолт)
• danger-full-access: никаких ограничений на файловую систему или сеть

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

• untrusted: спрашивать перед запуском чего угодно
• on-request: модель сама выполняет рутинную работу и спрашивает только когда нужно выйти за границу (интерактивный дефолт)
• never: никогда не спрашивать; если что-то не разрешено, оно просто падает

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

Так откуда же берётся command failed; retry without sandbox? Команда запустилась, слой песочницы привёл к её завершению с ненулевым кодом, и политика одобрений среагировала, предложив запустить ту же команду снова вне песочницы, как только вы согласитесь. Формулировка намекает «вашему коду нужно больше прав», но очень часто команда прошла бы и так. Сама песочница не смогла стартовать, либо регрессия пометила нормальную правку как отказ.

модель хочет выполнить команду
        │
        ▼
  sandbox_mode применяет границу  ──► команда выполняется чисто ──► готово
        │
        ▼ (команда завершается с ненулевым кодом под песочницей)
  approval_policy реагирует
        │
        ▼
  "command failed; retry without sandbox?"  ──► вы одобряете ──► перезапуск вне песочницы

Держите это разделение в голове. Почти каждое решение ниже — это либо «дать песочнице возможность делать свою работу», либо «сказать политике одобрений перестать дёргать рутину».

Когда чинить конфиг, когда менять версию, а когда просто одобрить

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

Чините конфиг, если bwrap отсутствует или ваши approval_policy/sandbox_mode выставлены строже, чем вам нужно. Это большинство случаев, и им посвящён остаток статьи.

Меняйте версию, если вы на релизе с известной регрессией, а чистый конфиг плюс bubblewrap всё равно вызывают промпт на обычных правках. В нескольких сборках 2026 заехали регрессии apply_patch; зафиксируйте хорошую версию или обновитесь поверх неё.

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

Правило остановки: если вы видите промпт лишь раз-другой в час на реальных сетевых/вне-workspace командах — у вас нет бага. Одобрите и продолжайте. Решения ниже — для случая «на каждой команде».

Ошибки песочницы и одобрений Codex: что значит каждая

Самая частая корневая причина на Linux — первая строка. Документация Codex прямо говорит, что на Linux и WSL2 bubblewrap ставится первым делом; Codex берёт первый bwrap, найденный в PATH, и откатывается на вшитый хелпер, которому нужны непривилегированные user namespaces. Если недоступно ни то, ни другое, Codex печатает предупреждение при старте, и с этого момента каждая команда в песочнице падает в промпт retry. Ровно это поведение описано в issue #19162, где каждая правка файла падала начиная примерно с версии 0.115.0, и первый вопрос мейнтейнера был, установлен ли bubblewrap согласно предпосылкам песочницы.

Какой механизм удерживает песочницу — целиком зависит от вашей платформы, и это решает, есть ли вам вообще что устанавливать:

Если вы на macOS или Windows PowerShell и всё равно получаете промпт на каждой команде — причина почти никогда не в самом механизме песочницы; переходите к Решению 2 (политика одобрений) или Решению 5 (регрессия версии). Решения «установи что-нибудь» — это история про Linux и WSL2.

Как это починить (решения под любую настройку)

Решение 1 (Linux/WSL2): установите bubblewrap

Это решение для случая «каждой команде нужно одобрение» на Linux. Песочнице workspace-write нужен bwrap, чтобы удерживать границу. Без него команды не могут запуститься в песочнице, поэтому падают и эскалируют.

# Debian / Ubuntu / WSL2 (Ubuntu)
sudo apt-get update && sudo apt-get install -y bubblewrap

# Fedora
sudo dnf install -y bubblewrap

# Arch
sudo pacman -S bubblewrap

command -v bwrap   # ожидаем /usr/bin/bwrap

Перезапустите Codex после установки. Предупреждение при старте должно исчезнуть, а правки — перестать вызывать промпт. Если bwrap установлен, но промпт держится, в вашем ядре могут быть отключены непривилегированные user namespaces, либо профиль AppArmor блокирует bubblewrap. Проверьте:

cat /proc/sys/kernel/unprivileged_userns_clone   # ожидаем 1 (или отсутствие файла на новых ядрах)

На Ubuntu 25.10 в частности (issue #17134) пользователи упирались в ограничения AppArmor вокруг bwrap. Свежие релизы Ubuntu идут с политикой AppArmor, которая ограничивает непривилегированные user namespaces — ровно то, на что опирается вшитый хелпер. Если у вас закалённое (hardened) ядро, может потребоваться разрешить соответствующий профиль AppArmor для bubblewrap; на обычном десктопном Ubuntu хватает apt-get install выше, потому что системный bwrap разрешён собственным профилем. Порядок предпочтения такой: сначала установите системный пакет bwrap (он несёт рабочий профиль), и трогайте настройки AppArmor только если пакет на месте, а создание namespace всё ещё падает.

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

Решение 2: выставьте approval_policy в on-request

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

Отредактируйте ~/.codex/config.toml:

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

С on-request Codex сам выполняет рутинные чтения, правки и локальные команды и спрашивает только когда нужно выйти за пределы workspace или достучаться до сети. Можно задать и на один прогон, не трогая файл:

codex --ask-for-approval on-request --sandbox workspace-write

Короткие формы — -a для --ask-for-approval и -s для --sandbox, обе описаны в справочнике командной строки Codex CLI.

Решение 3: уйдите с read-only, чтобы правки были разрешены

Если sandbox_mode = "read-only", Codex не может писать вообще, так что любая его правка либо отклоняется, либо эскалирует в промпт retry. Для нормальной работы с кодом вам нужен workspace-write:

sandbox_mode = "workspace-write"

read-only полезен, когда вы хотите, чтобы Codex анализировал репозиторий, ничего не меняя. Это неправильный режим в тот момент, когда вы просите его править код, а промпт retry — симптом.

Решение 4: разрешите сеть, не сбрасывая песочницу

Частая чрезмерная реакция — сразу прыгать на danger-full-access, потому что упали npm install или git fetch. Это не нужно. Песочница workspace-write по умолчанию блокирует исходящую сеть, но вы можете включить её внутри песочницы:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

Это сохраняет границу файловой системы целой, пропуская установки пакетов и fetch’и. Тянитесь к danger-full-access только когда вам действительно нужны и неограниченная файловая система, и сеть, и предпочтительно делайте это внутри контейнера.

Решение 5: зафиксируйте версию поверх регрессии apply_patch

Если bubblewrap установлен, конфиг чистый, а обычные правки всё равно вызывают промпт — вы, вероятно, на сборке с регрессией. Отчёты:

Issue #16407 привязал регрессию к версии 0.118.0, где apply_patch входил в цикл одобрения патча с промптом retry, тогда как 0.117.0 работала. Issue #19162 сообщил, что поведение началось около 0.115.0 и затрагивало почти каждую правку файла. Issue #18079 описал промпт как вводящий в заблуждение: bubblewrap и запись в файловую систему работали, а apply_patch всё равно просил retry without sandbox.

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

# зафиксировать конкретную версию
npm install -g @openai/[email protected]

# или обновиться до последней и перепроверить
npm install -g @openai/codex@latest
codex --version

После смены версии проверьте тривиальной правкой. Если чистая версия плюс bubblewrap всё снимают — причиной была регрессия, а не ваш конфиг.

Решение 6 (macOS / кроссплатформенно): расширьте writable roots

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

Добавьте путь в writable_roots вместо отключения песочницы:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = ["/Users/you/.cache/mytool"]

Таблица [sandbox_workspace_write] также поддерживает exclude_slash_tmp и exclude_tmpdir_env_var, если вам нужно ужесточить обработку /tmp и $TMPDIR, согласно справочнику конфига.

Заметка про —full-auto и —yolo

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

--full-auto — это устаревший флаг совместимости. Справочник CLI описывает его как deprecated и советует предпочитать --sandbox workspace-write; Codex печатает предупреждение, когда вы его используете. Если старый пост в блоге говорит «просто запусти codex --full-auto», обновите привычку до --sandbox workspace-write --ask-for-approval on-request, который явно задаёт оба контроля.

--dangerously-bypass-approvals-and-sandbox (алиас --yolo) снимает оба контроля разом. Это правильный инструмент только внутри одноразового, изолированного от сети контейнера или VM, потому что Codex тогда может выполнить любую команду с вашими полными правами. Для запусков без присмотра на машине, которая вам дорога, безопаснее сочетание:

codex --sandbox workspace-write --ask-for-approval never

Оно сохраняет границу файловой системы, не делая паузу на одобрения, — а это обычно то, чего люди на самом деле хотят, когда тянутся к --yolo.

Проблемы песочницы Codex в 2026: реальные отчёты

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

Закономерность ясна: кластер регрессий примерно между 0.115 и 0.118, где путь apply_patch чрезмерно срабатывал на промпт, наложенный поверх вечной причины на Linux (bubblewrap не установлен). Если читать только один, #19162 — канонический отчёт «на каждой команде», и ответ мейнтейнера указывает прямо на предпосылки песочницы.

Как подтвердить, что ваша песочница в порядке

После применения решения проверяйте, а не гадайте. Быстрый цикл:

codex --version                         # вне диапазона регрессий
command -v bwrap                        # Linux: разрешается в путь
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml

Затем запустите Codex и проследите за предупреждением о старте песочницы. Нет предупреждения плюс тривиальная правка, которая применяется без промпта, значит граница работает. Если вы хотите, чтобы Codex показал собственный взгляд на окружение, в свежих сборках есть диагностика в стиле codex doctor; запустите codex --help, чтобы увидеть подкоманды, которые открывает ваша версия, поскольку они меняются между релизами.

Практичный приём, когда у вас есть рабочая настройка: сохраните её как именованный профиль, чтобы не перенабирать флаги. Справочник конфига говорит, что файлы профилей лежат рядом с config.toml как $CODEX_HOME/profile-name.config.toml, и вы выбираете один через --profile profile-name. Держите строгий дефолт в config.toml и более свободный файл профиля для репозиториев, которым уже доверяете:

# ~/.codex/trusted.config.toml
approval_policy = "never"
sandbox_mode   = "workspace-write"

Запускайте его через codex --profile trusted. Так ваши повседневные прогоны остаются безопасными, давая вам люк аварийного выхода в один флаг для доверенных репозиториев, ни разу не тянувшись к --yolo.

Когда песочница — не тот слой: обход хлипкого шага модели

Большинство случаев retry-without-sandbox локальны: bubblewrap, конфиг или регрессия версии. Но иногда нижележащая команда в порядке, а медленная или падающая часть цикла — это сама модель, и вы хотите более быстрый или дешёвый бэкенд за тем же рабочим процессом Codex.

Codex CLI говорит с любым OpenAI-совместимым endpoint, поэтому он работает с ofox всего лишь через переменную окружения. Вы направляете Codex на base URL и ключ ofox, оставляете настройки песочницы и одобрений ровно как выше, и маршрутизируете на любую модель:

export OPENAI_BASE_URL="https://api.ofox.ai/v1"
export OPENAI_API_KEY="your-ofox-key"
# затем запускайте Codex как обычно; конфиг песочницы/одобрений неизменен
codex --sandbox workspace-write --ask-for-approval on-request

Это никак не меняет промпт песочницы; это локальный контроль. Это лишь значит, что бэкенд за циклом — ваш выбор. ofox отдаёт OpenAI-совместимый API по https://api.ofox.ai/v1 и перечисляет модели OpenAI (семейство GPT-5.4 и GPT-5.3 Codex) наряду с другими, так что вы можете сохранить локальные средства безопасности Codex и менять модель независимо. Полную настройку провайдера разбирает гайд по настройке API в Codex CLI: base URL, ключ и выбор модели.

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

Если сама модель песочницы не подходит вашему рабочему процессу, вот реалистичные варианты:

• Codex на бэкенде ofox. Сохраните средства песочницы и одобрений Codex, направьте OpenAI-совместимый base URL на https://api.ofox.ai/v1 и выберите модель. Лучше всего, когда вам нравится UX Codex, но нужна гибкость бэкенда. Настройка — одна переменная окружения.
• --sandbox workspace-write --ask-for-approval never. Тот же Codex, без промптов, граница файловой системы цела. Лучше всего для локальных прогонов без присмотра на машине, которой вы доверяете.
• Одноразовый контейнер плюс --yolo. Полный обход внутри изолированной VM или контейнера. Лучше всего для одноразовых окружений, где ничто на хосте не пострадает.
• Другие агентные CLI. У Claude Code и Cursor свои модели прав. Если вы постоянно воюете с песочницей Codex, дефолты другого инструмента могут подойти вам лучше. Сравните их в Claude Code против Codex CLI против Cursor.

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

FAQ

Вопросы выше отражают самые частые запросы вокруг этого промпта. Полный набор — в FAQ-схеме этой страницы; коротко: на Linux установите bubblewrap; везде выставьте approval_policy = "on-request" и sandbox_mode = "workspace-write"; если оба верны, подозревайте регрессию версии в диапазоне 0.115–0.118 и зафиксируйте заведомо рабочую сборку.

Источники, проверенные для этого апдейта

• Codex Configuration Reference, по ключам и значениям approval_policy, sandbox_mode и [sandbox_workspace_write] (проверено 2026-06-29): https://developers.openai.com/codex/config-reference
• Концепции песочницы Codex, по Seatbelt на macOS, bubblewrap на Linux/WSL2, нативной песочнице Windows, первому bwrap в PATH плюс откат на вшитый хелпер (проверено 2026-06-29): https://developers.openai.com/codex/concepts/sandboxing
• Справочник командной строки Codex CLI, по --ask-for-approval (-a), --sandbox (-s), --full-auto (deprecated), --dangerously-bypass-approvals-and-sandbox / --yolo (проверено 2026-06-29): https://developers.openai.com/codex/cli/reference
• GitHub issue #19162, “retry without sandbox” на каждой команде, 0.115.0+ (проверено 2026-06-29): https://github.com/openai/codex/issues/19162
• GitHub issue #16407, регрессия apply_patch в 0.118.0, 0.117.0 работает (проверено 2026-06-29): https://github.com/openai/codex/issues/16407
• GitHub issue #18079, вводящий в заблуждение промпт даже когда bwrap и записи работают (проверено 2026-06-29): https://github.com/openai/codex/issues/18079
• Каталог API ofox, OpenAI-совместимый base URL https://api.ofox.ai/v1, перечислены семейство GPT-5.4 и GPT-5.3 Codex (проверено 2026-06-29): https://ofox.ai/docs