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

Codex уміє сам редагувати файли й запускати команди — і саме тому питання «а що йому взагалі дозволено» перестає бути теоретичним. Більшість плутається, бо шукає «один режим». Насправді ж у Codex два незалежні регулятори: пісочниця вирішує, що агент технічно може зробити, а політика схвалень — коли він зобов’язаний зупинитися й запитати. Звичні назви «read-only», «auto», «full access» — це просто зручні комбінації цих двох регуляторів.

У цьому розборі — як обидва механізми влаштовані окремо, як складаються в пресети, що відбувається з доступом до мережі (локально і в хмарі) та, найголовніше, готова матриця: який режим брати на своєму проєкті, а який — коли відкриваєш чужий незнайомий код. Дані актуальні на 17 липня 2026; імена прапорців і значення політики змінюються від версії до версії — де дивитися свіже, вкажу наприкінці.

Sandbox і approval у Codex: два регулятори, а не один «режим»

Ключ до всього — зрозуміти, що безпека Codex стоїть на двох ногах, і вони не залежать одна від одної.

Пісочниця (sandbox) — це про «що можна фізично». Вона обмежує файлову систему й мережу на рівні процесу: куди агент може писати, звідки лише читати, чи є вихід в інтернет. Навіть якщо модель згенерує небезпечну команду, пісочниця не дасть їй вийти за свої межі.

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Політика схвалень (approval policy) — це про «коли запитати». Вона визначає, у який момент Codex ставить виконання на паузу й просить вашого підтвердження: перед виходом за межі пісочниці, перед доступом до мережі, перед командою поза довіреним набором.

Codex для не-програміста: як зібрати перший робочий продукт

Один продукт на Codex: як довести ідею до живого URL, не потонувши в коді

AGENTS.md: інструкція, яку агент Codex справді читає перед роботою

Codex — не чат-бот, а агент: як формулювати завдання, щоб він робив їх правильно

Некастодіальний міст Boltz вимкнув свопи: команда перестала встигати за автоматизованими атаками

Різниця принципова. Можна поставити «пиши в проєкт без питань» (вільні схвалення), але при цьому «в інтернет — не можна» (жорстка пісочниця). А можна навпаки: «читати будь-що, але будь-яку зміну — тільки з мого дозволу». Саме комбінація двох налаштувань і дає потрібний баланс автономності та контролю, а не один чарівний перемикач.

Звідси проста настанова для читання далі: спершу обираємо пісочницю (межі), потім політику схвалень (частоту питань) — і вже їхня пара перетворюється на зрозумілий пресет.

Пісочниця Codex: три режими доступу

Пісочниця задається параметром sandbox_mode і має три рівні — від найсуворішого «codex read-only режим», де агент лише читає, до повного доступу.

read-only — агент інспектує файли й відповідає на запитання, але не редагує і не запускає команд, що змінюють стан, без окремого дозволу. Ідеальний старт для чужого коду.

workspace-write — робочий режим за замовчуванням для локальної розробки. Codex читає і править файли всередині поточної робочої теки та запускає звичайні локальні команди, але не виходить за її межі. Важливий нюанс: навіть у цьому режимі службові каталоги .git, .codex і .agents лишаються доступними тільки для читання — агент не перепише вашу історію комітів і власний конфіг. Розширити список тек для запису можна ключем writable_roots.

danger-full-access — пісочниця знімається повністю: зникають і файлові, і мережеві межі. Назва з «danger» не для краси. Цей режим виправданий лише там, де оточення й так ізольоване (одноразовий контейнер), а не на робочому ноутбуці з доступом до ваших ключів і репозиторіїв.

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Технічно пісочниця спирається на засоби операційної системи: на macOS це вбудований механізм Seatbelt, на Linux — Landlock і seccomp (через розгортання ізольованого простору, зазвичай за допомогою bubblewrap), на Windows працює нативна пісочниця або Linux-реалізація під час запуску через WSL2. Знати деталі не обов’язково, але корисно розуміти: межі тримає ОС, а не «обіцянка» моделі.

Політика схвалень: коли Codex зупиниться запитати

Другий регулятор — approval_policy (в англомовній документації «codex approval mode»). Він не про межі, а про частоту питань усередині цих меж.

Окремо зазначу on-failure: у багатьох порадниках він досі числиться як робочий варіант «працюй вільно, спитай при помилці». В актуальній конфігураційній документації на дату перевірки це значення позначене як застаріле — використовуйте on-request або never. Це якраз той випадок, де старі статті вводять в оману.

Є й просунутий, «гранулярний» вид політики — об’єкт з окремими прапорцями на різні типи запитів (схвалення виходу з пісочниці, правил, викликів MCP-інструментів тощо). MCP тут — протокол, яким Codex підключає зовнішні інструменти й сервіси; його виклики можна проводити через схвалення окремо від решти команд.

