SpyBara
Go Premium

permissions.md 2026-10-09 23:02 UTC to 2026-10-10 21:01 UTC

This page contains 174 additions and 143 deletions.

2026
Thu 1 23:59 Fri 2 22:59 Tue 6 23:59 Thu 8 22:58 Sat 10 22:01

Настройка разрешений

Контролируйте, что Claude Code может использовать и делать, с помощью детальных правил разрешений, режимов и управляемых политик.

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

Система разрешений

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

Тип инструмента Пример Требуется одобрение Поведение "Да, не спрашивать снова"
Только чтение Чтение файлов, Grep Нет, в пределах рабочего каталога и дополнительных каталогов Н/А
Bash команды Выполнение оболочки Да, кроме встроенного набора команд только для чтения Постоянно для каждого репозитория и команды
Изменение файлов Edit/Write файлы Да До конца сеанса
Веб-выборка WebFetch Да, кроме встроенного набора предварительно одобренных доменов документации Постоянно для каждого репозитория и домена
Веб-поиск WebSearch Да Постоянно для каждого репозитория

Запрос разрешения показывает, что Claude собирается сделать, а затем варианты ответа. Этот пример — запрос для команды Bash из сессии в режиме Manual:

Запрос разрешения Claude Code с заголовком Bash command. Под подсказкой об авторежиме показаны описание 'Run the test suite', команда npm test и строка 'This command requires approval', затем вопрос 'Do you want to proceed?' с четырьмя вариантами: Yes; Yes, and don't ask again for: npm test *; Yes, and switch to auto mode; и No. В нижней строке указаны две клавиши: Esc для отмены и Tab для изменения. Запрос разрешения Claude Code с заголовком Bash command. Под подсказкой об авторежиме показаны описание 'Run the test suite', команда npm test и строка 'This command requires approval', затем вопрос 'Do you want to proceed?' с четырьмя вариантами: Yes; Yes, and don't ask again for: npm test *; Yes, and switch to auto mode; и No. В нижней строке указаны две клавиши: Esc для отмены и Tab для изменения.

Третий вариант, Yes, and switch to auto mode, появляется не в каждом запросе.

Когда вы выбираете "Да, не спрашивать снова" и одобрение сохраняется постоянно, например для команды Bash или домена WebFetch, Claude Code сохраняет правило в .claude/settings.local.json в корне git репозитория, разрешённого через worktrees к основной копии. Правило применяется к будущим сеансам в любом месте этого репозитория, включая сеансы, запущенные в подкаталогах и в worktrees. Одобрение изменения файла не сохраняется в файл: как показано в таблице, оно действует до конца сеанса. В некоторых случаях, например вне git репозитория или на Windows, Claude Code не использует корень репозитория; Где Claude Code ищет каждый файл перечисляет эти случаи и где вместо этого сохраняется правило.

До версии 2.1.211 Claude Code всегда сохранял правило в начальном каталоге, поэтому одобрение, предоставленное в worktree или подкаталоге, не применялось к остальной части репозитория. Правила, которые более ранние версии сохранили в подкаталоге или worktree, по-прежнему применяются к сеансам, запущенным там.

Иногда запрос разрешения предлагает только одноразовое одобрение, без опции "не спрашивать снова" и без опции разрешить действие на остаток сеанса. Claude Code предлагает эти опции только когда запрос может показать вам всё, что они позволили бы, поэтому правило, которое вы сохраняете из запроса, охватывает только то, что названо его опцией. Когда запрос предлагает только одноразовое одобрение, одобрите действие один раз или добавьте правило самостоятельно в /permissions. Чтобы запросы перестали появляться для команды, которая начинается с exec-обёртки, например watch, или для команды find с действием, например -delete, см. Exec-обёртки и действия find.

Добавьте комментарий при ответе на запрос разрешения

Вы можете прикрепить заметку к Claude при одобрении или отклонении одного действия. На большинстве запросов разрешений, включая Bash, PowerShell, файл и запросы инструментов MCP, перейдите на Yes или No и нажмите Tab для открытия поля комментария на этой опции. Запросы WebFetch и браузера не предлагают это поле. Опции, которые разрешают действие на остаток сеанса или сохраняют правило, также не принимают его.

С открытым полем введите комментарий и затем нажмите одну из этих клавиш:

  • Enter: отправляет ваш ответ с прикреплённым комментарием. Если вы оставите поле пустым, Claude Code отправляет ответ без комментария.
  • Tab: закрывает поле без ответа. Claude Code сохраняет введённый вами текст и всё ещё отправляет его, если вы ответите с этой опцией.
  • Shift+Tab: на запросе файла, например запросе Edit или Write, закрывает поле так же, как Tab. До версии 2.1.235 нажатие Shift+Tab внутри поля вместо этого выбирало опцию, которая разрешает действие на остаток сеанса, поэтому Claude Code одобрял действие на остаток сеанса и отбрасывал комментарий.

Claude Code доставляет комментарий по-разному в зависимости от того, как вы ответили:

  • Yes: Claude Code выполняет действие, затем отправляет ваш комментарий Claude после результата.
  • No: Claude Code отправляет ваш комментарий Claude как причину отклонения, и Claude продолжает работу. Если вы выберете No без комментария на запрос из основного разговора, Claude Code останавливает ход.

Управление разрешениями

Вы можете просматривать и управлять разрешениями инструментов Claude Code с помощью /permissions. Этот интерфейс отображает все правила разрешений и файлы settings.json, из которых они берутся. Вы можете открыть этот интерфейс во время работы Claude: когда вы добавляете или удаляете правило, Claude Code применяет изменение начиная со следующего вызова инструмента Claude в том же ходу. До версии 2.1.234 Claude Code ставил команду в очередь до завершения хода.

  • Правила Allow позволяют Claude Code использовать указанный инструмент без ручного одобрения.
  • Правила Ask запрашивают подтверждение каждый раз, когда Claude Code пытается использовать указанный инструмент.
  • Правила Deny предотвращают использование Claude Code указанного инструмента.

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

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

Правила Deny ведут себя по-разному в зависимости от того, называют ли они инструмент или определяют область действия шаблона внутри него. Простое имя инструмента, такое как Bash, удаляет инструмент из контекста Claude полностью, поэтому Claude его никогда не видит. Если вы добавите такое правило во время сеанса, Claude не сможет вызвать инструмент со своего следующего вызова инструмента; Отказ от целого инструмента описывает, что происходит с определением, которое Claude уже видел. Правило с областью действия, такое как Bash(rm *), оставляет инструмент доступным и блокирует совпадающие вызовы, когда Claude пытается их выполнить.

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

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

Режимы разрешений

Claude Code поддерживает несколько режимов разрешений, которые контролируют, как он одобряет вызовы инструментов. См. Permission modes для определения того, когда использовать каждый из них. Чтобы изменить режим, в котором начинаются сеансы, установите defaultMode в ваших файлах параметров. Which mode a session starts in охватывает встроенное значение по умолчанию для каждого плана и то, что читает расширение VS Code.

Режим Описание
default Запрашивает разрешение при первом использовании каждого инструмента. Обозначается как Manual в CLI, расширениях VS Code и JetBrains, а также в приложении для рабочего стола, и Claude Code принимает manual как псевдоним
acceptEdits Автоматически принимает редактирование файлов и общие команды файловой системы, такие как mkdir, touch, mv и cp для путей в рабочем каталоге или additionalDirectories
plan Claude читает файлы и запускает команды оболочки только для чтения для исследования, но не редактирует ваши исходные файлы; с доступным режимом auto также запускаются одобренные классификатором команды. Обозначается как Plan в CLI и расширении VS Code
auto Работает без обычных запросов; перед выполнением действий, таких как команды оболочки и сетевые запросы, фоновый классификатор проверяет, что они соответствуют вашему запросу
dontAsk Автоматически отклоняет каждый вызов, который иначе запросил бы подтверждение; чтение файлов в ваших рабочих каталогах и другие действия, которые не требуют подтверждения, по-прежнему выполняются, как и инструменты, предварительно одобренные через /permissions или правила permissions.allow. AskUserQuestion, инструменты MCP, отмеченные requiresUserInteraction, чтение из сетевых путей и инструменты коннекторов, для которых ваша организация установила ask, в сессиях, где эта настройка достигает Claude Code, отклоняются, даже если вы их разрешили
bypassPermissions Пропускает запросы разрешений, за исключением действий, которые ни один режим не одобряет автоматически

Чтобы предотвратить использование режима bypassPermissions или auto, установите permissions.disableBypassPermissionsMode или permissions.disableAutoMode на "disable" в любом файле параметров. Это наиболее полезно в управляемых параметрах, где они не могут быть переопределены.

