Від Matt Connor 2026-08-09 · Оновлено 2026-08-13

Claude Code: автоматичний режим стане стандартним

Q: Як заборонити всім на моєму сервері використовувати auto mode або bypass mode?

Установіть permissions.disableAutoMode і permissions.disableBypassPermissionsMode у значення "disable" у файлі /etc/claude-code/managed-settings.json. Керовані налаштування мають вищий пріоритет за всі інші області дії, тому жоден файл налаштувань користувача та жоден прапорець командного рядка не може їх перевизначити. disableAutoMode вилучає auto із циклу Shift+Tab і відхиляє --permission-mode auto під час запуску. disableBypassPermissionsMode також працює з будь-якої області дії, тому окремий користувач може встановити його у власному ~/.claude/settings.json.

14 August 2026 автоматичний режим стане стандартним у Claude Code для Pro, Max і Team. Порівнюємо режими дозволів і вибір для сервера без нагляду.

Що змінює автоматичний режим 14 August 2026

Автоматичний режим Claude Code виконує виклики інструментів без паузи для запиту вашого підтвердження та спочатку передає кожну дію окремій моделі-класифікатору на перевірку. Починаючи з 14 August 2026, саме в цьому режимі запускатимуться нові сеанси в планах Pro, Max і Team. Ви можете будь-коли змінити режим, а встановлений вами раніше режим за замовчуванням не буде перезаписано.

У документації цю зміну описано так:

Починаючи з 14 August 2026, автоматичний режим стане стандартним режимом дозволів для нових сеансів у планах Pro, Max і Team. Ви можете будь-коли змінити режим. Встановлений вами режим за замовчуванням залишиться без змін, якщо ви не погодитеся на одноразову пропозицію змінити його, а режим за замовчуванням, яким керує ваша організація, не зміниться.

Тут важливіші за дату два положення. defaultMode, який ви встановили у власному файлі налаштувань, збережеться після зміни. Режим за замовчуванням, розгорнутий вашою організацією через керовані налаштування, також не зміниться. У повідомленні про оголошення додатково зазначено, що на першому етапі розгортання автоматичний режим залишатиметься необов’язковим для планів Enterprise і облікових записів, які використовують API.

Якщо ви запускаєте Claude Code на VPS (virtual private server), цю зміну варто врахувати до її набуття чинності. Запит дозволу є контрольної точкою, для якої потрібна людина за клавіатурою. На віддаленому сервері вас часто немає, тому режим, у якому запускається сеанс, може залишатися активним протягом кількох годин.

Режими дозволів Claude Code: від найсуворішого контролю до найменшого

Є шість режимів. Назва на початку кожного рядка — це значення, яке потрібно вказати в налаштуваннях або передати до --permission-mode.

default: Claude запитує дозвіл перед кожним новим використанням інструмента. Читання в межах робочого каталогу все одно виконується без запиту. CLI (інтерфейс командного рядка) позначає цей режим як Manual і приймає manual як псевдонім, починаючи з Claude Code v2.1.200.
plan: Claude читає файли та виконує команди для аналізу, але не змінює вихідний код. Редагування залишаються заблокованими, доки ви не схвалите план.
acceptEdits: редагування файлів виконуються без запиту разом із командами файлової системи mkdir, touch, rm, rmdir, mv, cp і sed. Це діє лише для шляхів у межах робочого каталогу або additionalDirectories. Для всіх інших shell-команд усе одно потрібне підтвердження.
auto: виконується все, але класифікатор спочатку перевіряє кожну дію. Явні правила ask усе одно вимагають підтвердження.
dontAsk: Claude Code автоматично відхиляє все, для чого потрібен був би запит. Виконуються лише ваші правила allow, вбудовані Bash-команди, доступні лише для читання, і виклики, схвалені хуком PreToolUse. Сеанс ніколи не очікує введення.
bypassPermissions: запити та перевірки безпеки пропускаються, зокрема для запису в захищені шляхи, такі як .git і .claude.

