Claude Code permissions: настраиваем разрешения для одного репозитория

Настройте Claude Code на трёх учебных файлах: один можно менять сразу, второй — после подтверждения, третий — запрещено. Проверим реальные вызовы инструментов и содержимое файлов. Это поможет понять разрешения до работы с важным проектом.

Отделите просьбу от разрешения

Фраза «не трогайте конфигурацию» помогает объяснить задачу агенту. Но разрешения проверяет сама программа Claude Code перед вызовом инструмента. Для такой проверки нужны правила allow, ask и deny.

По официальному справочнику, порядок проверки такой: сначала deny, затем ask, затем allow. Более узкое разрешающее правило не отменяет совпавший запрет. Правило ask также требует подтверждения, даже если действие есть в allow.

Для упражнения подходит обычная CLI-сессия. Расширения, которые переопределяют решения разрешений (mods), изменят условия опыта; их поведение отдельно описано в документации. Сам тест ограничен встроенным инструментом правки файла.

Понадобятся установленный Claude Code, рабочая сессия, редактор и настроенный Git. Установку проверьте по официальному руководству. Формулировки задач можно освежить в статье о промптах для фронтендеров, но правила доступа сохраняются в конфигурации.

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

Подготовьте три файла с одинаковым содержимым

Создайте отдельную папку claude-permission-demo. Начните репозиторий:

git init

В редакторе создайте allowed.txt, ask.txt и blocked.txt. В каждый поместите:

Учебная заметка
Статус: исходный

Также создайте .gitignore:

.claude/settings.local.json

Сохраните начальную точку:

git add allowed.txt ask.txt blocked.txt .gitignore
git commit -m "Add permission demo"

Перед продолжением выполните git status --short: изменений быть не должно. Этот коммит сохраняет заметки на вашей машине. Позже Git покажет, какие строки действительно изменились.

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

Выберите файл настроек для одного проекта

Создайте .claude/settings.local.json в корне учебной папки. Это личная конфигурация текущего проекта. Общая командная конфигурация хранится в .claude/settings.json, а пользовательская для разных проектов — в ~/.claude/settings.json.

Если Claude Code сам создаёт локальный файл, он заботится о его исключении из Git. Мы создали файл вручную, поэтому уже добавили строку в .gitignore. Расположения и области действия описаны в руководстве по настройкам.

Сохраните JSON:

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Edit(/allowed.txt)",
      "Edit(/ask.txt)",
      "Edit(/blocked.txt)"
    ],
    "ask": [
      "Edit(/ask.txt)"
    ],
    "deny": [
      "Edit(/blocked.txt)"
    ]
  }
}

Все три файла есть в allow намеренно. Два из них одновременно попадают в другие списки. Для ask.txt выигрывает подтверждение, для blocked.txt — запрет. Поэтому порядок строк внутри allow не меняет результат.

defaultMode: "default" выбирает ручной режим, который интерфейс называет Manual. Название и поведение режима приведены в справочнике permissions. Он подходит для наблюдения за запросами. Если режим сессии другой, сравнение с нашей таблицей будет неполным.

Скобки указывают, к какому пути относится правило. Edit используется для проверки правки встроенными файловыми инструментами. По текущей документации путь вида Write(путь) не заменяет Edit(путь): такая запись не используется для проверки файловых путей.

Проверьте, как читается путь

В нашем локальном файле настроек /allowed.txt относится к allowed.txt в основной рабочей папке сессии. Начальный одинарный слеш здесь не означает корень диска. Мы запускаем агент из корня учебного репозитория, поэтому нужный файл лежит рядом.

Разница путей разобрана в официальном справочнике файловых правил:

Начало пути	Откуда считается путь
/path	От области источника настроек; в нашем проектном локальном файле — от основной рабочей папки
./path	От текущей папки
~/path	От домашней папки пользователя
//path	Абсолютный путь от корня файловой системы

Расположение правила важно. Такой же /path в пользовательских настройках имеет другую привязку. Поэтому не переносите пример в глобальный файл, рассчитывая автоматически получить ограничения для любого репозитория.

Для первого опыта достаточно трёх точных имён. Шаблоны с ** удобны для больших папок, но их границы тоже нужно проверять. Увеличивайте область правила после того, как проверили конкретный файл.

Посмотрите действующие правила перед правкой

Запустите claude из корня claude-permission-demo. После запроса доверия папке откройте /permissions. Найдите все пять записей из JSON: три разрешения, одно подтверждение и один запрет. Диалог показывает источник каждого правила.