Синтаксис правил разрешений

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

Совпадение всех использований инструмента

Чтобы совпадать со всеми использованиями инструмента, используйте только имя инструмента без скобок:

Правило Эффект
Bash Совпадает со всеми Bash командами
WebFetch Совпадает со всеми запросами веб-выборки
Read Совпадает со всеми чтениями файлов

Bash(*) эквивалентен Bash и совпадает со всеми Bash командами. Как правило отказа, обе формы удаляют инструмент из контекста Claude.

Используйте спецификаторы для детального контроля

Добавьте спецификатор в скобках, чтобы совпадать с конкретными использованиями инструмента:

Правило Эффект
Bash(npm run build) Совпадает с точной командой npm run build
Read(./.env) Совпадает с чтением файла .env в текущем каталоге
WebFetch(domain:example.com) Совпадает с запросами выборки на example.com

Совпадение по входному параметру

Правила отказа и запроса могут совпадать с параметром верхнего уровня на любом встроенном инструменте с помощью Tool(param:value).

Чтобы совпадать с параметром на инструменте MCP, передайте правило отказа с --disallowedTools. Когда Claude Code загружает файл параметров, он пропускает любое правило mcp__, которое содержит скобки. Claude Code перечисляет пропущенное правило в диалоге invalid-settings при запуске интерактивного сеанса и в выводе claude doctor.

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

Правило Совпадает
Agent(model:opus) Вызовы Agent, которые запрашивают уровень модели Opus
Agent(isolation:worktree) Вызовы Agent, которые запрашивают git worktree
Bash(run_in_background:true) Вызовы Bash, которые выполняются в фоновом режиме

Совпадение параметров следует этим правилам:

  • Имя параметра должно быть прямым полем входа инструмента, таким как model на инструменте Agent. Поля, вложенные внутри объекта или массива, не совпадают
  • Каждое правило называет один параметр. Чтобы ограничить как model, так и isolation, напишите два правила, Agent(model:opus) и Agent(isolation:worktree), вместо того чтобы объединять их в одно правило
  • Значение поддерживает * как подстановочный символ, который совпадает с любой последовательностью символов, поэтому Agent(isolation:*) совпадает с любым явным значением изоляции. Без * совпадение точное
  • Параметр, который модель опускает, никогда не совпадает, поэтому Agent(model:*) не совпадает с вызовом, который оставляет model неустановленным
  • Значение сравнивается с буквальным входом, который отправляет Claude, до любой нормализации. Agent(model:opus) совпадает с псевдонимом opus, но не с полным ID модели
  • Правило отказа Skill(skill:<name>) вместо этого совпадает с навыком под любым из его имён, таким как его псевдоним или отображаемое имя
  • Запустите с --verbose, чтобы увидеть точные имена параметров и значения в каждом вызове инструмента
  • Пробелы вокруг двоеточия игнорируются

Вы не можете совпадать с основным полем содержимого инструмента таким образом: command для Bash и PowerShell, file_path для Read, Edit и Write, path для Grep и Glob, notebook_path для NotebookEdit и url для WebFetch. Правило, такое как Bash(command:rm *), можно было бы обойти составной командой, поэтому Claude Code игнорирует его и выдает предупреждение при запуске. Используйте Bash(rm *), Read(./path) или WebFetch(domain:host) вместо этого.

Шаблоны подстановочных символов

* в правиле Bash совпадает с любым текстом, включая пробелы, поэтому одно правило охватывает семейство команд. Правило без * совпадает с одной точной командой.

Напишите команду, которую вы хотите, чтобы Claude выполнил без запроса, и замените части, которые варьируются, на *. С этой конфигурацией Claude Code запускает npm скрипты и git коммиты без запроса и отказывает в командах, которые начинаются с git push. Push, написанный другим способом, такой как git -C . push, не совпадает; см. что правило Bash не совпадает.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

* может находиться в любом месте правила: в начале, в середине или в конце. Каждая строка показывает правило, команды, которые оно совпадает, и близлежащие команды, которые оно не совпадает:

Вы пишете Совпадает Не совпадает
Bash(npm run build) npm run build npm run build --watch
Bash(npm run *) npm run build, npm run test --watch, npm run npm install
Bash(git log * main) git log --oneline main, git log -5 main, git log --output=<file> main git log main, git push origin main
Bash(git * main) git merge main, git push origin main, git -c core.fsmonitor=<script> diff main git log
Bash(* --version) node --version, bash -c 'echo hi' --version node -v
Bash(ls *) ls -la, ls lsof
Bash(ls*) ls -la, lsof
Bash(* --help *) npm --help x npm --help

Три правила совпадения производят эти строки:

  • * стоит вместо того, какой текст находится на его месте. В Bash(git * main), он стоит вместо подкоманды, поэтому Claude Code совпадает с каждой подкомандой git и каждой опцией перед ней. Это включает -c, что заставляет git запустить программу, которую вы называете. В Bash(* --version), * стоит вместо программы, поэтому совпадает любая программа.
  • * в конце, с пробелом перед ним, также совпадает с голой командой. Bash(ls *) совпадает с ls, и Bash(git log *) совпадает с git log. Это верно только когда завершающий * — единственный подстановочный символ правила: Bash(* --help *) совпадает с npm --help x, но не с npm --help.
  • Пробел перед завершающим * является частью правила. Bash(ls *) требует пробел после ls, поэтому lsof не совпадает. Bash(ls*) не имеет пробела, поэтому он совпадает с lsof тоже.

Суффикс :* — это эквивалентный способ написания завершающего подстановочного символа, поэтому Bash(ls:*) совпадает с теми же командами, что и Bash(ls *).

Диалог разрешений записывает форму, разделенную пробелами, когда вы выбираете "Да, не спрашивать снова" для префикса команды. Форма :* распознается только в конце шаблона. В шаблоне, таком как Bash(git:* push), двоеточие рассматривается как буквальный символ и не будет совпадать с git командами.

Подстановочные символы имён инструментов

Правила отказа и запроса также принимают glob-шаблоны в позиции имени инструмента. Шаблон должен совпадать с полным именем инструмента: "*" совпадает с каждым инструментом, и "mcp__*" совпадает с каждым MCP инструментом на всех серверах. Инструмент, совпадающий с правилом отказа с простым именем glob, удаляется из контекста Claude, так же как и простое имя инструмента, включая исключение EndConversation: glob отказ не может удалить его, пока остается любой другой инструмент, и glob запрос никогда не запрашивает его. Эта конфигурация отрицает каждый MCP инструмент:

{
  "permissions": {
    "deny": [
      "mcp__*"
    ]
  }
}

Правила разрешения принимают glob-шаблоны имён инструментов только после буквального префикса mcp__<server>__. Сегмент сервера должен быть свободен от glob, поэтому правило называет конкретный сервер, который вы настроили. mcp__puppeteer__* совпадает с каждым инструментом с сервера puppeteer, и mcp__github__get_* совпадает с его инструментами get_. Неякорированный glob разрешения, такой как "*", "B*" или "mcp__*", пропускается с предупреждением и не одобряет ничего автоматически.

Правило отказа или запроса, имя инструмента которого не совпадает ни с одним известным инструментом, выдает предупреждение при запуске, чтобы поймать опечатки. Имена инструментов, содержащие _ или *, освобождаются от проверки, и так же как и имена инструментов, которые Claude Code удалил, такие как TaskOutput.

Метка, отображаемая для инструмента в стенограмме и диалоге разрешений, может отличаться от его канонического имени. Например, инструмент с меткой Stop Task в стенограмме имеет каноническое имя TaskStop. Правила разрешений и матчеры hook не совпадают с меткой, поэтому правило, написанное как Stop Task, не совпадает. Для правил отказа и запроса предупреждение при запуске выше ловит несоответствие. Используйте канонические имена, указанные в справочнике инструментов.

Правила разрешений для отдельных инструментов

Bash

Правила Bash сопоставляются со всем текстом команды, где * заменяет любой текст. В разделе Шаблоны с подстановочными знаками показано, какие команды соответствуют каждой форме правила и где ставить *. В остальной части этого раздела описано, как Claude Code сопоставляет составные команды и обёртки, какие обёртки и действия find не может одобрить правило-префикс, чему правило не соответствует, а также команды только для чтения и перенаправления.

Составные команды

Правила deny и ask применяются, когда им соответствует любая подкоманда, включая команду, вложенную в подоболочку, подстановку команды или тело управляющей конструкции, например цикла for. Правило ask вида Bash(git clean *) по-прежнему запрашивает у вас подтверждение для cd /tmp && git clean -f или echo "$(git clean -f)", даже в авторежиме.