Під час сеансу натискайте Shift+Tab, щоб циклічно перемикатися між default, acceptEdits і plan. У рядку стану відображається вибраний режим, наприклад ⏵⏵ auto mode on або сірий ⏸ manual mode on. Інші режими за замовчуванням до цього циклу не входять. auto додається до нього, коли ваш обліковий запис відповідає вимогам для цього режиму. bypassPermissions додається лише тоді, коли сеанс запущено з --permission-mode bypassPermissions або --dangerously-skip-permissions. dontAsk у цьому циклі не відображається, тому встановлюйте його за допомогою claude --permission-mode dontAsk.

Для автоматичного режиму також потрібна актуальна модель. Зазвичай саме тому цей режим взагалі не відображається. Станом на August 2026 у документації зазначено Claude Opus 4.6 або новішу версію, Sonnet 4.6 або новішу версію, а також Fable 5 в Anthropic API. Також зазначено, що старіші моделі, такі як Sonnet 4.5, не підтримуються жодним провайдером. Якщо Claude Code повідомляє, що автоматичний режим недоступний, одну з цих вимог не виконано. Це не тимчасовий збій, тому очікування не допоможе.

Два елементи керування діють у кожному режимі, зокрема bypassPermissions: правила deny і явні правила ask. Це налаштування, які залишаються під вашим контролем незалежно від режиму, з якого починається сеанс.

Що блокує класифікатор автоматичного режиму

Класифікатор — це друга модель, яка читає заплановану дію та визначає, чи відповідає вона вашому запиту. Документація описує його завдання одним реченням:

Окрема модель-класифікатор перевіряє дії перед виконанням і блокує все, що виходить за межі вашого запиту, стосується невідомої інфраструктури або, імовірно, спричинене шкідливим вмістом, прочитаним Claude.

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

Завантаження та виконання коду, наприклад curl | bash
Розгортання та міграції у production
Примусовий push
Зміна спільної інфраструктури
Відкриття тунелю або reverse shell, що робить локальний сервіс доступним із публічного інтернету
Виведення чинних облікових даних або токена в transcript чи файл

За замовчуванням дозволені:

Операції з локальними файлами у вашому робочому каталозі
Встановлення залежностей, оголошених у lock-файлах або manifest-файлах
HTTP-запити лише для читання
Push до будь-якої гілки репозиторію, з яким ви працюєте

Не покладайтеся на підсумок на кшталт наведеного вище. Виконайте claude auto-mode defaults, щоб вивести повні списки правил у форматі JSON, і перегляньте набір правил, який постачається з установленою у вас версією.

Перед використанням цього механізму врахуйте два задокументовані обмеження. По-перше, класифікатор бачить ваші повідомлення, виклики інструментів і вміст CLAUDE.md, але результати інструментів вилучаються. Тому текст у файлі або на вебсторінці, яку прочитав Claude, не може безпосередньо впливати на класифікатор. По-друге, коли класифікатор блокує дію 3 рази поспіль або 20 разів протягом одного сеансу, автоматичний режим призупиняється, а Claude Code знову починає запитувати ваші підтвердження. Ці пороги не можна налаштувати. У неінтерактивному режимі з прапорцем -p нікому поставити запитання, тому повторні блокування натомість завершують сеанс з помилкою.

Саме друга особливість створює проблеми на віддаленому сервері. Некерований запуск, який досягає цього ліміту, зупиняється й очікує на людину, яка не стежить за терміналом. Інша частина рішення — звузити завдання агента. Для цього скрипт, який спрямовує агента до найменшої працездатної зміни, допомагає не допустити, щоб сеанс перейшов до масштабних дій, які зупиняє класифікатор.

Де зберігаються режими у settings.json

Усе описане вище є одним об’єктом у файлі налаштувань.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Правила перевіряються по черзі: deny, потім ask, потім allow. Результат визначає перше правило, що збігається в цьому порядку. Вужче правило не має пріоритету над ширшим правилом, яке розташоване раніше. Правило deny для Bash(aws *) блокує aws s3 ls, навіть якщо для цієї самої команди задано allow. Тому правило deny не може містити винятки.

