Агент, который правит файлы и запускает команды в вашей оболочке, — это одновременно ускорение работы и источник риска. Нужен способ задать границу: что он делает сам, а что только с вашего согласия. Именно это и решают режимы разрешений.

Выбор режима — рабочий инструмент, который меняется по нескольку раз за день: незнакомый legacy-код требует одной строгости, песочница — другой, продовый сервис — третьей. Не понимая этого, вы либо утонете в подтверждениях и начнёте нажимать «да» не читая, либо дадите слишком много свободы там, где не стоило.

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

Что уже умеем / что добавим

Вы уже провели сессию, увидели, как агент исследует код, и просили его «пока ничего не менять» обычными словами. Просьба — не гарантия: она влияет на намерения модели, но не на то, что разрешает инструмент. Перейдём от просьб к механизму, который действует независимо от диалога.

Что вы узнаете в рамках статьи

• Как устроена система разрешений и какие действия требуют подтверждения
• Все режимы: manual, acceptEdits, plan, auto, dontAsk, bypassPermissions
• Как переключать режим внутри сессии и задавать стартовый режим
• Чем правила allow, ask и deny отличаются и в каком порядке применяются
• Как выбрать режим под конкретную задачу

Ключевые термины

• Режим разрешений — набор правил, определяющий, какие действия агент выполняет без вопроса, а какие требуют подтверждения.
• Рабочая директория — папка запуска сессии; граница, внутри которой действуют послабления режимов.
• Правило разрешений — запись вида Инструмент(уточнение), разрешающая, запрещающая или требующая подтверждения для конкретных вызовов.
• Классификатор — отдельная модель, которая в режиме auto проверяет действия вместо вас.
• Read-only команды — встроенный набор безопасных команд оболочки (ls, cat, pwd, grep, git status), выполняемых без подтверждения в любом режиме.
• Защищённые пути — каталоги вроде .git и .claude, запись в которые почти нигде не одобряется автоматически.

Как устроена система разрешений

Основа проста: действия делятся по уровню риска. Чтение файлов внутри рабочей директории и встроенный набор read-only команд оболочки выполняются без вопросов. Правки файлов, произвольные команды оболочки и сетевые обращения требуют решения — а кто его принимает, определяет режим. В ручном режиме решаете вы, в auto за вас это делает классификатор, в остальных часть решений принята заранее.

Поверх режима работают правила разрешений — они задают исключения для конкретных инструментов и команд. Формат правила: Инструмент целиком или Инструмент(уточнение):

