Режими доступу та дозволи Claude Code: як не дати агенту знести пів системи

Коротко (TL;DR)

Claude Code — агент, який уміє сам правити файли і запускати команди в терміналі. Логічне запитання: як вирішувати, що йому можна без дозволу, а що ні? Відповідь — режими доступу. Їх кілька, і плутанина між ними призводить до двох крайнощів: або ви втомлюєтеся підтверджувати кожен крок, або в пориві «хай працює сам» знімаєте всі перевірки й одного разу втрачаєте дані.

Коротко розклад по режимах, між якими перемикаються клавішею Shift+Tab: Manual (default) — питає перед кожною правкою і командою; acceptEdits (auto-accept) — сам приймає правки файлів; plan — лише читає і планує, нічого не змінює; auto — окремий класифікатор пропускає безпечне і блокує небезпечне; bypassPermissions, він же «YOLO» через прапорець --dangerously-skip-permissions — не питає взагалі нічого.

І окремо стоїть sandbox — це не режим, а шар ізоляції: він обмежує, що запущена команда може дістати на диску і в мережі. Його можна комбінувати з будь-яким режимом.

Ця стаття для тих, хто вже опанував базовий метод роботи з Claude Code і хоче налаштувати доступ свідомо. Нижче — що робить кожен режим, чим реально небезпечний YOLO (із задокументованим інцидентом), і матриця «який режим під який сценарій».

Як перемикати режими: Shift+Tab і статус-бар

Основний спосіб змінити режим прямо в сесії — клавіша Shift+Tab. Вона циклічно перебирає режими: default (Manual) → acceptEdits → plan, а якщо ви ввімкнули додаткові режими, вони вбудовуються в цикл після plan (bypassPermissions, потім auto). Поточний режим завжди видно в статус-барі внизу — наприклад, ⏵⏵ accept edits on для acceptEdits. Плюс plan mode можна ввімкнути командою /plan або запуском claude --permission-mode plan.

Творець ШІ-агента Hermes Nous Research веде перемовини про раунд за оцінки $1,5 млрд

Інженер Anthropic змусив Claude спроєктувати стійку під кластер материнок Framework

Що показало й чого не показало нове дослідження інтерпретованості Anthropic

Слеш-команди Claude Code: повна шпаргалка і розбір /effort, /config, /resume та /compact

Метод роботи з Claude Code: як керувати агентом, щоб отримувати хороший результат

Важливо зрозуміти базову механіку: режим доступу відповідає на запитання «чи потрібно спитати дозвіл перед тим, як виконати дію». Це не про те, що агент фізично може, а про те, де він зупиняється і чекає вашого «так».

Manual (default): питає перед кожною дією

Режим за замовчуванням — найбезпечніший. Станом на липень 2026 в інтерфейсі він називається Manual (значення в конфізі — default). Без підтвердження проходять лише операції читання; будь-яка правка файлу чи запуск bash-команди потребують вашого явного «так».

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

acceptEdits (auto-accept): сам приймає правки

Режим acceptEdits — те, що в інтерфейсі називають «auto-accept edits». Вмикається тим самим Shift+Tab, статус-бар показує ⏵⏵ accept edits on. Він автоматично схвалює правки файлів — і це прискорює роботу, коли ви вже довіряєте напрямку.

Тонкість, яку пропускають майже всі гайди: acceptEdits авто-схвалює не лише правки файлів, а й фіксований набір безпечних файлових команд — mkdir, touch, rm, rmdir, mv, cp, sed — але лише в межах робочої директорії. Усі інші bash-команди все одно потребуватимуть підтвердження. Тобто це «довіряю правкам у проєкті», а не «роби що завгодно».

plan mode: лише дивиться, нічого не змінює

Режим планування — дзеркальна протилежність. У ньому Claude фізично не може редагувати файли: доступні лише читання і безпечне read-only дослідження. Він вивчає код, відповідає на запитання і пропонує план — але не чіпає нічого, доки ви не схвалите.

Коли план готовий, Claude пропонує варіанти продовження: схвалити й перейти в авто-режим, схвалити з автоприйняттям правок, схвалити з ручним підтвердженням кожного кроку або доопрацювати план. Це ключовий інструмент для незнайомого коду і ризикованих змін — саме з plan mode починається правильний робочий цикл Explore → Plan → Code.

auto mode: класифікатор замість ваших підтверджень