ask — це тип правила, який використовується в auto mode. Auto mode прибирає стандартний запит підтвердження, а правило ask повертає його для конкретної команди, яка потребує підтвердження користувача. Команду розгортання слід додати саме туди. Так само можна додати Bash(git push *), якщо передавання коду із сервера має виконуватися лише після контрольної перевірки. Зберігання файлів облікових даних у deny — інша частина цього підходу. Воно доповнює недопущення доступу агента до облікових даних із самого початку.

Файли налаштувань у порядку від найнижчого пріоритету:

~/.claude/settings.json: налаштування вашого користувача, які застосовуються в кожному проєкті.
.claude/settings.json: налаштування проєкту, зафіксовані в репозиторії.
.claude/settings.local.json: ваші власні налаштування для одного репозиторію, які ігноруються git.
Керовані налаштування, розгорнуті адміністратором. У Linux цей файл має назву /etc/claude-code/managed-settings.json. Жодне налаштування не може перевизначити правило дозволів, задане адміністратором, зокрема параметр командного рядка.

Тут є одна особливість із документованою причиною. defaultMode: "auto" ігнорується, якщо його задано у .claude/settings.json або .claude/settings.local.json, починаючи з Claude Code v2.1.142. Це не дає репозиторію самостійно вмикати auto mode через файл налаштувань. Якщо вказати цей параметр там, сеанс запускається в режимі default, і жодного повідомлення про помилку не виводиться. Перемістіть цей рядок до ~/.claude/settings.json. Виконайте /permissions, щоб переглянути всі активні правила поруч із файлами, з яких вони походять.

Два перемикачі, які вимикають режим

Адміністратори мають два аварійні перемикачі, і обидва приймають рядок "disable", а не булеве значення.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

У документації точно вказано, де їх потрібно задати:

Щоб заборонити використання режиму bypassPermissions або auto, задайте permissions.disableBypassPermissionsMode або permissions.disableAutoMode значення "disable" у будь-якому файлі налаштувань. Найбільше вони корисні в керованих налаштуваннях, де їх не можна перевизначити.

disableAutoMode вилучає auto із циклу Shift+Tab і відхиляє --permission-mode auto під час запуску. disableBypassPermissionsMode виконує те саме завдання для режиму обходу та працює з будь-якої області видимості, тому його можна задати у власному ~/.claude/settings.json, щоб заблокувати собі доступ до режиму, яким не варто користуватися о 2-й ночі на робочому сервері. На сервері, яким користуються інші люди, натомість задайте обидва параметри у /etc/claude-code/managed-settings.json, оскільки файл налаштувань користувача належить користувачеві, а керований файл — ні.

Чому для auto mode на VPS потрібна ізоляція

Класифікатор перевіряє одну дію за раз. Він не контролює наслідки схваленої дії. У документації межу визначено чітко:

Класифікатор контролює окремі дії, а не забезпечує ізоляцію, тому ізоляція залишається додатковим рівнем захисту для запусків без нагляду. Вона не є обов’язковою лише для --dangerously-skip-permissions.

Тому для віддаленого сервера потрібне поєднання auto mode із середовищем, яке можна безпечно втратити, а не bypassPermissions і сподівання на краще. Bypass mode призначено лише для ізольованих середовищ: контейнерів, віртуальних машин або dev containers без доступу до інтернету, де Claude Code не може пошкодити хост-систему. VPS, на якому працюють база даних і reverse proxy, не належить до таких середовищ.

На сервері найбільше значення мають три заходи. Запускайте Claude Code від імені звичайного користувача, ніколи не використовуйте root. Надайте цьому користувачеві робочий каталог і не залишайте в ньому інших даних, які варто читати. Перебудовуйте сервер замість його відновлення. Саме це є аргументом на користь одноразової VM, яку ви видаляєте після кожного завдання. Детальний опис посилення захисту — від створення користувача до правил firewall — наведено в повному описі безпечного запуску Claude Code на VPS, тому тут його не повторено.