Bash(npm test)              # конкретная команда
Bash(npm run *)             # команды по шаблону
Read(~/secrets/**)          # чтение по пути
Edit(src/**)                # правка по пути
WebFetch(domain:example.com)  # обращение к домену

Правила бывают трёх видов: allow разрешает без подтверждения, ask заставляет спрашивать, deny запрещает. Порядок проверки строгий: deny, затем ask, затем allow — первое совпадение решает исход, и более точное правило не побеждает более общее. Практический вывод: широкое deny вроде Bash(aws *) заблокирует и то, что разрешено узким Bash(aws s3 ls). Исключений из запрета не бывает.

Посмотреть и отредактировать правила можно командой /permissions. Важно, что правила применяет сам Claude Code, а не модель: инструкции в вашем запросе влияют на то, что агент попытается сделать, но не на то, что ему позволено.

Шесть режимов и их назначение

Режимы отличаются тем, что выполняется без подтверждения.

• manual (в настройках default) — без вопроса только чтение и read-only команды, остальное спрашивает. Для чувствительной работы и незнакомого кода.
• acceptEdits — плюс правки файлов и распространённые файловые команды (mkdir, touch, rm, rmdir, mv, cp, sed) внутри рабочей директории; прочие команды спрашивают. Для итераций по коду, который вы потом смотрите через git diff.
• plan — агент исследует и предлагает план, но не правит исходники: правки заблокированы, пока план не утверждён. Для разбора кодовой базы перед изменениями.
• auto — работает всё, но действия оценивает классификатор. Для длинных задач и снижения усталости от подтверждений.
• dontAsk — выполняется только заранее разрешённое правилами, остальное отклоняется без вопросов. Для CI и ограниченных окружений.
• bypassPermissions — проверки пропускаются. Только для изолированных контейнеров и виртуальных машин.

На планах Pro, Max и Team интерактивные терминальные сессии стартуют в режиме auto, на остальных планах — в manual. Некоторых действий не одобряет автоматически ни один режим, включая bypassPermissions: например, удаление критических путей вроде rm -rf /.

Переключение и стартовый режим

Внутри сессии режим меняется горячей клавишей Shift+Tab. Из auto первое нажатие переводит в manual, дальше цикл идёт manual → acceptEdits → plan → и обратно в manual. Текущий режим виден в строке состояния подписями manual mode on, accept edits on, plan mode on, auto mode on. Режим dontAsk в цикле не появляется и задаётся только флагом запуска; bypassPermissions появляется, лишь если сессия запущена соответствующим образом.

Стартовый режим одной сессии задаётся флагом:

claude --permission-mode plan
claude --permission-mode acceptEdits

Постоянный стартовый режим задаётся в настройках: для всех сессий на машине — в ~/.claude/settings.json, для проекта — в его .claude/settings.json:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Отдельно об особенности plan-режима. Когда план готов, агент предлагает выбор: утвердить и продолжить в автоматическом режиме, утвердить с ручным подтверждением каждой правки, либо продолжить планирование. Утверждение выводит сессию из plan-режима, и агент начинает править код в выбранном режиме. Войти в plan-режим можно и на один запрос, начав его с /plan.

Как выбирать режим на практике

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

Незнакомый проект, чувствительный сервис, задача с неясными границами — manual или plan. Plan особенно хорош в начале работы: агент всё изучит и предложит план, а вы прочитаете его до того, как будет изменена хоть одна строка.

Задача понятна, код под контролем git, вы собираетесь смотреть diff — acceptEdits. Здесь важна дисциплина: режим экономит время именно потому, что вы проверяете результат после. Не будете проверять — экономии нет, есть только риск.

Длинная рутинная задача, где подтверждения превращаются в механические нажатия, — auto. Классификатор по умолчанию блокирует опасные категории: скачивание и выполнение кода вроде curl | bash, отправку чувствительных данных вовне, продовые деплои и миграции, force push, команды, отбрасывающие незакоммиченные изменения. Полезная деталь: границы, названные вами в разговоре, классификатор тоже учитывает — сказали «не пушь, пока я не проверю», и такие действия будут блокироваться, пока вы не снимете ограничение. Но эта граница живёт в переписке, а не в правилах, и может потеряться при сжатии контекста; для жёсткой гарантии нужно deny-правило.

Отдельно про bypassPermissions: это не «режим для опытных», а режим для изолированных сред. В контейнере, который не жалко потерять, он уместен; на рабочей машине с ключами и репозиториями — нет.

Частые ошибки

• Нажимать «да» не читая. Подтверждения работают, только пока вы их читаете. Если поток вопросов стал механическим, смените режим или добавьте allow-правила для рутинных команд.
• Ждать, что просьба в запросе что-то запретит. Фраза «ничего не удаляй» влияет на намерения модели, но не на разрешения. Гарантию даёт только deny-правило или режим.
• Пытаться сделать исключение из запрета. Порядок deny → ask → allow означает, что широкий deny перекрывает узкий allow. Нужны исключения — сужайте сам запрет.

• Использовать bypassPermissions на рабочей машине. Режим пропускает проверки, включая запись в защищённые пути вроде .git. Его место — изолированный контейнер.

Наиболее частые вопросы

• В каком режиме стартует сессия по умолчанию? — На Pro, Max и Team интерактивные терминальные сессии начинаются в auto, на остальных планах — в manual. Переопределяется настройкой defaultMode или флагом запуска.
• Чем acceptEdits отличается от auto? — acceptEdits разрешает только правки файлов и распространённые файловые команды в рабочей директории; остальные команды спрашивают. Auto разрешает почти всё, пропуская действия через классификатор.
• Работают ли правила deny в режиме auto? — Да, deny действует во всех режимах, включая bypassPermissions, где allow-правила, наоборот, смысла не имеют.
• Можно ли попросить агента сменить режим в чате? — Нет. Смена режима — действие пользователя: Shift+Tab, флаг запуска или настройка.
• Что происходит, когда классификатор в auto блокирует действие? — Действие не выполняется, агент получает причину и пробует другой путь. При повторяющихся блокировках auto приостанавливается и возвращаются обычные подтверждения.

Итоги

Вы разобрались с механизмом, который делает работу с агентом управляемой: знаете все шесть режимов и понимаете, чем они отличаются по сути, умеете переключаться на лету через Shift+Tab и закреплять стартовый режим в настройках, знаете формат правил и порядок их применения. Главное — появилась привычка сознательно выбирать строгость под задачу.

Но у режимов есть предел: они решают, что агенту позволено, а не откуда берутся его намерения. Если в прочитанном файле или на загруженной странице спрятана инструкция для модели, режим об этом не знает. Об этом — следующий урок: модель доверия и prompt injection.