auto — найсвіжіший і, мабуть, найцікавіший режим (на липень 2026 — research preview). Замість того щоб питати вас, він підключає окрему модель-класифікатор, яка перевіряє кожну дію перед виконанням і блокує потенційно небезпечні категорії: curl | bash, продакшн-деплої та міграції, масове видалення в хмарних сховищах, terraform/pulumi destroy тощо. Явно задані ask-правила при цьому все одно викликають запит.

У режиму є вбудований запобіжник: якщо класифікатор блокує дію 3 рази поспіль або 20 разів за сесію, auto призупиняється і повертаються звичайні підтвердження. У неінтерактивному режимі (-p) повторні блокування натомість переривають виконання — підтвердити ж нема кому.

Позиціонується auto саме як «середній шлях» між виснажливим Manual і безрозсудним YOLO: набагато менше запитів, але без повного вимкнення перевірок. Чесне застереження: research preview офіційно «не гарантує безпеку» — це зниження тертя, а не заміна ізоляції для по-справжньому недовірених задач.

YOLO: –dangerously-skip-permissions і чим він реально небезпечний

«YOLO-режим» — розмовна назва прапорця --dangerously-skip-permissions, технічно ідентичного режиму bypassPermissions. Він пропускає взагалі всі запити дозволів: лишаються тільки явні ask-правила і захисний запобіжник на rm -rf / та rm -rf ~. Спокуса зрозуміла — нуль підтверджень, агент летить. Ціна помилки — теж реальна.

Офіційна документація формулює прямо: bypassPermissions «не дає жодного захисту від prompt injection чи ненавмисних дій», і використовувати його слід виключно в ізольованих контейнерах або віртуальних машинах. Є і нюанс версій: починаючи з v2.1.126 у цьому режимі перестав діяти захист «захищених шляхів» (.git, .claude та ін.) — раніше запис у них потребував підтвердження навіть у bypass. Тобто в YOLO агент може непомітно переписати власний конфіг, git-хуки чи CI-скрипти.

І це не теорія. У грудні 2025 задокументовано реальний випадок: у YOLO-режимі Claude виконав команду на кшталт rm -rf tests/ patches/ plan/ ~/, де хвостове ~/ розгорнулося у весь домашній каталог користувача. Було видалено файли робочого столу, дані застосунків і вміст звʼязки ключів. Випадок активно обговорювався на Hacker News. Без sandbox чи контейнера ніщо не зупинило виконання — у цьому вся суть попередження про незворотність.

На Linux і macOS Claude Code взагалі відмовляється стартувати в bypassPermissions від імені root або через sudo — з міркувань безпеки. Перевірка знімається лише всередині розпізнаного sandbox.

Sandbox: це не режим, а окремий шар ізоляції

Тут головна концептуальна помилка новачків: sandbox плутають із ще одним «режимом». Це не так. Permission mode вирішує, чи потрібно спитати перед запуском. Sandbox вирішує, що вже запущена команда фізично дістане на диску і в мережі. Це два незалежні шари, і їх можна комбінувати — аж до sandbox поверх bypassPermissions.

Технічно вбудований sandboxed Bash tool ізолює bash-команди та їхні дочірні процеси: на macOS через Seatbelt (нічого ставити не треба), на Linux і WSL2 — через пакети bubblewrap і socat. Нативний Windows не підтримується — там потрібен WSL2. За офіційним анонсом Anthropic від 20 жовтня 2025, sandbox безпечно скорочує кількість permission-запитів на 84% завдяки звʼязці файлової ізоляції (доступ лише до певних директорій) і мережевої (підключення лише до схвалених серверів).

Два чесні застереження, про які варто знати:

• Sandbox покриває лише Bash. Вбудовані інструменти Read/Edit/WebFetch, MCP-сервери і хуки працюють напряму на хості й sandbox їх не захищає. Якщо потрібна повна ізоляція — загортайте весь процес у контейнер, VM або sandbox-runtime.
• Мережа за замовчуванням не інспектує TLS. Проксі вирішує лише за іменем хоста, тому широкий дозволений домен (наприклад, github.com) теоретично обхідний технікою domain fronting для ексфільтрації даних. Відповідальність за вузькість allowlist — на вас.

Три шари захисту: як це збирається разом

Щоб не заплутатися, тримайте в голові, що доступом керують три незалежні механізми, які доповнюють одне одного:

deny– і ask-правила діють завжди, навіть у bypassPermissions — тому заборона на git push чи git push --force й далі захищатиме вас у будь-якому режимі. Керування командами і налаштування правил — тема статті про слеш-команди Claude Code (/permissions, /config).

Правила дозволів на практиці