Claude Code самостійно контролює правило для root. У Linux і macOS він відмовляється запускатися в bypass mode від імені sudo або root:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

У розпізнаному sandbox ця перевірка не виконується. Тому для автономної роботи в контейнері документація рекомендує dev container, у якому Claude Code запускається від імені не root-користувача. Якщо ви керуєте агентом із телефона або ноутбука через SSH, те саме міркування стосується довготривалого сеансу Claude Code, відкритого в tmux: під час роботи сеансу ніхто не контролює запити.

Налаштуйте Bash sandbox на Ubuntu VPS

Вбудований sandbox обмежує доступ до файлової системи та мережі для кожної команди Bash, яку запускає Claude. Операційна система також застосовує ці обмеження до дочірніх процесів. У Linux для цього потрібні два пакети.

sudo apt-get install bubblewrap socat

Запустіть Claude Code і виконайте /sandbox. Відкриється панель із вкладками Mode та Overrides, а також вкладкою Dependencies зі списком відсутніх компонентів. Перевірка залежностей виконується під час запуску, тому після встановлення пакетів перезапустіть Claude Code. Інакше панель і надалі показуватиме, що вони відсутні.

В Ubuntu 24.04 і новіших версіях політика AppArmor за замовчуванням не дає bubblewrap створювати потрібні йому користувацькі простори імен, тому sandbox не запускається. Перевірте, чи стосується це вашого сервера:

sysctl kernel.apparmor_restrict_unprivileged_userns

Повідомлення 0 або помилка про відсутність такого ключа означає, що нічого робити не потрібно. Повідомлення 1 означає, що для bwrap потрібен власний профіль:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

Профіль застосовується безпосередньо до bwrap, а не до команд, які він запускає всередині sandbox. Потім звузьте межі доступу в налаштуваннях:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Цей блок потрібно додати до .claude/settings.json проєкту, оскільки . визначається як кореневий каталог проєкту лише в налаштуваннях проєкту. Якщо додати ті самі рядки до ~/.claude/settings.json, . натомість визначатиметься як ~/.claude. У такому разі правило denyRead блокуватиме доступ до файлів проєкту, і кожна команда не зможе читати код, який вона має редагувати.

Врахуйте, чого це не охоплює. Sandbox обмежує Bash і його дочірні процеси. Вбудовані файлові інструменти виконуються всередині процесу Claude Code, а сервери MCP (model context protocol) і хуки є окремими процесами, які працюють на хості без обмежень. Щоб розмістити всі ці компоненти за однією межею ізоляції, запускайте весь процес Claude Code усередині контейнера, віртуальної машини або пакета @anthropic-ai/sandbox-runtime, який на момент написання матеріалу доступний як бета-версія дослідницького попереднього перегляду.

Який режим відповідає кожному сценарію?

Окремий репозиторій на власному ноутбуці

Використовуйте auto, додавши правила ask для дій, які потрібно виконувати без додаткового підтвердження. Ви працюєте за клавіатурою, резервний механізм класифікатора справді може звернутися до вас, а потенційна шкода обмежена одним комп’ютером під вашим контролем. Саме для цього сценарію було створено стандартне значення від 14 August.

Спільний VPS

Використовуйте auto для кожного користувача. Встановлюйте його у власному ~/.claude/settings.json відповідного користувача на сервері, де обліковий запис, від якого працює Claude Code, не є root і не може читати робочі дані інших користувачів. Розгорніть disableBypassPermissionsMode як "disable" у /etc/claude-code/managed-settings.json разом із правилами заборони, які захищають спільні шляхи. Спільний сервер — найочевидніший сценарій, у якому bypassPermissions є неправильним вибором, оскільки межа ізоляції, на яку розрахований цей режим, відсутня: інші орендарі перебувають усередині неї.

CI та сеанси без нагляду