Когда после && или || ничего нет, как в npm test &&, Claude Code считает команду неразбираемой и не разделяет её на подкоманды для сопоставления с правилами allow, поэтому правило вида Bash(npm *) её не одобряет.

Когда вы одобряете составную команду с помощью «Yes, and don't ask again», Claude Code сохраняет отдельное правило для каждой подкоманды, требующей подтверждения, а не одно правило для всей составной строки. Например, одобрение git status && npm test сохраняет правило для npm test, поэтому будущие вызовы npm test распознаются независимо от того, что стоит перед &&. Подкоманды вроде cd в каталог за пределами ваших рабочих каталогов создают собственное правило Read для этого пути. Для одной составной команды может быть сохранено до 5 правил.

Обёртки

Перед сопоставлением с правилами Bash Claude Code отбрасывает фиксированный набор обёрток, поэтому правило вида Bash(npm test *) также соответствует timeout 30 npm test. Отбрасываемые обёртки: timeout, time, nice, nohup и stdbuf, а также встроенные команды оболочки command и builtin и noglob из zsh. Каждая из них выполняет свой аргумент как фактическую команду. Две родственные формы не отбрасываются: форма запроса command -v, которая ищет команду, а не выполняет её, и nocorrect из zsh.

Claude Code также отбрасывает начальное присваивание некоторых заведомо безопасных переменных окружения, поэтому Bash(npm test *) соответствует NODE_ENV=test npm test. Правило allow не сопоставляется через присваивание любой другой переменной. Правило deny или ask сопоставляется через любое начальное присваивание, поэтому Bash(rm *) в deny по-прежнему соответствует FOO=bar rm -rf tmp/.

Простой xargs тоже отбрасывается, поэтому Bash(grep *) соответствует xargs grep pattern. Отбрасывание применяется только тогда, когда у xargs нет флагов: вызов вида xargs -n1 grep pattern сопоставляется как команда xargs, поэтому правила, написанные для внутренней команды, его не покрывают.

Этот список обёрток встроен и не настраивается. Средства запуска сред разработки, такие как direnv exec, devbox run, mise exec, npx и docker exec, в список не входят. Поскольку эти инструменты выполняют свои аргументы как команду, правило вида Bash(devbox run *) соответствует всему, что идёт после run, включая devbox run rm -rf .. Чтобы одобрить работу внутри средства запуска среды, напишите конкретное правило, включающее и средство запуска, и внутреннюю команду, например Bash(devbox run npm test). Добавьте по одному правилу на каждую внутреннюю команду, которую хотите разрешить.

Exec-обёртки и действия `find`

Правило-префикс вида Bash(watch *) или Bash(find *) не может автоматически одобрить следующие команды, поэтому в ручном режиме они запрашивают подтверждение:

  • Exec-обёртки: например watch, setsid, ionice и flock
  • find: с действием, которое выполняет команды, удаляет файлы или записывает файлы, например -exec, -delete или -fprint, либо с -files0-from, который берёт пути для поиска из файла

Чтобы одобрить конкретный вызов без *, напишите правило точного соответствия для всей строки команды, например Bash(find build -type f -delete).

Когда в команде есть *, как в find . -name '*.tmp' -delete, Claude Code читает правило как шаблон с подстановочными знаками, а не как точное соответствие, поэтому команда по-прежнему запрашивает подтверждение. Одобряйте её каждый раз при запросе или используйте хук PreToolUse, который возвращает для неё "allow".

Чему не соответствует правило Bash

Правило Bash сопоставляется с текстом команды, который пишет Claude, после того как Claude Code разделит составные команды и отбросит обёртки. Оно не соответствует той же программе, вызванной в другой форме, поэтому правило deny или ask покрывает вызов, который обычно создаёт Claude, и не является границей безопасности вокруг программы. Эти правила в deny или ask останавливают первую форму, но не остальные:

Правило Останавливает Не останавливает
Bash(curl *) curl https://example.com /usr/bin/curl https://example.com, sh -c 'curl https://example.com'
Bash(rm *) rm -rf build/ /bin/rm -rf build/, bash -c 'rm -rf build/'
Bash(git push *) git push origin main git -C . push origin main, git -c push.default=current push origin main, git 'push' origin main

Судьбу команд из последнего столбца решают ваши остальные правила и режим разрешений.

Для ограничений файловой системы и сети, не зависящих от текста команды, используйте изоляцию в песочнице. Чтобы проверять полный текст команды собственной логикой перед её выполнением, используйте хук PreToolUse.

Команды только для чтения

Claude Code распознаёт встроенный набор команд Bash как команды только для чтения и выполняет их без запроса разрешения в любом режиме, за исключением изменений, которые вносит permissions.blockReadsOutsideWorkingDirectories для путей за пределами ваших рабочих каталогов. Набор включает ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd и формы git только для чтения. Набор не настраивается; чтобы требовать запрос подтверждения для одной из этих команд, добавьте для неё правило ask или deny. В авторежиме эти команды также могут ожидать проверки классификатором; см. как классификатор оценивает действия.

Перенаправление вида ls > out.txt добавляет проверку цели. См. Перенаправления.