Нарешті, хто відповідає на запити схвалення, теж налаштовується: ключ approvals_reviewer за замовчуванням user (запитують вас), але може бути auto_review — тоді відповідні запити проходять через агента-рецензента, а не спливають вам на екран.

Як режими складаються в пресети Read Only / Auto / Full Access

Користувачу в інтерфейсі не доводиться щоразу збирати пару вручну — Codex пропонує три готові пресети. Перемкнути їх у CLI можна командою /permissions (у частині версій це стартовий селектор режиму).

• Read Only — --sandbox read-only --ask-for-approval on-request. Codex читає файли й відповідає на запитання; на будь-яку зміну, запуск команди чи доступ до мережі просить дозвіл.
• Auto (за замовчуванням) — --sandbox workspace-write --ask-for-approval on-request. Агент сам читає, редагує й запускає команди в робочій теці, але запитує, щоб вийти за її межі або отримати мережевий доступ. Це режим, який закриває більшу частину повсякденної роботи без ризику, що агент піде за межі проєкту.
• Full Access — прапорець --dangerously-bypass-approvals-and-sandbox (короткий аліас --yolo). Знімає і пісочницю, і питання. Максимум автономності — і максимум відповідальності на вас.

Прапорці можна комбінувати й вручну: --sandbox задає пісочницю, --ask-for-approval — політику. Прапорець --full-auto застарів (під час запуску Codex виводить попередження) — раніше він вмикав пару workspace-write без зайвих питань. Сучасна заміна — явний прапорець --sandbox workspace-write.

Тут-таки зрозуміло, чим «codex повний доступ» (full access) відрізняється від «auto»: в auto мережа й вихід із теки під запитом, а у full access — немає ні пісочниці, ні запитів узагалі.

Мережевий доступ: локально і в хмарі — це різні історії

Мережа — найчастіше місце, де щось «не працює», і водночас найчутливіше налаштування з погляду безпеки.

Локально (Codex CLI). У режимі workspace-write мережа за замовчуванням вимкнена. Це свідоме рішення розробників: агент, який має вихід в інтернет і читає недовірений контент, — потенційна мішень для промпт-ін’єкції. Вмикається мережа окремо, у таблиці [sandbox_workspace_write] ключем network_access = true. На практиці це виглядає так: команда, якій потрібна мережа (наприклад, npm install або curl), падає всередині пісочниці, і за політики on-request Codex запитує, чи виконати її поза пісочницею. Якщо агенту справді потрібен пошук в інтернеті, розумніше не відкривати мережу навстіж, а розібратися, який web search API підключити агенту під конкретне завдання.

У хмарі (Codex Cloud). Тут модель доступу влаштована акуратніше й заслуговує окремої уваги, бо конкуренти її майже не розбирають. У хмарного завдання дві фази. Фаза setup-скрипта запускається з доступом в інтернет — щоб поставити залежності. А от фаза агента за замовчуванням іде без інтернету. Агентський доступ налаштовується на рівні оточення й має два стани:

• Off (за замовчуванням) — інтернет для агента повністю закритий.
• On — доступ є, і його можна звузити: обмежити дозволеним списком доменів (allowlist) і списком припустимих HTTP-методів. Тобто «обмежений доступ» — це не окремий третій перемикач, а той самий On з надітими обмеженнями.

Для звуження доменів пропонують преднастроєні списки: None (порожній, домени додаєте самі), Common dependencies (популярні репозиторії — npm, PyPI, Docker, GitHub і подібні) та All (без обмежень). Методи можна врізати — наприклад, лишити тільки GET, HEAD і OPTIONS, заблокувавши POST, PUT, DELETE та інші змінювальні запити. Увесь вихідний трафік при цьому йде через HTTP/HTTPS-проксі, а стан контейнера кешується до 12 годин.

Схожа логіка «дозволити публічний інтернет окремим налаштуванням» є і в суміжного агента OpenAI — ChatGPT Work: доступ до мережі там теж вмикається свідомо, а не за замовчуванням.

Матриця «пісочниця × схвалення»: коли що брати

Тепер найголовніше — власний фреймворк вибору. Тримайте в голові одне правило: беріть найвужчий профіль, за якого завдання ще виконуване. Розширити доступ простіше, ніж розгрібати наслідки зайвої автономності.

Розкладу три частих config.toml. Файл лежить у $CODEX_HOME/config.toml (за замовчуванням ~/.codex/config.toml).

Свій проєкт, низьке тертя:

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

Чужий або недовірений код на робочій машині (розумні значення за замовчуванням — мережа вимкнена):

approval_policy = "untrusted"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

Неінтерактивний CI-прогін, де оточення саме обмежує шкоду:

approval_policy = "never"
sandbox_mode = "read-only"

Сенс матриці: не шукати «правильний режим узагалі», а під кожне завдання добирати пару «межі + частота питань».

config.toml і профілі доступу: точне налаштування