Використовуйте dontAsk із явним списком allow команд, потрібних завданню. Автоматична заборона є правильною реакцією за замовчуванням, якщо ніхто не побачить запит на підтвердження. Автоматичний режим також працює неінтерактивно, але повторні блокування класифікатором переривають сеанс -p. Тому завдання, у якому виникають такі блокування, завершується помилкою після часткового виконання. Застосовуйте bypassPermissions лише в контейнері або віртуальній машині, яку щоразу перебудовуєте з образу, і не використовуйте його на хості, де працюють важливі для вас служби.

FAQ

Коли auto mode стане режимом за замовчуванням у Claude Code?

З 14 August 2026 для нових сеансів у планах Pro, Max і Team. У документації зазначено, що режими можна перемикати в будь-який час, встановлений вами режим за замовчуванням зберігається, доки ви не погодитеся на одноразову пропозицію перемикання, а режим за замовчуванням, яким керує організація, не змінюється. В оголошенні зазначено, що на першому етапі розгортання auto mode залишається необов’язковим для планів Enterprise і облікових записів, які використовують API. Перевірте фактичний режим сеансу в рядку стану: в auto mode там відображається ⏵⏵ auto mode on.

Чи використовувати auto mode або bypassPermissions на VPS?

Використовуйте auto mode разом із boundary ізоляції. Класифікатор перевіряє кожну дію перед виконанням, але в документації чітко зазначено, що це контроль на рівні окремої дії, а не boundary ізоляції. Тому для unattended run усе одно потрібні контейнер, віртуальна машина або сервер, який можна безпечно перебудувати. bypassPermissions повністю пропускає перевірки й призначений лише для ізольованих середовищ. Claude Code відмовляється запускатися в цьому режимі від імені root у Linux і виводить --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons.

Як заборонити всім на моєму сервері використовувати auto mode або bypass mode?

Установіть permissions.disableAutoMode і permissions.disableBypassPermissionsMode у значення "disable" у файлі /etc/claude-code/managed-settings.json. Керовані налаштування мають вищий пріоритет за всі інші області дії, тому жоден файл налаштувань користувача та жоден прапорець командного рядка не може їх перевизначити. disableAutoMode вилучає auto із циклу Shift+Tab і відхиляє --permission-mode auto під час запуску. disableBypassPermissionsMode також працює з будь-якої області дії, тому окремий користувач може встановити його у власному ~/.claude/settings.json.

Чому моє налаштування `defaultMode: "auto"` ігнорується?

Тому що воно міститься в неправильному файлі. Починаючи з Claude Code v2.1.142, defaultMode: "auto" ігнорується, якщо надходить із .claude/settings.json або .claude/settings.local.json. Це не дає репозиторію самостійно вмикати auto mode через файл налаштувань. Сеанс запускається в режимі default без повідомлення про помилку. Перемістіть налаштування до ~/.claude/settings.json, а потім виконайте /permissions, щоб перевірити, з якого файлу надійшло кожне активне правило. Якщо auto mode усе ще недоступний, перевірте вимоги до моделі: старіші моделі, наприклад Sonnet 4.5, не підтримуються в жодного провайдера.

#claude-code #permissions #ai-agents #security #vps

Що змінює автоматичний режим 14 August 2026

Режими дозволів Claude Code: від найсуворішого контролю до найменшого

Що блокує класифікатор автоматичного режиму

Де зберігаються режими у settings.json

Два перемикачі, які вимикають режим

Чому для auto mode на VPS потрібна ізоляція

Налаштуйте Bash sandbox на Ubuntu VPS

Який режим відповідає кожному сценарію?

Окремий репозиторій на власному ноутбуці

Спільний VPS

CI та сеанси без нагляду

FAQ

Коли auto mode стане режимом за замовчуванням у Claude Code?

Чи використовувати auto mode або bypassPermissions на VPS?

Як заборонити всім на моєму сервері використовувати auto mode або bypass mode?

Чому моє налаштування defaultMode: "auto" ігнорується?

Чому моє налаштування `defaultMode: "auto"` ігнорується?