Правила задаються в settings.json трьома списками. allow — що дозволено без питання, ask — що завжди потребує підтвердження, deny — що заборонено взагалі. Саме deny — ваша страхувальна сітка навіть у найвільніших режимах. Мінімальний розумний набір для автономної роботи виглядає так: дозволити читання і тести, але жорстко заборонити незворотні операції.

Наприклад, deny-правило на git push, git push --force і rm -rf не дасть агенту випадково відправити напівсирий код у віддалений репозиторій або знести директорію, навіть якщо ви працюєте в acceptEdits чи bypassPermissions. Це дешевий захист, який спрацьовує раніше, ніж режим доступу встигає «пропустити» команду. Практика спільноти сходиться на одному: перед автономним прогоном завжди робіть git-коміт-чекпоінт і тримайте deny-список актуальним — тоді будь-який збій відкочується одним git reset, а не відновленням із бекапів.

Окремо варто памʼятати про робочі директорії: acceptEdits авто-схвалює файлові операції лише всередині робочої папки і явно доданих additionalDirectories. Усе за їхніми межами — за межами вашого проєкту — все одно потребує підтвердження, і це правильно: агент не має непомітно чіпати сусідні репозиторії чи системні файли.

Зведена таблиця режимів

Як обрати режим під задачу

Практичне дерево рішень, яке варто тримати в голові:

• Соло-розробка на своїй машині → acceptEdits або auto. Швидко, але із сіткою безпеки.
• Ревʼю чужого або неперевіреного коду → plan + sandbox. Спершу зрозуміти, що відбувається, і обмежити, що команда дістане.
• CI чи пайплайн без людини → dontAsk з явними allow-правилами: усе, що не дозволено, автоматично відхиляється.
• Повністю автономний прогін агента без нагляду → bypassPermissions, але лише всередині контейнера, VM або sandbox-runtime, з deny-правилами на небезпечні git-операції і git-комітом-чекпоінтом перед стартом.

Слабкі місця і підводні камені режимів

Чесний список ризиків, які варто тримати в голові:

• YOLO з v2.1.126 знімає захист навіть із .git/.claude — агент може переписати конфіги і хуки. Мітигація: deny-правила на git push/--force, окремий некореневий користувач, обовʼязковий контейнер.
• Реальна втрата даних можлива — задокументований кейс із rm -rf ~/ тому доказ. Тримайте git-чекпоінт і не запускайте YOLO поза ізоляцією.
• Sandbox захищає не все — MCP, хуки і не-Bash інструменти лишаються поза ним; хибне відчуття повної ізоляції небезпечне.
• Мережа sandbox не інспектує TLS — звужуйте allowlist доменів вручну.
• auto mode — research preview і «не гарантує безпеку»: не заміна контейнеру для недовірених задач.
• Поведінка залежить від версії. Імена та пороги (Manual з v2.1.200, protected paths з v2.1.126) змінюються — звіряйтеся з актуальною документацією на дату роботи.

FAQ

Як швидко перемкнути режим прямо в сесії? Клавішею Shift+Tab — вона циклічно перебирає Manual → acceptEdits → plan (і ввімкнені auto/bypassPermissions). Поточний режим видно в статус-барі внизу. Plan mode ще вмикається командою /plan.

Що таке YOLO-режим і коли його взагалі можна вмикати? YOLO — це прапорець --dangerously-skip-permissions (режим bypassPermissions), який знімає майже всі перевірки. Офіційно його припустимо використовувати лише в ізольованому контейнері, VM або sandbox без виходу в інтернет. На звичайній робочій машині це прямий ризик втрати даних.

Sandbox — це окремий режим доступу? Ні. Sandbox — незалежний шар ізоляції: він обмежує, що запущена bash-команда дістане на диску і в мережі, і комбінується з будь-яким режимом доступу. Режим вирішує «чи питати перед запуском», sandbox — «що команда зможе після запуску».

Чим auto mode відрізняється від YOLO? Auto перевіряє кожну дію окремим класифікатором і блокує небезпечне, тоді як YOLO дозволяє все без розбору. Auto — «середній шлях» із сіткою безпеки, але він у статусі research preview і не гарантує безпеку для недовірених задач.

Чи захищає sandbox від prompt injection повністю? Ні. Sandbox знижує шкоду від bash-команд, але не покриває MCP-сервери, хуки і не-Bash інструменти, а мережа за замовчуванням не інспектує TLS. Для по-справжньому недовірених задач потрібні контейнер або VM плюс вузький мережевий allowlist.