Шаблоны glob без кавычек допускаются для команд, у которых все флаги предназначены только для чтения, поэтому ls *.ts и wc -l src/*.py выполняются без запроса подтверждения.

В ручном режиме команды из этого набора всё равно запрашивают подтверждение в следующих случаях:

  • Glob без кавычек для команд с флагами, способными записывать: команды с флагами, способными записывать или выполнять, такие как find, sort, sed и git, запрашивают подтверждение при наличии glob без кавычек, поскольку glob может раскрыться во флаг вроде -delete.
  • docker, направленный на другой демон: формы docker только для чтения запрашивают подтверждение, когда команда содержит флаг, выбирающий другой демон, например -H, --context или --url и --connection из Podman.
  • file с флагами, открывающими пути: file запрашивает подтверждение, когда передаёт -m/--magic-file или -f/--files-from, поскольку эти флаги заставляют file открывать пути, указанные в значении флага.
  • ps, который может вывести переменные окружения: ps запрашивает подтверждение, когда один из его аргументов может действовать как опция e, как в ps auxe или ps aux -e, поскольку эта опция выводит переменные окружения процессов. ps aux и ps -ef выполняются без запроса подтверждения. Проверка форм с дефисом, таких как ps aux -e, требует Claude Code v2.1.290 или новее.
  • Сетевые пути в Windows: команда, аргументы которой включают сетевой путь (UNC), например \\server\share\file, запрашивает подтверждение, поскольку обращение к сетевому пути может отправить ваши учётные данные Windows указанному в нём хосту. Та же проверка применяется к командам инструмента PowerShell.
  • Запись в специальные переменные оболочки: команда, которая задаёт, сбрасывает или перебирает определённые специальные переменные оболочки, такие как PATH или IFS, запрашивает подтверждение, даже если остальная часть команды только читает.
  • Команды, которые анализ не может разобрать: когда Claude Code не может полностью разобрать команду, он запрашивает подтверждение вместо того, чтобы считать команду командой только для чтения. Команды длиннее 10 000 символов всегда запрашивают подтверждение, поскольку превышают объём, который разбирает анализ.

cd в путь внутри вашего рабочего каталога или дополнительного каталога также считается операцией только для чтения, и составная команда вида cd packages/api && ls выполняется без запроса подтверждения, если каждая её часть удовлетворяет условиям сама по себе. Следующие сочетания запрашивают подтверждение, даже если каждая часть только читает:

  • cd с git: запрашивает подтверждение, когда cd переходит в другой каталог, поскольку запуск git в новом каталоге может выполнить хуки этого каталога. cd, цель которого разрешается в текущий рабочий каталог, ничего не делает и не вызывает запроса.
  • cd с перенаправлением: запрашивает подтверждение, когда Claude Code не может определить, относительно какого каталога разрешается цель перенаправления после выполнения cd. Команда, единственной целью перенаправления которой является /dev/null, например cd app; grep -r pattern . 2>/dev/null, не запрашивает подтверждение, поскольку /dev/null не зависит от рабочего каталога.

Перенаправления

Когда команда перенаправляет вывод или ввод, Claude Code проверяет цель перенаправления по вашим правилам для файлов так, как если бы Claude записывал или читал этот файл напрямую:

  • Перенаправления вывода: для > file, >> file или 2> file проверка охватывает ваши правила allow и deny для Edit, защищённые пути и рабочие каталоги. Правило вида Bash(git commit *) разрешает команду, а не цель. Цель, которая начинается с ~ или содержит символ glob, требует вашего подтверждения.
  • Перенаправления ввода: для < file проверка охватывает ваши правила allow и deny для Read и рабочие каталоги. Цель за пределами рабочих каталогов требует вашего подтверждения, если её не покрывает правило allow. Цель, содержащая шаблон glob, или относительный путь, следующий за cd в той же команде, требует вашего подтверждения, даже если её покрывает правило allow. Claude Code проверяет цели ввода в v2.1.257 и новее.

Цели, за которыми не стоит файл, не проверяются: /dev/null, формы с файловыми дескрипторами, такие как 2>&1 и <&3, а также here-doc и here-string.

Claude Code также проверяет файлы, которые записывает команда tee, в том числе в конвейере вида make | tee build.log. Проверка охватывает ваши правила allow и deny для Edit, защищённые пути и рабочие каталоги. Правило allow вида Bash(tee *) не покрывает место назначения за пределами рабочих каталогов. Claude Code проверяет цели tee в v2.1.269 и новее.

PowerShell

Правила разрешений PowerShell имеют ту же форму, что и правила Bash. Подстановочные знаки * сопоставляются в любой позиции, суффикс :* эквивалентен завершающему *, а простой PowerShell или PowerShell(*) соответствует любой команде. Эта конфигурация разрешает команды Get-ChildItem и git commit, блокируя Remove-Item:

{
  "permissions": {
    "allow": [
      "PowerShell(Get-ChildItem *)",
      "PowerShell(git commit *)"
    ],
    "deny": [
      "PowerShell(Remove-Item *)"
    ]
  }
}

Распространённые псевдонимы приводятся к каноническому виду перед сопоставлением. Правило, написанное для имени командлета, также соответствует его псевдонимам, поэтому PowerShell(Get-ChildItem *) соответствует также gci, ls и dir. Сопоставление не зависит от регистра.

Claude Code разбирает AST PowerShell и проверяет каждую команду в составной команде независимо. Операторы конвейера |, разделители инструкций ;, а в PowerShell 7+ операторы цепочки && и || разделяют составную команду на подкоманды. Чтобы составная команда была разрешена, правило должно соответствовать каждой подкоманде.

Read и Edit

Чтобы запретить файловым инструментам Claude читать файл или каталог, добавьте правило deny для Read с его путём, например Read(./.env) или Read(./secrets/**); в разделе Исключение конфиденциальных файлов есть готовый для вставки пример. Если в вашем проекте есть файл .claudeignore, он ни на что не влияет, поэтому перенесите его записи в правила deny для Read.

Правила Edit применяются ко всем встроенным инструментам, которые редактируют файлы. Claude по мере возможности применяет правила Read ко всем встроенным инструментам, которые читают файлы, например Grep и Glob, к упоминаниям @file в ваших промптах, а также к выделению и контексту открытого файла, которыми подключённая IDE делится с Claude.

Правило deny для Read также блокирует инструменты Edit и Write для того же пути, включая создание там нового файла. NotebookEdit не охватывается, поэтому добавьте правило deny для Edit для путей, которые не должен изменять ни один инструмент. Проверка требует Claude Code v2.1.208 или новее для правок, и v2.1.228 или новее для записи.

Claude Code проверяет файловые разрешения только по правилам Edit(path) и Read(path). Если вместо этого вы напишете правило с путём для Write, NotebookEdit, Glob или устаревшего инструмента MultiEdit, Claude Code примет правило, но никогда не будет к нему обращаться и выдаст предупреждение при запуске, за исключением правила Glob, переданного в --allowedTools. Используйте Edit(docs/**) вместо Write(docs/**), NotebookEdit(docs/**) или MultiEdit(docs/**), и Read(docs/**) вместо Glob(docs/**). Claude Code не предупреждает о правиле с именем инструмента без пути, например о правиле deny для Write; такое правило сопоставляется на уровне инструмента везде. Требуется Claude Code v2.1.210 или новее.

Правила Read и Edit используют синтаксис шаблонов gitignore с четырьмя различными типами шаблонов; для шаблонов каталогов из одного сегмента глубина сопоставления зависит также от типа правила, как описано далее в этом разделе:

Шаблон Значение Пример Соответствует
//path Абсолютный путь от корня файловой системы Read(//Users/alice/secrets/**) /Users/alice/secrets/**
~/path Путь от домашнего каталога Read(~/Documents/*.pdf) /Users/alice/Documents/*.pdf
/path Путь относительно источника настроек Edit(/src/**/*.ts) <primary working directory>/src/**/*.ts в настройках проекта
path или ./path Путь относительно текущего каталога Read(*.env) <cwd>/*.env

Шаблон /path привязывается к каталогу, связанному с источником настроек, в котором он определён, поэтому одно и то же правило соответствует разным расположениям в зависимости от того, где вы его разместите:

Где определено правило Во что разрешается /path
Настройки проекта в .claude/settings.json <primary working directory>/path
Локальные настройки в .claude/settings.local.json <primary working directory>/path
Пользовательские настройки в ~/.claude/settings.json ~/.claude/path
Файл, переданный через --settings <file> <directory of file>/path
Флаги CLI или правила сессии <primary working directory>/path

Правило, добавленное через /permissions, следует строке для файла настроек, в который вы его сохраняете.

В v2.1.211 и новее правила локальных настроек привязываются к основному рабочему каталогу сессии, а не к корню репозитория, где Claude Code хранит файл. В сессии, запущенной из корня репозитория, эти каталоги совпадают; в сессии worktree общее правило вида Edit(/src/**) соответствует собственному каталогу src/ этого worktree.

Правило deny вида Read(/secrets/**) в пользовательских настройках блокирует ~/.claude/secrets/**, а не каталог secrets в вашем проекте. Чтобы написать в пользовательских настройках правило, действующее внутри каждого проекта, используйте абсолютный путь с // или путь относительно домашнего каталога с ~/.

В Windows пути перед сопоставлением нормализуются к форме POSIX. C:\Users\alice превращается в /c/Users/alice, поэтому используйте //c/**/.env, чтобы сопоставить файлы .env в любом месте этого диска. Чтобы сопоставлять на всех дисках, используйте //**/.env.

Примеры:

  • Edit(/docs/**): правки в <primary working directory>/docs/, но не в /docs/ и не в <primary working directory>/.claude/docs/
  • Read(~/.zshrc): чтение .zshrc в вашем домашнем каталоге
  • Edit(//tmp/scratch.txt): правки по абсолютному пути /tmp/scratch.txt
  • Read(src/**): как правило allow — чтение только из <current-directory>/src/; как правило deny или ask — соответствует каталогу src на любой глубине внутри текущего каталога

Правило соответствует только файлам внутри своей точки привязки; в этих пределах глубина сопоставления зависит от формы шаблона, а для шаблонов каталогов из одного сегмента — от типа правила, как описано ниже. Простые имена файлов следуют семантике gitignore и сопоставляются на любой глубине, поэтому Read(.env) и Read(**/.env) эквивалентны:

