Codex постійно просить підтвердження? Політики підтвердження, пісочниця і «більше не питати»
Codex просить підтвердження, коли команді потрібно вийти за межі пісочниці. Більшість скарг «він весь час питає» спричинені надто суворою пісочницею, налаштуванням, якого більше немає, або відповіддю «більше не питати», що діяла лише в межах сесії.
КОРОТКО
В актуальній версії Codex approval_policy приймає значення on-request (за замовчуванням: модель питає, коли їй потрібно), never або таблицю granular; untrusted видалено, а on-failure тепер просто інша назва для on-request. Як часто вас питають, здебільшого визначає пісочниця: з sandbox_mode = "workspace-write" Codex редагує файли й виконує команди всередині проєкту без запитів. Для команд, яким ви завжди довіряєте, додайте prefix_rule з decision = "allow" у ~/.codex/rules/default.rules. Туди ж зберігається відповідь «більше не питати для команд, що починаються з …».
Спершу: що змінилося в Codex
Багато посібників і відповідей на форумах описують налаштування, які більше не працюють. Перш ніж щось налаштовувати, звірте свій ~/.codex/config.toml із цим списком:
| Старе налаштування | Зараз |
|---|---|
approval_policy = "untrusted" | Видалено. Codex повідомляє «approval_policy = "untrusted" is no longer supported; remove this setting». Натомість документація пропонує sandbox_mode = "read-only" разом з on-request. |
approval_policy = "on-failure" | Досі приймається, але лише як псевдонім on-request. |
--full-auto | Більше немає в довіднику CLI. Найближчий до нього прапорець --approve-for-me (псевдонім --not-so-yolo), який вмикає автоматичну перевірку підтверджень з on-request і пісочницею workspace-write. |
[profiles.name] всередині config.toml | Починаючи з Codex 0.134.0, --profile name натомість читає $CODEX_HOME/name.config.toml. Залишений ключ profile = "x" тепер спричиняє помилку. |
/approvals | Використовуйте /permissions («Set what Codex can do without asking first.») |
Документація Codex теж переїхала: старі сторінки developers.openai.com/codex тепер переспрямовують на learn.chatgpt.com.
Як Codex вирішує, коли питати
Тут у парі працюють два налаштування. Пісочниця обмежує те, до чого може звертатися команда: файли поза проєктом, мережа. Політика підтвердження визначає, що відбувається, коли команді потрібно більше, ніж дозволяє пісочниця.
| sandbox_mode | Що Codex може робити без запиту |
|---|---|
read-only (за замовчуванням) | Читати файли й виконувати команди в пісочниці лише для читання |
workspace-write | Автоматично читати, редагувати й виконувати команди в робочому каталозі |
danger-full-access | Усе, без пісочниці. Не рекомендується |
| approval_policy | Поведінка |
|---|---|
on-request (за замовчуванням) | Модель сама вирішує, коли питати. Команди, дозволені пісочницею, виконуються без підтвердження |
never | Ніколи не питає. Усе, що завершилося помилкою, повертається моделі, а не передається вам |
{ granular = { … } } | Залишає частину категорій запитів інтерактивними, а решту автоматично відхиляє (sandbox_approval, rules, skill_approval, request_permissions, mcp_elicitations) |
Тож у режимі read-only кожне редагування потребує відповіді «так». Це найчастіша причина того, що «Codex питає про все». Навіть у workspace-write каталоги .git, .codex, .agents і .aws залишаються доступними лише для читання, а доступ до мережі вимкнено, доки ви його не ввімкнете.
Це приклад конфігурації з документації OpenAI з поясненнями до параметрів workspace:
Новіші версії також пропонують профілі дозволів (default_permissions із вбудованими :read-only, :workspace і :danger-full-access). Використовуйте або профілі, або sandbox_mode, але не обидва одночасно.
Пресети в CLI, розширенні для IDE і застосунку
Редагувати TOML не обов’язково. У CLI команда /permissions відкриває пресети; у застосунку та розширенні для IDE під полем введення є перемикач дозволів. Пресети CLI:
- Read Only: читає робочу область; для редагування файлів або доступу до інтернету потрібне підтвердження.
- Default: редагує всередині робочої області; для доступу до інтернету або редагування інших файлів потрібне підтвердження.
- Full Access: редагує за межами робочої області й користується інтернетом без запитів.
У застосунку та розширенні для IDE той самий вибір називається Ask for approval, Approve for me і Full access. На старих знімках екрана IDE вони називаються Chat, Agent і Agent (Full Access).
Дозвіл окремих команд за допомогою правил
Якщо потрібно, щоб Codex виконував одну команду поза пісочницею без запиту (наприклад, gh pr view), напишіть правило. Правила експериментальні й зберігаються у файлі .rules у папці rules/ поруч із шаром конфігурації, наприклад ~/.codex/rules/default.rules:
allow: виконувати поза пісочницею без запиту.prompt: питати перед кожною відповідною командою.forbidden: блокувати без запиту.
Якщо збігається кілька правил, перемагає найсуворіше: forbidden важливіше за prompt, яке, своєю чергою, важливіше за allow. Перш ніж покладатися на правило, перевірте команду через codex execpolicy check.
Що насправді зберігає «більше не питати»
Запит підтвердження в Codex CLI пропонує різні варіанти «так», і діють вони дуже різний час:
| Варіант | Скільки діє |
|---|---|
| Yes, proceed | Лише ця команда |
Yes, and don’t ask again for commands that start with <prefix> | Назавжди (записується як правило в ~/.codex/rules/default.rules) |
| Yes, and don’t ask again for this command in this session | До кінця сесії |
| Yes, and don’t ask again for these files | Редагування файлів у цій сесії |
Якщо ви весь час обираєте варіант для сесії, завтра вас спитають знову. Оберіть варіант із префіксом або напишіть правило самі.
Codex у Windows
Найгостріше проблема «питає про все» проявлялася у Windows. В issue #10187 співробітник OpenAI пояснив причину: «Without a sandboxing mechanism, all tool calls need to be manually approved on Windows.» Тепер у Codex є нативна пісочниця для Windows, і вона використовується за замовчуванням:
mxc: рекомендована пісочниця на сумісних пристроях з Windows.elevated: бажаний запасний варіант, якщо MXC недоступна.unelevated: застарілий запасний варіант.
Виконайте /setup-default-sandbox у CLI, щоб налаштувати пісочницю elevated (або codex sandbox setup --elevated для IT-відділу). Рекомендовано Windows 11; Windows 10 1809 і новіші підтримуються без гарантій. Якщо ви працюєте у WSL, Codex використовує там свою пісочницю для Linux, а WSL1 більше не підтримується.
Конфігурація проєкту завантажується лише в довірених проєктах
Файл .codex/config.toml всередині репозиторію читається лише після того, як ви позначите проєкт як довірений. Якщо налаштування проєкту ніби ігноруються, причина в цьому. Запис про довіру в користувацькій конфігурації має такий вигляд:
Налаштування накладаються шарами, від найвищого пріоритету: прапорці командного рядка й перевизначення -c, .codex/config.toml довіреного проєкту, файл --profile, ваш ~/.codex/config.toml, потім системні значення за замовчуванням.
Про прапорець --yolo
--dangerously-bypass-approvals-and-sandbox (псевдонім --yolo) виконує всі команди без підтверджень і без пісочниці. У вихідному коді його описано як «EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed.» Поєднання approval_policy = "never" і danger-full-access робить те саме з файлу конфігурації. Якщо вам потрібно просто менше запитів, workspace-write і кілька правил allow розв’язують задачу, а пісочниця залишається ввімкненою.
Для запитів, що залишаються
Коли Codex питає лише про важливе (мережа, файли поза проєктом, push), залишається одна проблема: вчасно помітити запитання. Pet Island виводить підтвердження команд і редагувань файлів Codex на маленький острів у верхній частині екрана разом із командою або diff, і ви можете дозволити чи заборонити їх, не розшукуючи потрібний термінал. Острів показує, коли Codex працює і коли закінчив, а запитання Codex одним клацанням переводять вас у потрібне вікно. Він працює з Codex CLI і застосунком Codex, а якщо острів закрито, Codex як зазвичай питає у своєму вікні.
Поширені запитання
Як зробити, щоб Codex не просив підтвердження постійно?
Використовуйте sandbox_mode = "workspace-write", щоб Codex міг редагувати файли й виконувати команди всередині проєкту, залиште approval_policy = "on-request" і додайте записи prefix_rule з decision = "allow" у ~/.codex/rules/default.rules для команд, яким ви завжди довіряєте.
Чи підтримується ще approval_policy = "untrusted"?
Ні. Актуальна версія Codex відхиляє її з повідомленням «approval_policy = "untrusted" is no longer supported; remove this setting». Натомість використовуйте sandbox_mode = "read-only" з approval_policy = "on-request".
Що сталося з --full-auto?
Його більше немає в довіднику Codex CLI. Найближчий до нього варіант --approve-for-me (псевдонім --not-so-yolo), який використовує автоматичну перевірку підтверджень з on-request і пісочницею workspace-write.
Чому «більше не питати» не запам’ятовується?
«Don’t ask again for this command in this session» діє лише в межах сесії. Оберіть «don’t ask again for commands that start with …», і правило збережеться в ~/.codex/rules/default.rules.
Чому у Windows Codex питає частіше?
Без пісочниці кожен виклик інструмента потребує підтвердження. Тепер Codex за замовчуванням використовує нативну пісочницю Windows; якщо її не налаштовано, виконайте /setup-default-sandbox.
Чому мій файл проєкту .codex/config.toml ігнорується?
Codex завантажує конфігурацію проєкту лише для довірених проєктів.
Джерела
Усі налаштування й описану поведінку на цій сторінці звірено з цими джерелами 26 жовтня 2026 р.. Агенти швидко змінюються; якщо щось уже не збігається, пріоритет має офіційна сторінка.
- OpenAI: Codex agent approvals and security
- OpenAI: Codex permission modes
- OpenAI: Codex config basics
- OpenAI: Codex sample config
- OpenAI: Codex rules
- OpenAI: Codex Windows sandbox
- OpenAI: Codex CLI reference
- OpenAI: Codex slash commands
- Вихідний код openai/codex (запит підтвердження, помилки конфігурації)
- Issue #10187: Codex repeatedly asks for command approval
- Issue #5131: Always have to approve file edits
- Issue #29406: Approval prompt persists despite don’t ask again