1. Режим выбирают до первой просьбы
Проектные инструкции вы уже разобрали — теперь к следующему вопросу: что Claude разрешено делать именно в этой сессии. Permission mode выбирают до первой содержательной просьбы, а не после первого неожиданного diff. Это граница допустимого поведения Claude. Если Git baseline отвечает на вопрос «как откатить неудачную итерацию», то permission mode отвечает на вопрос «насколько далеко она вообще может зайти».
Три слоя, которые легко перепутать:
| Слой | На какой вопрос отвечает | Типичный пример |
|---|---|---|
| Git baseline | Как откатываться, если стало плохо? | clean working tree, branch, git diff |
| Permission mode | Что Claude может делать в этой сессии? | исследовать, предлагать, править, спрашивать |
| Prompt / task | Что вообще нужно сделать? | найти причину бага, подготовить план, внести фикс |
Перепутаете роли — хаос. Идеальная ветка и аккуратный prompt не спасут при слишком свободном режиме; строгий режим, наоборот, не даст наизменять пол-репозитория даже при расплывчатом prompt.
Отсюда привычка: сначала репозиторий и scope, потом режим доступа, и только потом — задача. Зашли исследовать refund-логику в режиме быстрых правок — уже подняли риск, не зная даже, в каком файле причина.
Safe Claude Code workflow = Git baseline + safe permissions + useful project instructions + memory hygiene + diff/tests/human review.
Середину выкинуть нельзя. Про Git помнят, про diff вспоминают в конце, а граница разрешений стоит ровно между ними.
2. Prompt не заменяет режим
Кажется, что фразой «исправь всё быстро и не задавай вопросов» можно поменять характер сессии. Не поменяете. Prompt описывает цель, permission mode — разрешённый диапазон действий. В режиме исследования «внеси изменения прямо сейчас» не сделает режим рабочим; при свободном старте «будь осторожен» не добавит ограничений.
Запуск на исследование в одной из версий:
# Точные имена флагов и режимов могут отличаться — сверяйтесь с `claude --help`
git switch -c investigate/refund-order
claude --permission-mode plan # режим исследования без правок
Исследуй, почему в inbox refund-запросы идут в неверном порядке.
Файлы пока не меняй.
Верни:
1. затронутые файлы,
2. гипотезу причины,
3. план проверки.
Claude читает и сопоставляет, но не превращает расследование в импровизированный commit.
Когда причина ясна и вы переходите к правке:
# Пример обычной рабочей сессии
git switch -c fix/refund-label
claude --permission-mode default # обычная работа с явными approvals
Исправь только сортировку refund-запросов в модуле inbox.
Публичный API не меняй.
Если потребуется выйти за `src/orders/refund/**`, сначала остановись и объясни зачем.
После правки покажи diff и какие проверки нужно запустить.
Осторожный prompt всё ещё нужен — но поверх границы, а не вместо неё. Уговаривать Claude текстом вместо настройки режима — как повесить на дверь серверной табличку «не входите» вместо замка.
3. Approval model: что можно, а что спрашивается
Режим понятнее не через названия, а через approval model — модель подтверждений. Часть действий Claude делает спокойно: читать файлы, искать по коду, смотреть логи. Часть проходит через ваш явный контроль: запись в файлы, команды с побочным эффектом, массовые правки. Разрушительные команды, чувствительные пути и обход ограничений не должны становиться рутиной вообще.
Approval — не надоедливое окно, а сигнал: цена ошибки выросла, следите внимательно. Лишнее подтверждение — секунды. Лишний git diff иногда стоит сорока минут и пары неловких объяснений на code review.
Approval работает в связке со scope: ограничили задачу одним модулем — изменение за его пределами сразу подозрительно. Scope не объявлен — система не заметит, что Claude «полез помочь чуть шире».
«Без подтверждений, правка же простая» — самообман. Claude работает по интерпретации задачи: поставите её широко — режим без пауз превратит «небольшой фикс» в квест «почему вместе с сортировкой поправился README, тесты и конфиг».
Поэтому вместо «не спрашивай лишнего» формулируйте так:
Плохо:
"Исправь всё быстро и не задавай вопросов"
Лучше:
"Сначала предложи план. Меняй только `src/orders/refund/**`.
Публичный API не трогай. Если нужен другой файл — сначала объясни почему.
После правки покажи diff."
Prompt задаёт рамку. Approval следит, чтобы за неё не вышли незаметно. Решение принимаете вы.
4. Четыре семейства режимов, а не таблица названий
Названия режимов плавают между версиями: default, plan, acceptEdits, что-то свободнее. Учить их наизусть хрупко — первая новая версия всё ломает. Надёжнее держать в голове четыре семейства поведения.
| Как о режиме лучше думать | Что он делает по смыслу | Где обычно уместен |
|---|---|---|
| Исследование / только чтение | Читает, ищет, анализирует, предлагает план | знакомство с кодом, поиск причины бага, вход в незнакомый модуль |
| Обычная работа с подтверждениями | Может готовить правки, но ждёт человека на чувствительных шагах | большинство нормальных задач разработки |
| Ускоренная локальная работа | Трения меньше, мелкие правки проходят быстрее | низкий риск, понятный scope, дешёвый rollback, временная branch |
| Очень свободный режим / отсутствие ограничений | Почти не тормозит Claude подтверждениями | только в sandbox или одноразовой среде, для очень узкого и безопасного эксперимента |
Так проще: важно не название кнопки, а кто вам сейчас нужен — исследователь, аккуратный исполнитель или почти автономный механик.
Свободные режимы кажутся привлекательнее, когда вы устали, — и тогда опаснее всего. «Не спрашивай ничего» — короткая дорога к долгому вечеру с git restore.
Чем хуже понимаете задачу, чем чувствительнее зона и чем дороже откат — тем консервативнее режим. Не наоборот.
5. Commerce OS: четыре разные задачи
Снаружи все четыре похожи на «пора поработать с кодом», внутри требуют разной свободы.
Первая — расследование бага в порядке refund-запросов. Причина неизвестна: сортировка, SQL, DTO или временная зона. Свободный режим только повышает риск, что Claude начнёт править до доказательства причины. Нужен режим исследования.
Вторая — небольшая правка в pet-проекте или низкорисковой части Commerce OS: подпись поля, один метод отображения. Обычный режим с подтверждениями — хороший default.
Третья — механическая серия однотипных правок в тестах в отдельной ветке, откат одним действием. Ускоренный режим оправдан, но только при трёх условиях разом: зона низкорисковая, scope узкий, откат дешёвый и очевидный.
Четвёртая — чувствительная зона: auth, payment, конфигурация, миграции, расчёт денег. Ветка удешевляет откат, но не делает дешёвой смысловую ошибку. Если Claude «полезно» изменит контракт, расчёт комиссии или сценарий авторизации, вред определяется не скоростью отката, а тем, насколько легко вы это заметите. Значит: сначала исследование и план, потом очень аккуратные правки под явным контролем.
Практическое разделение:
# Сначала понять проблему
git switch -c investigate/refund-order
claude --permission-mode plan # exact name may change
# Потом внести небольшой подтверждённый фикс
git switch -c fix/refund-order
claude --permission-mode default # обычный режим с approvals
Одна задача — две сессии с разной permission posture. Не паранойя, а экономия внимания.
6. Сделайте выбор режима наблюдаемым
В любой момент вы должны уметь ответить себе на «в каком режиме я работаю?» и «почему именно в нём?». Ответ «ну, что-то обычное» — повод привести сессию в порядок.
Старт короткий: проверили репозиторий, сформулировали scope, запустили Claude с нужным режимом, и только потом дали задачу. Для исследования:
Исследуй модуль refund.
Найди, где формируется порядок элементов в inbox.
Файлы не меняй.
Верни только:
- релевантные файлы,
- гипотезу причины,
- план проверки.
Такой prompt поддерживает режим, а не спорит с ним: вы не просите «исправить заодно».
Не уверены в текущем режиме посреди сессии — не угадывайте по поведению модели. Откройте /help, найдите команду, которая в вашей версии показывает разрешения, и проверьте напрямую. Названия меняются, идея — нет.
Менять режим посреди сессии нормально, но причина должна быть инженерной. Доказали причину и переходите к узкому низкорисковому фиксу — понятно. Просто устали от подтверждений — предвестник странного diff.
7. Консервативный выбор дешевле свободного
Асимметрия: избыточная строгость раздражает, а избыточная свобода сначала приятно ускоряет, потом дорого обходится. Поэтому консервативный выбор — не трусость, а зрелость.
Тест прост: не можете назвать файлы под изменение, откат неочевиден или зона чувствительна — свободу давать рано. На Commerce OS особенно: рядом с прикладной логикой лежат деньги, интеграции и сценарии, которые ломаются тише, чем хотелось бы.
Отсюда рабочий default. Исследование — чтение и план. Обычные правки — явные approvals. Свободная автоматизация — только низкий риск, узкий scope, дешёвый откат. Обходные режимы — только одноразовая песочница, которую готовы выбросить. Коротко: сомневаетесь — выбирайте строже.
Правильно выставленная граница не мешает продуктивности, а держит её: меньше споров с Claude, меньше разгребания неожиданных изменений, яснее понимание, что вы делаете. Тогда scope, project instructions и diff review работают как инженерная система, а не декоративные слова.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