Правило deny Блокирует Не блокирует
Read(.env) или Read(**/.env) любой .env в текущем каталоге или ниже .env в родительском каталоге или другом проекте
Read(//**/.env) любой .env в любом месте файловой системы ничего; правило привязано к корню файловой системы

Относительный шаблон с одним сегментом каталога, например src/**, сопоставляется на разной глубине в зависимости от типа правила:

  • Правила allow: Edit(src/**) соответствует только <cwd>/src и файлам внутри него. Чтобы разрешить имя каталога на любой глубине, напишите Edit(**/src/**).
  • Правила deny и ask: Read(secrets/**) соответствует каталогу с именем secrets на любой глубине внутри текущего каталога, поэтому правило применяется и к вложенным копиям.

Все остальные формы шаблонов сопоставляются на одной и той же глубине при любом типе правила: Edit(/src/**) и Edit(src/components/**) соответствуют только своему привязанному расположению, а Edit(**/src/**) — любой глубине.

В следующем примере показана каждая форма шаблона применительно к проекту с каталогом src/ верхнего уровня и вложенной копией внутри vendor/:

<current-directory>/
├── src/
│   └── app.ts
└── vendor/
    └── pkg/
        └── src/
            └── lib.js
Правило Соответствует src/app.ts Соответствует vendor/pkg/src/lib.js
Edit(src/**) как правило allow Да Нет
Edit(src/**) как правило deny или ask Да Да
Edit(/src/**) при любом типе правила Да Нет
Edit(**/src/**) при любом типе правила Да Да

Когда вы одобряете путь к файлу с помощью «Yes, and don't ask again», Claude Code экранирует в этом пути символы шаблонов gitignore, такие как [, ] и *, поэтому созданное правило соответствует только буквально одобренному вами пути. Правила, которые вы пишете сами, не экранируются. До v2.1.202 Claude Code сохранял путь без экранирования, поэтому созданное правило для каталога с именем [2024-06] Reports могло не соответствовать собственному пути или соответствовать непредусмотренным соседним каталогам.

Экранировать круглые скобки в пути не нужно, поэтому Edit(./Finance (2024)/**) соответствует папке Finance (2024) в точном написании.

Правило deny или ask, путь которого нельзя использовать как шаблон gitignore, всё равно защищает именно этот путь. Правило allow с непригодным шаблоном ничего не одобряет.

Шаблон deny или ask, начинающийся с !, является отрицанием gitignore. Он исключает соответствующие ему пути из правил path или ./path, перечисленных перед ним. В списке deny одного файла настроек Read(*.env), за которым следует Read(!sample.env), блокирует каждый файл с именем, оканчивающимся на .env, на любой глубине, кроме файлов с именем sample.env. Правило !, указанное первым, ничего не исключает.

Исключение затрагивает только правила из того же источника. Read(!.env) в настройках проекта или в --disallowedTools не отменяет правило deny Read(./.env) из управляемых настроек или любого другого файла настроек.

Два ограничения сужают то, что может исключить шаблон !:

  • Claude Code читает шаблон ! относительно текущего каталога, даже если за ! следует /, ~/ или //, поэтому шаблон не может затронуть правило, привязанное с помощью одного из этих префиксов. Read(!~/notes/public/**) ничего не исключает из Read(~/notes/**).
  • Исключение не может снова открыть файл внутри каталога, который правило блокирует целиком. При Read(secrets/**) и Read(!secrets/public/**) Claude Code по-прежнему блокирует secrets/public вместе с остальной частью secrets.

Когда путь к файлу, запрошенный Claude, проходит через символическую ссылку, проверка разрешений охватывает два пути: запрошенный Claude и файл, в который он разрешается. Это относится к символическим ссылкам в macOS, Linux и Windows, а также к точкам соединения каталогов (junctions) в Windows.

Как правила сопоставляются с путём через символическую ссылку

Правила allow и deny по-разному обрабатывают запрошенный путь и файл, в который он разрешается:

  • Правила allow: применяются, только если соответствуют и запрошенный путь, и файл, в который он разрешается. Чтение через символическую ссылку внутри разрешённого каталога, указывающую за его пределы, не соответствует правилу.
  • Правила deny: применяются, если соответствует либо запрошенный путь, либо файл, в который он разрешается. Символическая ссылка, указывающая на запрещённый файл, сама запрещена. Например, если Read(./project/**) разрешено, а Read(~/.ssh/**) запрещено, символическая ссылка ./project/key, указывающая на ~/.ssh/id_rsa, блокируется: цель не проходит правило allow и соответствует правилу deny.

В macOS и Linux правило deny или ask, написанное через каталог-символическую ссылку с шаблоном //, ~/ или /, применяется также к реальному расположению каталога. Например, в macOS, где /etc разрешается в /private/etc, Read(//etc/**) блокирует и /private/etc/hosts. До v2.1.268 правило deny или ask, написанное через каталог-символическую ссылку, не применялось к пути, заданному через его реальное расположение.

Grep и Glob выполняют поиск в каталоге, в который разрешается аргумент path. Claude Code применяет к этому каталогу правила deny для Read.

Если путь, который Claude просит отредактировать или записать, сам является символической ссылкой, инструменты Edit и Write отказываются выполнять запись и направляют Claude к цели ссылки.

Запись всё же может пройти через символическую ссылку, если символической ссылкой является каталог на пути к файлу или если запись выполняет команда Bash или PowerShell. Для таких записей результат зависит от того, где находится файл, в который разрешается запись, относительно ваших рабочих каталогов и защищённых путей:

  • Разрешается за пределы рабочих каталогов: когда запрошенный путь находится внутри ваших рабочих каталогов, а файл, в который он разрешается, — нет, запись не одобряется автоматически в режиме acceptEdits. В авторежиме, если запись не одобрена правилом allow, подтверждение запрашивается у вас, а не решается классификатором. В запросе указывается путь, в который разрешается запись.
  • Разрешается в защищённый путь, который не назван в запрошенном пути: таблица защищённых путей указывает результат для каждого режима разрешений, за исключением того, что там, где таблица направляет запись классификатору, для этой записи подтверждение запрашивается у вас.
Пути, которые невозможно разрешить или которые изменяются

Когда Claude Code не может определить, куда ведёт путь на диске, например потому, что символические ссылки на нём образуют цикл, инструменты Read, Edit и Write отказываются выполнять операцию.

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

Сетевые пути

Когда инструменты Claude для чтения файлов, такие как Read, Grep и Glob, читают по сетевому пути, чтение проходит собственную проверку разрешений. Сетевой путь — это путь, который может вести на другой компьютер: в Windows это путь UNC, например \\server\share\file, а в macOS и Linux — путь автомонтирования /net, например /net/fileserver/notes.txt. Поиск такого пути может обратиться к указанному в нём хосту, а в Windows такое обращение может отправить хосту ваши учётные данные. У shell-команд есть собственная проверка: в ручном режиме команда Bash или PowerShell только для чтения, аргументы которой включают путь UNC, всё равно запрашивает подтверждение в Windows.

В Claude Code v2.1.292 и новее запрос подтверждения сохраняется в каждом из следующих случаев:

  • Правила allow: правило не одобряет чтение заранее, включая правило для всего инструмента, например Read
  • Хуки PreToolUse: хук, который возвращает "allow", не отменяет запрос подтверждения
  • Авторежим: запрос приходит вам, и классификатор не принимает решение о чтении

В режиме dontAsk Claude Code отклоняет чтение вместо запроса подтверждения. В режиме bypassPermissions, а также в интерактивных сессиях терминала в режиме планирования при доступном обходе разрешений чтение выполняется без этого запроса.

Чтобы читать файлы на сетевом ресурсе без этого запроса, сначала назначьте ресурсу локальный путь:

  • Windows: подключите ресурс как букву диска и передайте диск через --add-dir при запуске Claude Code, как описано в разделе Рабочие каталоги
  • macOS и Linux: смонтируйте ресурс по локальному пути, например в каталог внутри /mnt или /Volumes, и читайте файлы оттуда, как описано в разделе Рабочий каталог является сетевым путём

WebFetch

Правила WebFetch используют префикс domain: и сопоставляются с именем хоста запрошенного URL. Сопоставление не зависит от регистра, поддерживает подстановочные знаки * и удаляет завершающую . как из правила, так и из имени хоста, поэтому example.com. и example.com считаются одинаковыми.

  • WebFetch(domain:example.com) соответствует только запросам к example.com. Чтобы охватить также поддомены, например api.example.com, добавьте правило WebFetch(domain:*.example.com)
  • WebFetch(domain:*.example.com) соответствует любому поддомену на любой глубине, например api.example.com или a.b.example.com, но не самому example.com
  • WebFetch(domain:*) соответствует любому домену. Это не то же самое, что простое правило WebFetch; см. Разрешение или запрет всех загрузок

В любой позиции, кроме начального *. или одиночного *, подстановочный знак соответствует только тексту между двумя точками. WebFetch(domain:example.*) соответствует example.org, где * становится org, но не example.evil.com, где * пришлось бы стать evil.com и пересечь точку. Это не позволяет завершающему подстановочному знаку соответствовать доменам, которые может зарегистрировать злоумышленник.

Чтобы подстановочные знаки в правилах WebFetch сопоставлялись с загрузками, требуется Claude Code v2.1.172 или новее.

Разрешение или запрет всех загрузок

Простое правило WebFetch — это имя инструмента без части domain:, например "deny": ["WebFetch"]. И оно, и WebFetch(domain:*) охватывают любой URL, но Claude Code применяет их по-разному, и только форма domain: также добавляет свой домен в список разрешённых или запрещённых доменов песочницы. В том разделе перечислены формы с подстановочными знаками, которые учитывает песочница, и версия, в которой был добавлен одиночный *.

В каждой строке показано, что делает правило в списке allow и в списке deny:

Правило В allow В deny
WebFetch Claude загружает страницы без запроса подтверждения. Не меняет набор хостов, к которым могут обращаться команды в песочнице. Claude Code удаляет инструмент WebFetch, поэтому Claude вообще не может загружать страницы. Не меняет набор хостов, к которым могут обращаться команды в песочнице.
WebFetch(domain:*) Claude загружает страницы без запроса подтверждения, а команды в песочнице могут обращаться к любому хосту. Claude Code сохраняет инструмент и отклоняет каждую загрузку, а команды в песочнице не могут обращаться ни к одному хосту.

Эти две формы также различаются при чтении артефактов — страниц, которые инструмент Artifact публикует на claude.ai. Простое правило deny или ask для WebFetch не применяется к таким чтениям. Правило domain:, охватывающее claude.ai или хост содержимого *.claudeusercontent.com, например WebFetch(domain:claude.ai) или WebFetch(domain:*), отклоняет каждое чтение или запрашивает подтверждение перед ним. Правило Artifact делает то же самое.

Когда правило блокирует чтение, в сообщении об отказе указывается это правило. До v2.1.268 простое правило deny для WebFetch блокировало каждое чтение артефакта, а простое правило ask запрашивало подтверждение перед каждым из них.

Чтобы позволить Claude свободно загружать страницы, сохранив список разрешённых доменов песочницы без изменений, используйте простую форму. Этот settings.json делает именно это:

{
  "permissions": {
    "allow": ["WebFetch"]
  }
}

Когда вы просите Claude загрузить страницу, он загружает её без запроса подтверждения. Когда вы просите его выполнить curl в песочнице к хосту вне списка разрешённых доменов песочницы, Claude Code всё равно запрашивает у вас подтверждение для этого хоста, поскольку простое правило не добавило хост в список разрешённых доменов.

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

MCP

Правила MCP используют имя сервера в том виде, в каком оно настроено в Claude Code, за которым может следовать имя инструмента этого сервера.

  • mcp__puppeteer соответствует любому инструменту, предоставляемому сервером puppeteer
  • mcp__puppeteer__* использует синтаксис подстановочных знаков и также соответствует всем инструментам сервера puppeteer
  • mcp__puppeteer__puppeteer_navigate соответствует инструменту puppeteer_navigate, предоставляемому сервером puppeteer

Если ваша организация установила для инструмента коннектора claude.ai значение ask и эта настройка доходит до Claude Code в вашей сессии, правила allow для этого инструмента не действуют: Claude Code запрашивает подтверждение при каждом вызове, даже в режимах auto и bypassPermissions. В режиме dontAsk, который никогда не запрашивает подтверждение, Claude Code вместо этого отклоняет вызов. Инструменты из коннекторов, которые Claude Code загружает сам, отображаются как mcp__claude_ai_<server>__<tool>.

В сессии Cowork в приложении Claude Desktop Claude выполняет shell-команды через инструмент Cowork mcp__workspace__bash, а не через встроенный инструмент Bash, и Cowork аналогично предоставляет mcp__workspace__web_fetch для веб-загрузок. Claude Code также применяет к этим инструментам Cowork правила deny, называющие весь инструмент Bash или WebFetch, поэтому управляемое правило deny для Bash не даёт Claude выполнять shell-команды в Cowork. Когда Claude Code блокирует такой вызов, в сообщении указывается инструмент Cowork: Permission to use mcp__workspace__bash has been denied. Правила allow не переносятся: Claude Code никогда не применяет правило allow для Bash к mcp__workspace__bash.

Agent (субагенты)

Используйте правила Agent(AgentName), чтобы управлять тем, какие субагенты может использовать Claude:

  • Agent(Explore) соответствует субагенту Explore
  • Agent(Plan) соответствует субагенту Plan
  • Agent(my-custom-agent) соответствует пользовательскому субагенту с именем my-custom-agent

Добавьте эти правила в массив deny в ваших настройках или используйте флаг CLI --disallowedTools, чтобы отключить определённых агентов. Чтобы отключить агента Explore:

{
  "permissions": {
    "deny": ["Agent(Explore)"]
  }
}

Cd

Правила Cd управляют тем, в какие каталоги команда /cd может переместить сессию. Cd не является инструментом, вызываемым моделью: Claude не может его вызвать, и правила применяются только тогда, когда вы сами запускаете /cd.

Простое правило deny Cd полностью отключает /cd. Правило deny Cd(<path-pattern>) блокирует соответствующие цели. Правила deny проверяют каждое написание цели, включая каждый переход по символической ссылке, через который она разрешается, поэтому правило, написанное для одного пути, также блокирует цели, которые в него разрешаются.

Добавление любого правила allow Cd переводит /cd в режим списка разрешённых каталогов: разрешённый целевой каталог должен соответствовать одному из ваших правил allow, иначе /cd откажет. Если правила Cd не настроены, /cd сохраняет поведение по умолчанию и запрашивает у вас подтверждение доверия незнакомому каталогу.

Шаблоны путей используют те же точки привязки //, ~/ и /, что и правила Read и Edit, но сопоставление привязано ко всему пути каталога, а не выполняется в стиле gitignore. * соответствует ровно одному сегменту пути, а ** — нескольким сегментам. Завершающий /** также соответствует названному корню.

Правило Соответствует Не соответствует
Cd(~/code/*) ~/code/app ~/code/app/src, ~/code
Cd(~/code/**) ~/code и любому каталогу внутри него каталогам вне ~/code
Cd(**/node_modules) любому каталогу node_modules на любой глубине внутри текущего каталога node_modules/pkg