Проверьте, что режим сессии — Manual. Если вы продолжаете прежнюю сессию, начните новую после создания конфигурации: так в упражнении будет понятная исходная точка. Просмотрите также личные и управляемые правила, которые могли добавиться к проектным.

Настройки действуют слоями. Для обычного одиночного значения локальный проектный файл выше общего проектного и пользовательского. Но списки разрешений объединяются. Локальный allow не стирает deny из другого источника. Это объяснено в разделе о приоритете настроек.

Если организационная политика ограничивает доступ, не пытайтесь обходить её новым файлом. Запишите источник правила и учитывайте его в результате. Чтобы понять отклонение, сначала нужно знать, какая конфигурация сработала.

Выполните разрешённую правку

Отправьте:

Прочитайте allowed.txt.
Через встроенный инструмент Edit замените
«Статус: исходный» на «Статус: проверен».
Меняйте только эту строку.
Не используйте команды оболочки, MCP или другие обходные пути.

В обычной сессии с указанными правилами правка должна пройти без отдельного подтверждения: совпадает allow, а соответствующих ask и deny нет.

Посмотрите журнал. В нём нужен вызов встроенной правки нужного файла. Затем откройте allowed.txt в редакторе: статус должен измениться, первая строка — сохраниться.

Чтение перед правкой — отдельное действие. По наличию или отсутствию вопроса при чтении нельзя судить о правиле Edit.

Проверьте действие с подтверждением

Повторите тот же запрос для ask.txt. Попросите такую же замену через встроенный Edit и сохраните ограничение на другие инструменты.

Перед правкой должен появиться запрос подтверждения. В нём сверьте путь и заменяемый текст, затем одобрите только это действие. Выберите разовое подтверждение: так при повторной проверке снова будет видно действие правила ask.

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

Само сообщение агента «сейчас попрошу разрешение» не доказывает работу правила. Доказательство — диалог Claude Code и правка после вашего решения.

Проверьте запрет

Теперь запросите ту же замену в blocked.txt, опять через встроенный Edit. Несмотря на запись в allow, совпавший deny должен остановить это действие.

Агент может заранее увидеть ограничение и отказаться от правки. Тогда журнал подтвердит, что запрет прочитан, но самого отклонённого вызова может не быть. Не просите найти способ обойти правило ради демонстрации. Зафиксируйте, что файл сохранился и агент назвал действующий запрет; при отсутствии попытки вызова отметьте эту границу наблюдения.

Проверьте итог:

git diff -- allowed.txt ask.txt blocked.txt

Файл	Ожидаемый статус при одобрении второго действия
allowed.txt	проверен, отдельного подтверждения правки не было
ask.txt	проверен, пользователь подтвердил конкретную правку
blocked.txt	исходный, правка не выполнена

Эти вызовы Claude Code в материале не выполнялись. Таблица задаёт критерии вашего упражнения и не изображает полученный журнал.

Разберитесь с неожиданным результатом

Когда разрешённая правка всё же спрашивает подтверждение, найдите совпавшее ask или deny в /permissions. Затем проверьте путь и режим. Если правило не видно, откройте /status и выполните claude doctor вне сессии: диагностика помогает найти непрочитанный или неверный JSON.

При правке другого файла остановите работу и прочитайте точный путь в вызове. Переход в подпапку может изменить смысл относительного пути. В этом упражнении оставайтесь в корне репозитория.

Команда оболочки вместо Edit меняет условия опыта: заданные три вызова ещё не проверены. Верните его к выбранному инструменту. Не добавляйте широкое разрешение на все команды ради устранения вопросов.

Разрешения и песочница дополняют друг друга

Файловые правила проверяются перед вызовом инструмента. Они действуют для встроенных операций и распознаваемых команд. Но у отдельного Python- или Node-процесса может быть другой путь к файлу: такие правила не заменяют изоляцию процесса.

Песочница ограничивает доступ выполняющейся команды средствами операционной системы. В актуальной документации она охватывает команды Bash, PowerShell и Monitor на поддерживаемых платформах. Файловые инструменты, MCP-серверы и hooks находятся вне этой встроенной границы.

На macOS, Linux и WSL 2 песочница поддерживается; на Native Windows команды выполняются без неё. Для Windows-сценария с песочницей нужна WSL 2. Настройка разрешений сама по себе не добавляет эту изоляцию.

В упражнении нет причины выключать защиту или переходить в режим пропуска разрешений. Три точных правила дают достаточно информации, чтобы понять решение программы.

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