Коли трьох пресетів мало, у дію йдуть іменовані профілі. Codex розрізняє довірені й недовірені проєкти: конфігурація з теки проєкту (шар .codex/) підхоплюється тільки для довіреного проєкту; недовірений відкочується до користувацьких, системних і вбудованих значень. Це захищає від того, щоб чужий репозиторій потайки нав’язав вам свої налаштування доступу.

Профілі доступу (permission profiles) — це іменовані комбінації пісочниці та політики під різні контексти. Вбудовані профілі: :read-only, :workspace і :danger-full-access. Свій профіль описується секцією [permissions.<ім'я>], а який із них вважати профілем за замовчуванням — задає ключ default_permissions (можна вказати ім’я свого профілю або один із вбудованих).

Корисні ключі таблиці [sandbox_workspace_write] для тонкого налаштування запису:

• network_access — вихід у мережу всередині пісочниці (за замовчуванням false);
• writable_roots — додаткові каталоги, куди дозволено запис;
• exclude_tmpdir_env_var та exclude_slash_tmp — виключити $TMPDIR і /tmp зі шляхів для запису.

Окрема добра звичка — не пускати в шелл агента зайві секрети: політикою оточення (shell_environment_policy) можна виключити чутливі змінні на кшталт ключів доступу до хмари, щоб вони не витекли в команди.

Ризики й типові помилки

Відверто про те, де це ламається — бо «увімкнув full access, і все летить» закінчується передбачувано.

• danger-full-access / --yolo на робочій машині. Знята пісочниця на ноутбуці, де є доступ до репозиторіїв, хмарних ключів і пошти, — це готовий канал ексфільтрації, якщо модель виконає невдалу команду. Тримайте повний доступ тільки в одноразовому ізольованому контейнері.
• network_access = true без потреби. Щойно агент отримує доступ до мережі й читає недовірений вебконтент, відкривається вектор промпт-ін’єкції: інструкція, схована на сторінці чи в залежності, може відвести агента від завдання. Увімкнений інтернет — це ще й ризик витоку коду та секретів і завантаження вразливих залежностей. Ставтеся до кожного true як до окремого свідомого рішення.
• Сліпа віра в read-only. Режим задуманий як «тільки читання», але в Codex відкритими числилися баги, коли через MCP-інструменти чи окремі шляхи запис усе ж проходив (issues #4152 та #12896 у репозиторії на 17 липня 2026). Висновок не «режим марний», а «критичне все одно запускайте в ізольованому оточенні, а не лише покладаючись на прапорець».
• never без жорсткої пісочниці. Вимкнути питання й лишити широку пісочницю — означає отримати агента без гальм. never виправданий тільки коли межі тримає щось іще (read-only або контейнер).
• Ретрай без пісочниці «на автоматі». Коли команда падає через відсутність мережі, легко машинально схвалити її виконання поза пісочницею. Перш ніж натиснути «так», переконайтеся, що це справді npm install, а не щось, чому вихід назовні не потрібен.

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

Що в пісочниці Codex застаріє першим: імена прапорців і пресети

Імена прапорців, набір значень політики схвалень і склад пресетів Codex змінює часто (свіжий приклад — застарілий on-failure). Перш ніж закладати режим у свій config.toml чи CI, звіряйтеся з актуальною конфігураційною документацією Codex і довідкою codex --help. Дані в цьому розборі перевірені на 17 липня 2026.

FAQ

Чим пісочниця відрізняється від політики схвалень? Пісочниця визначає, що агент технічно може зробити (куди писати, чи є мережа). Політика схвалень — коли він зупиняється й запитує дозвіл. Це два незалежні регулятори: пресети Read Only, Auto і Full Access — просто їхні зручні комбінації.

Який режим Codex стоїть за замовчуванням? Auto: пісочниця workspace-write плюс політика on-request. Агент сам працює всередині робочої теки, але запитує, щоб вийти за її межі або отримати доступ до мережі.

Чи є в Codex інтернет за замовчуванням? Ні. Локально в workspace-write мережа вимкнена й вмикається ключем network_access = true. У Codex Cloud інтернет агенту теж закритий за замовчуванням (Off), хоча фаза встановлення залежностей виконується з доступом до мережі.

Як безпечно запустити Codex на чужому незнайомому коді? Почніть із пресета Read Only (read-only + on-request): агент прочитає й пояснить проєкт, але нічого не змінить без вашого дозволу. Мережу не відкривайте. Так ви оцінили код, нічим не ризикнувши.

Що робить --yolo і коли він припустимий? --yolo (він же --dangerously-bypass-approvals-and-sandbox) знімає і пісочницю, і запити схвалення — повна автономність. Припустимий тільки в одноразовому ізольованому контейнері, ніколи — на робочій машині з доступом до ваших ключів і репозиторіїв.

Куди писати налаштування режимів? У config.toml в каталозі $CODEX_HOME (за замовчуванням ~/.codex/config.toml) ключами sandbox_mode, approval_policy і таблицею [sandbox_workspace_write]. Для різних контекстів зручні іменовані профілі [permissions.<ім'я>] і ключ default_permissions.