Расширение разрешений с помощью hooks

Claude Code hooks позволяют регистрировать пользовательские команды оболочки, которые оценивают разрешения во время выполнения. Когда Claude Code выполняет вызов инструмента, PreToolUse hooks запускаются перед запросом разрешения для каждого инструмента, кроме EndConversation. Выход hook может отклонить вызов инструмента, принудить запрос или пропустить запрос, чтобы позволить вызову продолжиться.

Решения hook не обходят правила разрешений. Claude Code оценивает правила deny и ask независимо от того, что возвращает PreToolUse hook: совпадающее правило deny блокирует вызов, и совпадающее правило ask по-прежнему запрашивает даже когда hook вернул "allow" или "ask". Это сохраняет приоритет deny-first, описанный в Управление разрешениями, включая правила deny, установленные в управляемых параметрах.

Этот приоритет распространяется на хуки в файлах настроек и в hooks/hooks.json плагина. Установленный вами mod, который обрабатывает tool.check, отвечает после того, как правила и хуки PreToolUse приняли решение, и его ответ может заменить их решение:

  • Правила Ask: mod может одобрить вызов, для которого правило ask запросило бы подтверждение
  • Блокировка от PreToolUse hook: mod может одобрить вызов, если только hook не находится в управляемых параметрах
  • Классификатор автоматического режима: в автоматическом режиме вызов, одобренный mod, выполняется без проверки классификатора
  • Правила Deny: на машине с управляемыми параметрами или когда вы вошли с планом Team или Enterprise, правила deny по умолчанию имеют приоритет над mod, и ваша организация может это изменить. В любом другом месте mod может одобрить вызов, который правило deny отклоняет.

См. Решить, доверять ли mod или Управление mod для вашей организации, если вы развёртываете управляемые параметры.

Для инструмента, требующего взаимодействия с пользователем, например AskUserQuestion или инструмента MCP, отмеченного requiresUserInteraction, подтверждение мода через tool.check не пропускает запрос разрешения. Требуется Claude Code v2.1.292 или новее. Инструменты MCP, отмеченные requiresUserInteraction, также по-прежнему запрашивают подтверждение, когда хук возвращает "allow", как и чтение из сетевых путей и инструменты коннекторов, для которых ваша организация установила ask, в сессиях, где эта настройка доходит до Claude Code.

Блокирующий hook также имеет приоритет над правилами allow. Hook, который выходит с кодом 2, останавливает вызов инструмента перед оценкой правил разрешений, поэтому блокировка применяется даже когда правило allow иначе позволило бы вызову продолжиться. Чтобы запустить все Bash команды без запросов, кроме нескольких, которые вы хотите заблокировать, добавьте "Bash" в список allow и зарегистрируйте PreToolUse hook, который отклоняет эти конкретные команды. См. Блокировка редактирования защищённых файлов для скрипта hook, который вы можете адаптировать.

Рабочие каталоги

По умолчанию Claude имеет доступ к файлам в каталоге, где вы его запустили. Этот каталог является основным рабочим каталогом сеанса до тех пор, пока вы не переместите сеанс с помощью /cd. Вы можете расширить этот доступ:

  • При запуске: используйте аргумент CLI --add-dir <path>
  • Во время сеанса: используйте команду /add-dir
  • Постоянная конфигурация: добавьте в additionalDirectories в файлы параметров

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

Вы не можете добавить большинство сетевых путей, таких как общая папка UNC \\server\share, в качестве рабочих каталогов, потому что поиск может связаться с хостом, который она называет. На Windows вместо этого сопоставьте общую папку с буквой диска и передайте диск с помощью --add-dir при запуске.

Установите permissions.blockReadsOutsideWorkingDirectories, чтобы инструменты работы с файлами отказывали в путях, которые она ограничивает, в каждом режиме разрешений. В автоматическом режиме Claude Code предлагает включить это в первый раз, когда Claude читает вне рабочих каталогов.

В фоновых сеансах на macOS хост сеанса запрашивает доступ к защищённым папкам, таким как ~/Desktop, ~/Documents и ~/Downloads, отдельно от вашего терминала, когда Claude нужно читать или писать файлы там; если чтение там завершается с ошибкой Operation not permitted, см. как предоставить доступ к папкам для фоновых сеансов.

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

Чтобы переместить сессию в другой основной рабочий каталог, вместо добавления каталога рядом с текущим, выполните /cd <path>. Claude Code сохраняет диалог, загружает CLAUDE.md нового каталога и предлагает вам доверять рабочему пространству, если вы в нём раньше не работали. После этого Claude Code находит перемещённую сессию, когда вы запускаете --resume из нового каталога.

Как только вы переместитесь, Claude Code применяет конфигурацию проекта нового каталога:

  • Его параметры проекта, включая их правила разрешений и hooks
  • Его серверы .mcp.json, подлежащие тому же одобрению сервера, что и при запуске, и локальные MCP серверы, которые вы зарегистрировали в нём
  • Плагины, которые его параметры включают, его skills и его subagents
  • Его значения env, применённые поверх переменных окружения из параметров предыдущего каталога, которые остаются в силе

Claude Code также отключает проект предыдущего каталога и локальные MCP серверы, а также серверы плагинов, которые больше не включены после перемещения. Он берёт дополнительные каталоги из параметров нового каталога вместо параметров предыдущего и сохраняет каталоги, которые вы добавили с помощью --add-dir или /add-dir. Hooks, которые активирует перемещение, по-прежнему получают ${CLAUDE_PROJECT_DIR}, установленный в корень проекта, где сеанс начался.

Когда новый каталог ещё не доверен, Claude Code перечисляет в подсказке доверия правила разрешения, дополнительные каталоги, hooks и вспомогательные команды, которые активировали бы параметры каталога, чтобы вы могли их просмотреть перед принятием. Если вы отклоните, сеанс останется там, где он был. До версии 2.1.246 /cd не применял параметры нового каталога, hooks, MCP серверы или skills до тех пор, пока вы не возобновили сеанс, и его подсказка доверия не перечисляла, что активировали бы параметры каталога.

Ограничьте или отключите цели /cd с помощью правил разрешений Cd.

Дополнительные каталоги предоставляют доступ к файлам, а не конфигурацию

Добавление каталога расширяет, где Claude может читать и редактировать файлы. Это не делает этот каталог полным корнем конфигурации: большинство конфигурации .claude/ не обнаруживается из дополнительных каталогов, хотя несколько типов загружаются как исключения.

Эти исключения применяются только к каталогам, добавленным с флагом --add-dir или командой /add-dir, включая каталоги, которые Agent SDK добавляет через флаг. Каталоги, указанные в permissions.additionalDirectories в файле параметров, предоставляют доступ только к файлам и не загружают никакую конфигурацию ниже.

Agent SDK additionalDirectories опция в TypeScript и add_dirs опция в Python получают исключения тоже, хотя опция TypeScript делит своё имя с ключом параметров. SDK передаёт каждую запись в Claude Code как --add-dir, поэтому эти каталоги ведут себя как каталоги, добавленные флагом. Skills, команды и subagents из любого каталога, добавленного флагом, загружаются через источник параметра project setting source, поэтому они не загружаются, когда вы исключаете этот источник с помощью --setting-sources в CLI или settingSources в SDK, и bare mode пропускает команды и subagents среди них.

Следующие типы конфигурации загружаются из каталогов --add-dir:

Конфигурация Загружается из --add-dir
Skills в .claude/skills/ Да, с live reload
Файлы команд в .claude/commands/ Да, без live reload. Когда добавленный каталог и ваш проект оба определяют команду с одинаковым именем, Claude Code запускает команду вашего проекта
Subagents в .claude/agents/ Да, без live reload
Settings в .claude/settings.json и .claude/settings.local.json Только ключи enabledPlugins и extraKnownMarketplaces
CLAUDE.md файлы, .claude/rules/ и CLAUDE.local.md Только когда установлено CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1. CLAUDE.local.md дополнительно требует источник параметра local, который включен по умолчанию

Чтобы загрузить skills, команды и subagents из подкаталога вашего основного рабочего каталога в середине сеанса, запустите /add-dir с путём этого подкаталога. Claude Code загружает их на оставшуюся часть сеанса без запроса или добавления рабочего каталога, потому что подкаталог уже читаем. Это требует Claude Code версии 2.1.257 или позже.

Claude Code обнаруживает стили вывода из текущего рабочего каталога и его родителей, вашего пользовательского каталога в ~/.claude/ и управляемых параметров. Hooks и другие ключи .claude/settings.json загружаются из папки .claude/ текущего рабочего каталога без резервного варианта для родительского каталога, наряду с вашим пользовательским файлом ~/.claude/settings.json и управляемыми параметрами. .claude/settings.local.json загружается из корня репозитория git вместо этого, даже когда вы запускаете Claude Code в подкаталоге, кроме случаев, когда Claude Code не использует корень репозитория, например на Windows; до версии 2.1.211 он тоже загружался только из текущего рабочего каталога. Сеансы Agent SDK загружают его из рабочего каталога во всех версиях.

Чтобы поделиться этой конфигурацией между проектами, используйте один из этих подходов:

  • Конфигурация на уровне пользователя: поместите файлы в ~/.claude/agents/, ~/.claude/output-styles/ или ~/.claude/settings.json, чтобы сделать их доступными в каждом проекте
  • Плагины: упакуйте и распространяйте конфигурацию как плагин, который команды могут установить
  • Запуск из каталога конфигурации: запустите Claude Code из каталога, содержащего конфигурацию .claude/, которую вы хотите использовать

Как разрешения взаимодействуют с песочницей

Разрешения и песочница — это дополняющие друг друга уровни безопасности:

  • Разрешения контролируют, какие инструменты может использовать Claude Code и к каким файлам или доменам он может получить доступ. Они применяются к Bash, Read, Edit, WebFetch, MCP и всем остальным инструментам, за исключением того, что правило отказа или запроса не может заблокировать EndConversation, пока остаётся любой другой инструмент.
  • Изоляция в песочнице обеспечивает принудительное применение на уровне ОС, которое ограничивает доступ shell-команд к файловой системе и сети. Она применяется к командам инструментов Bash, PowerShell и Monitor и их дочерним процессам.

Используйте оба уровня для защиты в глубину, поскольку ограничения песочницы остаются в силе даже если инъекция в подсказку обойдёт принятие решений Claude. Пути и домены из параметров песочницы и правил разрешений объединяются в финальную конфигурацию песочницы.

Когда вы включаете песочницу и оставляете autoAllowBashIfSandboxed со значением по умолчанию true, команды Bash в песочнице выполняются без запроса даже если ваши разрешения включают простое правило запроса Bash, или эквивалентную форму Bash(*): граница песочницы заменяет этот запрос для всего инструмента.

В режиме плана Claude Code пропускает эту замену. Без правила запроса встроенные команды только для чтения по-прежнему выполняются без запроса, и любая другая команда оболочки проходит через обычный поток разрешений пока вы всё ещё планируете; см. режим плана для того, как Claude Code управляет командами там. С простым правилом запроса Bash, каждая команда Bash запрашивается, включая команды только для чтения в песочнице, так же как вне песочницы. До версии v2.1.212 замена применялась также в режиме плана.

Эти проверки по-прежнему применяются:

  • Правила запроса с областью действия контента, такие как Bash(git push *), по-прежнему требуют запроса
  • Явные правила отказа по-прежнему применяются
  • Команды rm или rmdir, которые нацелены на критический путь, по-прежнему проходят через обычный поток разрешений

Команды, которые не будут выполняться в песочнице, такие как исключённые команды, соблюдают простое правило запроса Bash как обычно. См. режимы песочницы для изменения этого поведения.

Управляемые параметры

Для организаций, которым требуется централизованный контроль, администраторы развертывают управляемые параметры, которые не могут быть переопределены параметрами пользователя и проекта, за исключением нескольких ключей, чувствительных к безопасности. Развертывание управляемых параметров охватывает механизмы доставки, приоритет в управляемом уровне и ключи, которые могут устанавливать только управляемые параметры.

Один из этих ключей, allowManagedPermissionRulesOnly, делает управляемые параметры единственным источником параметров для правил разрешений. Его запись содержит список каждого источника, который Claude Code затем игнорирует.

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

Приоритет параметров

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

Если инструмент запрещен на любом уровне, никакой другой уровень не может его разрешить. Например, управляемый параметр deny не может быть переопределен --allowedTools, и --disallowedTools может добавить ограничения сверх того, что определяют управляемые параметры.

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

Этот приоритет применяется между файлами параметров и аргументами командной строки. Относительно того, действует ли правило запрета над mod, который вы устанавливаете, см. Расширение разрешений с помощью hooks.

Хосты встраивания могут предоставлять дополнительную управляемую политику через опцию SDK managedSettings, включая правила разрешения разрешений, если администратор не устанавливает блокировки allowManaged*Only; раздел Deliver policy to Claude Desktop sessions описывает, когда политика встраивающей стороны применяется вообще.

Правила allow проекта и доверие к рабочему пространству

Правила permissions.allow и записи permissions.additionalDirectories в файле .claude/settings.json проекта предоставляют возможности, поэтому Claude Code применяет их только после того, как вы примете диалог доверия к рабочему пространству для этой папки. В диалоге перечислены правила и каталоги, которые предоставила бы папка, чтобы вы могли сначала их просмотреть. Правила deny и ask это не затрагивает, поскольку они только ограничивают.

Claude Code привязывает и хранит принятое вами доверие в зависимости от того, где вы его запускаете:

  • В репозитории Claude Code привязывает доверие к корню git-репозитория, поэтому доверие распространяется на весь репозиторий, за исключением любого вложенного в него git-репозитория, например подмодуля. В worktree используется корень основного checkout, как и для сохранённых правил.
  • Вне репозитория Claude Code привязывает доверие к каталогу, из которого вы его запустили, и доверие распространяется на любой подкаталог этого каталога, за исключением вложенного в него git-репозитория, например клона. Каждый такой подкаталог затем считается папкой, родителю которой вы доверили.
  • Если вы запускаете Claude Code в своём домашнем каталоге, он хранит доверие только для текущей сессии и не записывает его на диск; см. примечание о дополнительных мерах защиты.

Claude Code показывает диалог доверия только в интерактивных сессиях. Запуск claude -p или сессия SDK никогда его не показывают, и доверие к родительской папке для этих правил не учитывается, поэтому в разделе Что выполняется до того, как вы доверите папке указано, какое содержимое репозитория Claude Code всё же использует в каждой из этих двух ситуаций.

Перед запуском или перезапуском фоновой сессии Claude Code также проверяет доверие к рабочему пространству для каталога, в котором выполняется сессия. Если вы запускаете claude --bg из терминала в каталоге, которому вы не доверили, сначала появляется диалог доверия, и сессия запускается после того, как вы его примете. Там, где диалог появиться не может, например в скрипте, команда вместо этого завершается с ошибкой Workspace not trusted.

Когда вашему локальному файлу настроек требуется доверие

.claude/settings.local.json обычно является вашим собственным файлом, поэтому Claude Code применяет его правила allow и дополнительные каталоги без шага доверия. Если файл отслеживается в git или .claude является символической ссылкой, Claude Code вместо этого считает его предоставленным репозиторием и не применяет его правила, пока вы не доверите папке.

Чтобы различить эти случаи, Claude Code запускает git, и запускает его только после того, как вы доверили папке: вы приняли диалог доверия для неё или для родительского каталога, доверие к которому на неё распространяется, либо вы находитесь в сессии -p или SDK, что считается принятием. До этого то, что происходит с правилами файла, зависит от того, где вы запустили Claude Code:

  • В вашем домашнем каталоге конфигурации: Claude Code сразу применяет .claude/settings.local.json этой папки, не запуская git. Ваш домашний каталог конфигурации — это ваш домашний каталог или каталог, подкаталог .claude которого вы задали как CLAUDE_CONFIG_DIR. Если этот каталог CLAUDE_CONFIG_DIR находится внутри git-репозитория и Claude Code вместо этого хранит ваши локальные настройки в корне репозитория, он не применяет правила, как и в любом другом месте.
  • В любом другом месте: Claude Code не применяет правила файла, как и в случае настроек проекта. После выполнения проверки Claude Code применяет правила неотслеживаемого файла или файла в каталоге вне любого git-репозитория, даже если вы не доверили именно этой папке.

До версии v2.1.207 Claude Code применял правила неотслеживаемого файла до того, как вы принимали диалог.

Что выполняется до того, как вы доверите папке

Каждая строка — это один вид содержимого, которое может предоставить репозиторий. Столбцы — это две ситуации, в которых вы не доверили самой папке: вы доверили только родительской папке или вы запустили там claude -p или SDK, которые никогда не показывают диалог доверия. Столбец родительской папки не применяется внутри вложенного репозитория: в интерактивной сессии Claude Code показывает для него диалог доверия, а запуск claude -p или SDK в нём следует столбцу claude -p.

Что предоставляет репозиторий Вы доверили только родительской папке claude -p или SDK, папке никогда не доверяли
Хуки в файлах настроек, блок env и вспомогательные команды, такие как apiKeyHelper, а также хуки и allowed-tools скилла проекта Используются Используются. Доверие к рабочему пространству никогда не ограничивает allowed-tools скилла ни в одной сессии
Правила permissions.allow и additionalDirectories в .claude/settings.json Не используются, пока вы не примете диалог доверия, который появляется снова с их перечнем Не используются. Claude Code выводит в stderr предупреждение this workspace has not been trusted
Хуки во frontmatter субагента проекта, плагин @skills-dir проекта и записи extraKnownMarketplaces из репозитория или каталога --add-dir Не используются, и диалог не предлагается Не используются
Встроенные mcpServers во frontmatter субагента из репозитория или каталога --add-dir Не используются, и диалог не предлагается Не используются
Серверы в .mcp.json, включая те, которые репозиторий одобряет в собственных настройках Claude Code спрашивает вас перед их подключением. Собственные одобрения репозитория не учитываются Подключаются без запроса, одобрены они или нет. SDK загружает их, только если settingSources включает настройки проекта. claude mcp list в той же папке по-прежнему сообщает о таком сервере как об ожидающем
headersHelper у сервера в .mcp.json Не запускается, пока вы не примете диалог доверия, который появляется снова с указанием места, где объявлен helper. До этого Claude Code подключает сервер только со статическими headers Не запускается. Claude Code подключает сервер только со статическими headers и выводит в stderr строку headersHelper not run для каждого сервера

Для строк, в которых требуется доверие именно к этой папке, задайте доверие вручную: установите projects["<path>"].hasTrustDialogAccepted в значение true в ~/.claude.json, где <path> — корень репозитория или сама папка вне репозитория. Claude Code выводит точный ключ в строке debug-лога для пропущенного хука субагента или встроенного MCP-сервера, в предупреждении stderr для пропущенных правил allow и в строке headersHelper not run для пропущенного helper.

Прежде чем запускать claude -p в репозитории, который писали не вы, решите, что ему разрешено запускать на вашем компьютере:

  • Передайте --setting-sources user или задайте settingSources в SDK без настроек проекта, чтобы Claude Code не читал ни файлы настроек проекта, ни его .mcp.json
  • Запускайте с --bare, чтобы Claude Code не читал из проекта хуки, скиллы, пользовательские команды, субагентов, плагины или серверы .mcp.json. Блок env проекта и вспомогательные команды, такие как awsAuthRefresh, в его файлах настроек по-прежнему применяются, а apiKeyHelper Claude Code читает только из --settings
  • Передайте --settings '{"disableAllHooks": true}', чтобы отключить хуки для этого запуска. Задать это только в пользовательских настройках недостаточно, поскольку настройки проекта репозитория имеют приоритет над вашими и могут вернуть значение false
  • Добавьте запись disabledMcpjsonServers, чтобы отклонять сервер .mcp.json по имени в сессиях любого типа

Примеры конфигураций

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

См. также

  • Все параметры: каждый ключ параметра, включая ключи разрешений
  • Настройка режима auto: укажите классификатору режима auto, какую инфраструктуру ваша организация доверяет
  • Sandboxing: изоляция файловой системы и сети на уровне ОС для команд Bash
  • Authentication: настройка доступа пользователей к Claude Code
  • Security: гарантии безопасности и лучшие практики
  • Hooks: автоматизация рабочих процессов и расширение оценки разрешений