Настройка разрешений
Контролируйте, что Claude Code может использовать и делать, с помощью детальных правил разрешений, режимов и управляемых политик.
Claude Code поддерживает детальные разрешения, позволяя вам точно указать, что агент может делать и что он не может. Параметры разрешений можно добавить в систему контроля версий и распространить среди всех разработчиков в вашей организации, а также настроить отдельными разработчиками.
Система разрешений
Claude Code использует многоуровневую систему разрешений для баланса между мощностью и безопасностью:
| Тип инструмента | Пример | Требуется одобрение | Поведение "Да, не спрашивать снова" |
|---|---|---|---|
| Только чтение | Чтение файлов, Grep | Нет | Н/А |
| Bash команды | Выполнение оболочки | Да | Постоянно для каждого каталога проекта и команды |
| Изменение файлов | Edit/Write файлы | Да | До конца сеанса |
Управление разрешениями
Вы можете просматривать и управлять разрешениями инструментов Claude Code с помощью /permissions. Этот интерфейс отображает все правила разрешений и файлы settings.json, из которых они берутся.
- Правила Allow позволяют Claude Code использовать указанный инструмент без ручного одобрения.
- Правила Ask запрашивают подтверждение каждый раз, когда Claude Code пытается использовать указанный инструмент.
- Правила Deny предотвращают использование Claude Code указанного инструмента.
Правила оцениваются по порядку: deny, затем ask, затем allow. Первое совпадающее правило в этом порядке определяет результат, и специфичность правила не изменяет порядок.
Широкое правило deny, такое как Bash(aws *), блокирует каждый совпадающий вызов, включая вызовы, которые также совпадают с более узким правилом allow, таким как Bash(aws s3 ls), поэтому правило deny не может содержать исключения в списке разрешений. Тот же приоритет применяется между ask и allow: совпадающее правило ask выдает запрос даже когда более специфичное правило allow также совпадает с тем же вызовом.
Правила Deny ведут себя по-разному в зависимости от того, называют ли они инструмент или определяют область действия шаблона внутри него. Простое имя инструмента, такое как Bash, удаляет инструмент из контекста Claude полностью, поэтому Claude его никогда не видит. Правило с областью действия, такое как Bash(rm *), оставляет инструмент доступным и блокирует совпадающие вызовы, когда Claude пытается их выполнить.
Режимы разрешений
Claude Code поддерживает несколько режимов разрешений, которые контролируют, как он одобряет вызовы инструментов. См. Permission modes для определения того, когда использовать каждый из них. Установите defaultMode в ваших файлах параметров:
| Режим | Описание |
|---|---|
default |
Стандартное поведение: запрашивает разрешение при первом использовании каждого инструмента |
acceptEdits |
Автоматически принимает редактирование файлов и общие команды файловой системы, такие как mkdir, touch, mv и cp для путей в рабочем каталоге или additionalDirectories |
plan |
Plan Mode: Claude читает файлы и запускает команды оболочки только для чтения для исследования, но не редактирует ваши исходные файлы |
auto |
Автоматически одобряет вызовы инструментов с проверками безопасности в фоне, которые проверяют, соответствуют ли действия вашему запросу. В настоящее время исследовательский предпросмотр |
dontAsk |
Автоматически отклоняет инструменты, если они не предварительно одобрены через /permissions или правила permissions.allow |
bypassPermissions |
Пропускает запросы разрешений, за исключением тех, которые вынуждены явными правилами ask. Удаления корневого каталога и домашнего каталога, такие как rm -rf /, также по-прежнему запрашивают подтверждение в качестве защиты от ошибок модели |
Чтобы предотвратить использование режима 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). Правило совпадает, когда 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 модели. Запустите с--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 поддерживают glob-шаблоны с *. Подстановочные символы могут появляться в любой позиции команды. Эта конфигурация позволяет npm и git commit команды, блокируя git push:
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git commit *)",
"Bash(git * main)",
"Bash(* --version)",
"Bash(* --help *)"
],
"deny": [
"Bash(git push *)"
]
}
}
Пробел перед * имеет значение: Bash(ls *) совпадает с ls -la, но не с lsof, в то время как Bash(ls*) совпадает с обоими. Суффикс :* - это эквивалентный способ написания завершающего подстановочного символа, поэтому Bash(ls:*) совпадает с теми же командами, что и Bash(ls *).
Диалог разрешений записывает форму, разделенную пробелами, когда вы выбираете "Да, не спрашивать снова" для префикса команды. Форма :* распознается только в конце шаблона. В шаблоне, таком как Bash(git:* push), двоеточие рассматривается как буквальный символ и не будет совпадать с git командами.
Подстановочные символы имён инструментов
Правила отказа и запроса также принимают glob-шаблоны в позиции имени инструмента. Шаблон должен совпадать с полным именем инструмента: "*" совпадает с каждым инструментом, и "mcp__*" совпадает с каждым MCP инструментом на всех серверах. Инструмент, совпадающий с правилом отказа с простым именем glob, удаляется из контекста Claude, так же как и простое имя инструмента. Эта конфигурация отрицает каждый MCP инструмент:
{
"permissions": {
"deny": [
"mcp__*"
]
}
}
Правила разрешения принимают glob-шаблоны имён инструментов только после буквального префикса mcp__<server>__. Сегмент сервера должен быть свободен от glob, поэтому правило называет конкретный сервер, который вы настроили. mcp__puppeteer__* совпадает с каждым инструментом с сервера puppeteer, и mcp__github__get_* совпадает с его инструментами get_. Неякорированный glob разрешения, такой как "*", "B*" или "mcp__*", пропускается с предупреждением и не одобряет ничего автоматически.
Правило отказа или запроса, имя инструмента которого не совпадает ни с одним известным инструментом, выдает предупреждение при запуске, чтобы поймать опечатки. Имена инструментов, содержащие _ или *, освобождаются от проверки.
Метка, отображаемая для инструмента в стенограмме и диалоге разрешений, может отличаться от его канонического имени. Например, инструмент с меткой Stop Task в стенограмме имеет каноническое имя TaskStop. Правила разрешений и матчеры hook совпадают только с каноническим именем, поэтому правило, написанное как Stop Task, не совпадает. Для правил отказа и запроса предупреждение при запуске выше ловит несоответствие. Используйте канонические имена, указанные в справочнике инструментов.
Правила разрешений для конкретных инструментов
Bash
Правила разрешений Bash поддерживают сопоставление подстановочных символов с *. Подстановочные символы могут появляться в любой позиции команды, включая начало, середину или конец:
Bash(npm run build)совпадает с точной Bash командойnpm run buildBash(npm run test *)совпадает с Bash командами, начинающимися сnpm run testBash(npm *)совпадает с любой командой, начинающейся сnpmBash(* install)совпадает с любой командой, заканчивающейся наinstallBash(git * main)совпадает с командами, такими какgit checkout mainиgit log --oneline main
Один * совпадает с любой последовательностью символов, включая пробелы, поэтому один подстановочный символ может охватывать несколько аргументов. Bash(git *) совпадает с git log --oneline --all, и Bash(git * main) совпадает с git push origin main, а также с git merge main.
Когда * появляется в конце с пробелом перед ним (например Bash(ls *)), это обеспечивает границу слова, требуя, чтобы префиксу предшествовал пробел или конец строки. Например, Bash(ls *) совпадает с ls -la, но не с lsof. В отличие от этого, Bash(ls*) без пробела совпадает с обоими ls -la и lsof, потому что нет ограничения границы слова.
Составные команды
Когда вы одобряете составную команду с "Да, не спрашивать снова", 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.
Голый 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, такие как watch, setsid, ionice и flock, всегда запрашивают и не могут быть автоматически одобрены правилом префикса, таким как Bash(watch *). То же самое применяется к find с -exec или -delete: правило Bash(find *) не охватывает эти формы. Чтобы одобрить конкретный вызов, напишите правило точного совпадения для полной строки команды.
Команды только для чтения
Claude Code распознает встроенный набор Bash команд как только для чтения и запускает их без запроса разрешения в каждом режиме. Они включают ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd и формы git только для чтения. Набор не настраивается; чтобы требовать запрос для одной из этих команд, добавьте правило ask или deny для нее.
Неквотированные glob-шаблоны разрешены для команд, у которых каждый флаг только для чтения, поэтому ls *.ts и wc -l src/*.py запускаются без запроса. Команды с флагами, способными к записи или выполнению, такие как find, sort, sed и git, по-прежнему запрашивают, когда присутствует неквотированный glob, потому что glob может расширяться до флага, такого как -delete.
cd в путь внутри вашего рабочего каталога или дополнительного каталога также только для чтения. Составная команда, такая как cd packages/api && ls, запускается без запроса, когда каждая часть квалифицируется самостоятельно. Объединение cd с git в одну составную команду всегда запрашивает, независимо от целевого каталога.
PowerShell
Правила разрешений PowerShell используют ту же форму, что и правила Bash. Подстановочные символы с * совпадают в любой позиции, суффикс :* эквивалентен конечному *, и голый PowerShell или PowerShell(*) совпадает с каждой командой. Эта конфигурация позволяет команды Get-ChildItem и git commit, блокируя Remove-Item:
{
"permissions": {
"allow": [
"PowerShell(Get-ChildItem *)",
"PowerShell(git commit *)"
],
"deny": [
"PowerShell(Remove-Item *)"
]
}
}
Общие псевдонимы канонизируются перед сопоставлением. Правило, написанное для имени cmdlet, также совпадает с его псевдонимами, поэтому PowerShell(Get-ChildItem *) совпадает с gci, ls и dir. Сопоставление не чувствительно к регистру.
Claude Code анализирует AST PowerShell и проверяет каждую команду в составной команде независимо. Операторы конвейера |, разделители операторов ; и на PowerShell 7+ операторы цепочки && и || разделяют составную команду на подкоманды. Правило должно совпадать с каждой подкомандой, чтобы составная команда была разрешена.
Read и Edit
Правила Edit применяются ко всем встроенным инструментам, которые редактируют файлы. Claude прилагает наилучшие усилия для применения правил Read ко всем встроенным инструментам, которые читают файлы, таким как Grep и Glob, к упоминаниям @file в ваших подсказках и к выделению и контексту открытого файла, которые подключенный IDE делится с Claude.
Правила Read и Edit следуют спецификации gitignore с четырьмя различными типами шаблонов:
| Шаблон | Значение | Пример | Совпадает |
|---|---|---|---|
//path |
Абсолютный путь от корня файловой системы | Read(//Users/alice/secrets/**) |
/Users/alice/secrets/** |
~/path |
Путь от домашнего каталога | Read(~/Documents/*.pdf) |
/Users/alice/Documents/*.pdf |
/path |
Путь относительно корня проекта | Edit(/src/**/*.ts) |
<project root>/src/**/*.ts |
path или ./path |
Путь относительно текущего каталога | Read(*.env) |
<cwd>/*.env |
На Windows пути нормализуются в форму POSIX перед сопоставлением. C:\Users\alice становится /c/Users/alice, поэтому используйте //c/**/.env для сопоставления файлов .env в любом месте на этом диске. Чтобы сопоставить все диски, используйте //**/.env.
Примеры:
Edit(/docs/**): редактирование в<project>/docs/, не в/docs/или<project>/.claude/docs/Read(~/.zshrc): чтение.zshrcвашего домашнего каталогаEdit(//tmp/scratch.txt): редактирование абсолютного пути/tmp/scratch.txtRead(src/**): чтение из<current-directory>/src/
Правило совпадает только с файлами под его якорем, поэтому якорь определяет, насколько далеко распространяется правило deny. Голые имена файлов следуют семантике gitignore и совпадают на любой глубине, поэтому Read(.env) и Read(**/.env) эквивалентны:
| Правило deny | Блокирует | Не блокирует |
|---|---|---|
Read(.env) или Read(**/.env) |
любой .env в текущем каталоге или под ним |
.env в родительском каталоге или другом проекте |
Read(//**/.env) |
любой .env в любом месте файловой системы |
ничего; правило привязано к корню файловой системы |
Когда Claude получает доступ к символической ссылке, правила разрешений проверяют два пути: саму символическую ссылку и файл, на который она указывает. Правила allow и deny обрабатывают эту пару по-разному: правила allow возвращаются к запросу вас, в то время как правила deny блокируют полностью.
- Правила allow: применяются только когда совпадают как путь символической ссылки, так и его цель. Символическая ссылка внутри разрешенного каталога, которая указывает вне его, по-прежнему запрашивает вас.
- Правила deny: применяются когда совпадает либо путь символической ссылки, либо его цель. Символическая ссылка, которая указывает на запрещенный файл, сама запрещена.
Например, с Read(./project/**) разрешено и Read(~/.ssh/**) запрещено, символическая ссылка в ./project/key, указывающая на ~/.ssh/id_rsa, блокируется: цель не проходит правило allow и совпадает с правилом deny.
WebFetch
Правила WebFetch используют префикс domain: и совпадают с именем хоста запрашиваемого URL. Сопоставление не чувствительно к регистру, поддерживает подстановочные символы * и удаляет конечную точку из правила и имени хоста, поэтому example.com. и example.com рассматриваются одинаково.
WebFetch(domain:example.com)совпадает с запросами наexample.comWebFetch(domain:*.example.com)совпадает с любым поддоменом на любой глубине, таким какapi.example.comилиa.b.example.com, но не с самимexample.comWebFetch(domain:*)совпадает с каждым доменом и эквивалентен голому правилуWebFetch
В любой позиции, отличной от ведущего *. или голого *, подстановочный символ совпадает только с текстом между двумя точками. WebFetch(domain:example.*) совпадает с example.org, где * становится org, но не с example.evil.com, где * должен был бы стать evil.com и пересечь точку. Это предотвращает совпадение конечного подстановочного символа с доменами, которые может зарегистрировать злоумышленник.
MCP
Правила MCP используют имя сервера, настроенное в Claude Code, опционально за которым следует имя инструмента с этого сервера.
mcp__puppeteerсовпадает с любым инструментом, предоставленным серверомpuppeteermcp__puppeteer__*использует синтаксис подстановочных символов и также совпадает со всеми инструментами с сервераpuppeteermcp__puppeteer__puppeteer_navigateсовпадает с инструментомpuppeteer_navigate, предоставленным серверомpuppeteer
Agent (subagents)
Используйте правила Agent(AgentName) для контроля, какие subagents может использовать Claude:
Agent(Explore)совпадает с subagent ExploreAgent(Plan)совпадает с subagent PlanAgent(my-custom-agent)совпадает с пользовательским subagent с именемmy-custom-agent
Добавьте эти правила в массив deny в ваших параметрах или используйте флаг CLI --disallowedTools для отключения конкретных агентов. Чтобы отключить агент Explore:
{
"permissions": {
"deny": ["Agent(Explore)"]
}
}
Cd
Правила Cd контролируют, в какие каталоги команда /cd может переместить сеанс. Cd не является инструментом, вызываемым моделью: Claude не может его вызвать, и правила применяются только когда вы сами запускаете /cd.
Голое правило Cd deny отключает /cd полностью. Правило Cd(<path-pattern>) deny блокирует совпадающие цели. Правила deny проверяют каждое написание цели, включая каждый переход символической ссылки, через который она разрешается, поэтому правило, написанное для одного пути, также блокирует цели, которые разрешаются в него.
Добавление любого правила Cd allow переключает /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 запускаются перед запросом разрешения. Выход hook может отклонить вызов инструмента, принудить запрос или пропустить запрос, чтобы позволить вызову продолжиться.
Решения hook не обходят правила разрешений. Правила deny и ask оцениваются независимо от того, что возвращает PreToolUse hook, поэтому совпадающее правило deny блокирует вызов и совпадающее правило ask по-прежнему запрашивает даже когда hook вернул "allow" или "ask". Это сохраняет приоритет deny-first, описанный в Управление разрешениями, включая правила deny, установленные в управляемых параметрах.
Блокирующий hook также имеет приоритет над правилами allow. Hook, который выходит с кодом 2, останавливает вызов инструмента перед оценкой правил разрешений, поэтому блокировка применяется даже когда правило allow иначе позволило бы вызову продолжиться. Чтобы запустить все Bash команды без запросов, кроме нескольких, которые вы хотите заблокировать, добавьте "Bash" в список allow и зарегистрируйте PreToolUse hook, который отклоняет эти конкретные команды. См. Блокировка редактирования защищённых файлов для скрипта hook, который вы можете адаптировать.
Рабочие каталоги
По умолчанию Claude имеет доступ к файлам в каталоге, где он был запущен. Вы можете расширить этот доступ:
- При запуске: используйте аргумент CLI
--add-dir <path> - Во время сеанса: используйте команду
/add-dir - Постоянная конфигурация: добавьте в
additionalDirectoriesв файлы параметров
Файлы в дополнительных каталогах следуют тем же правилам разрешений, что и исходный рабочий каталог: они становятся читаемыми без запросов, и разрешения на редактирование файлов следуют текущему режиму разрешений.
Чтобы изменить основной рабочий каталог сеанса вместо добавления другого, используйте /cd. Команда /cd требует Claude Code версии 2.1.169 или позже. В отличие от /add-dir, она перемещает сеанс: загружается CLAUDE.md нового каталога и --resume находит сеанс оттуда.
Дополнительные каталоги предоставляют доступ к файлам, а не конфигурацию
Добавление каталога расширяет, где Claude может читать и редактировать файлы. Это не делает этот каталог полным корнем конфигурации: большинство конфигурации .claude/ не обнаруживается из дополнительных каталогов, хотя несколько типов загружаются как исключения.
Эти исключения применяются только к каталогам, добавленным с флагом --add-dir или командой /add-dir. Каталоги, указанные в permissions.additionalDirectories в файле параметров, предоставляют доступ только к файлам и не загружают никакую конфигурацию ниже.
Следующие типы конфигурации загружаются из каталогов --add-dir:
| Конфигурация | Загружается из --add-dir |
|---|---|
Skills в .claude/skills/ |
Да, с live reload |
Subagents в .claude/agents/ |
Да |
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, который включен по умолчанию |
Команды и стили вывода обнаруживаются из текущего рабочего каталога и его родителей, вашего пользовательского каталога в ~/.claude/ и управляемых параметров. Hooks и другие ключи settings.json загружаются из папки .claude/ текущего рабочего каталога без резервного варианта для родительского каталога, наряду с вашим пользовательским файлом ~/.claude/settings.json и управляемыми параметрами. Чтобы поделиться этой конфигурацией между проектами, используйте один из этих подходов:
- Конфигурация на уровне пользователя: поместите файлы в
~/.claude/agents/,~/.claude/output-styles/или~/.claude/settings.json, чтобы сделать их доступными в каждом проекте - Плагины: упакуйте и распространяйте конфигурацию как плагин, который команды могут установить
- Запуск из каталога конфигурации: запустите Claude Code из каталога, содержащего конфигурацию
.claude/, которую вы хотите использовать
Как разрешения взаимодействуют с sandboxing
Разрешения и sandboxing являются дополняющими уровнями безопасности:
- Разрешения контролируют, какие инструменты может использовать Claude Code и какие файлы или домены он может использовать. Они применяются ко всем инструментам, включая Bash, Read, Edit, WebFetch и MCP.
- Sandboxing обеспечивает принудительное применение на уровне ОС, которое ограничивает доступ инструмента Bash к файловой системе и сети. Это применяется только к Bash командам и их дочерним процессам.
Используйте оба для защиты в глубину:
- Правила deny разрешений блокируют Claude от попытки доступа к ограниченным ресурсам
- Ограничения sandbox предотвращают Bash команды от доступа к ресурсам вне определенных границ, даже если инъекция подсказки обходит принятие решений Claude
- Ограничения файловой системы в sandbox объединяют параметры
sandbox.filesystemс правилами deny для Read и Edit; оба объединяются в финальную границу sandbox - Ограничения сети объединяют правила разрешений WebFetch со списками
allowedDomainsиdeniedDomainssandbox
Когда sandboxing включен с autoAllowBashIfSandboxed: true, что является значением по умолчанию, sandboxed Bash команды запускаются без запроса даже если ваши разрешения включают простое правило ask Bash, или эквивалентную форму Bash(*) (#match-all-uses-of-a-tool): граница sandbox заменяет этот запрос для всего инструмента. Эти проверки по-прежнему применяются:
- Правила ask с областью действия контента, такие как
Bash(git push *), по-прежнему вызывают запрос - Явные правила deny по-прежнему применяются
- Команды
rmилиrmdir, которые нацелены на/, ваш домашний каталог или другие критические пути системы, по-прежнему вызывают запрос
Команды, которые не будут запущены в sandboxed режиме, такие как исключенные команды, соблюдают простое правило ask Bash как обычно. См. sandbox modes для изменения этого поведения.
Управляемые параметры
Для организаций, которым требуется централизованный контроль над конфигурацией Claude Code, администраторы могут развернуть управляемые параметры, которые не могут быть переопределены параметрами пользователя или проекта. Эти параметры политики следуют тому же формату, что и обычные файлы параметров, и могут быть доставлены через политики MDM/уровня ОС, управляемые файлы параметров, параметры, управляемые сервером, или самостоятельно размещаемый Claude apps gateway. См. файлы параметров для механизмов доставки и расположения файлов.
Параметры только для управления
Следующие параметры эффективны только в управляемых параметрах. Размещение их в файлах параметров пользователя или проекта не имеет эффекта.
| Параметр | Описание |
|---|---|
allowAllClaudeAiMcps |
Когда true, соединители claude.ai загружаются вместе с развернутым managed-mcp.json вместо того, чтобы быть подавленными его исключительным контролем. См. Управляемая конфигурация MCP |
allowedChannelPlugins |
Список разрешений плагинов канала, которые могут отправлять сообщения. Заменяет список разрешений Anthropic по умолчанию при установке. Требует channelsEnabled: true. См. Ограничение того, какие плагины канала могут работать |
allowManagedHooksOnly |
Когда true, только управляемые hooks, SDK hooks и hooks из плагинов, принудительно включенных в управляемых параметрах enabledPlugins, загружаются. Hooks пользователя, проекта и всех остальных плагинов блокируются |
allowManagedMcpServersOnly |
Когда true, только allowedMcpServers из управляемых параметров учитываются. deniedMcpServers все еще объединяется из всех источников. См. Управляемая конфигурация MCP |
allowManagedPermissionRulesOnly |
Когда true, предотвращает определение правил разрешений allow, ask или deny в параметрах пользователя и проекта. Применяются только правила в управляемых параметрах. Не влияет на список разрешений сервера MCP; для этого установите allowManagedMcpServersOnly |
blockedMarketplaces |
Список блокировки источников marketplace. Заблокированные источники проверяются перед загрузкой, поэтому они никогда не касаются файловой системы. См. управляемые ограничения marketplace |
channelsEnabled |
Разрешить channels для организации. См. элементы управления предприятием для значения по умолчанию на каждом плане |
disableSideloadFlags |
{/* min-version: 2.1.193 */}Отклонить флаги CLI --plugin-dir, --plugin-url, --agents и --mcp-config при запуске. Без этого пользователи могут обойти strictKnownMarketplaces для одного запуска, передав эти флаги. См. disableSideloadFlags. Требуется Claude Code v2.1.193 или позже |
forceRemoteSettingsRefresh |
Когда true, блокирует запуск CLI до тех пор, пока удаленные управляемые параметры не будут свежо получены, и выходит, если получение не удается. См. принудительное закрытие при запуске |
pluginTrustMessage |
Пользовательское сообщение, добавленное к предупреждению о доверии плагина, показываемому перед установкой |
sandbox.filesystem.allowManagedReadPathsOnly |
Когда true, только пути filesystem.allowRead из управляемых параметров учитываются. denyRead все еще объединяется из всех источников |
sandbox.network.allowManagedDomainsOnly |
Когда true, только allowedDomains и правила WebFetch(domain:...) allow из управляемых параметров учитываются. Недопустимые домены блокируются автоматически без запроса пользователю. Запрещенные домены все еще объединяются из всех источников |
strictKnownMarketplaces |
Контролирует, какие источники marketplace плагинов пользователи могут добавлять и устанавливать плагины из. См. управляемые ограничения marketplace |
strictPluginOnlyCustomization |
Блокирует skills, agents, hooks и MCP servers из источников пользователя и проекта, поэтому они могут поступать только из плагинов или управляемых параметров. true блокирует все четыре поверхности; массив, такой как ["skills", "hooks"], блокирует только названные. См. strictPluginOnlyCustomization |
wslInheritsWindowsSettings |
Когда true в ключе реестра Windows HKLM или C:\Program Files\ClaudeCode\managed-settings.json, WSL читает управляемые параметры из цепочки политики Windows в дополнение к /etc/claude-code. См. Файлы параметров |
disableBypassPermissionsMode обычно размещается в управляемых параметрах для обеспечения организационной политики, но работает из любой области. Пользователь может установить его в своих собственных параметрах, чтобы заблокировать себя из режима bypass.
Приоритет параметров
Правила разрешений следуют тому же приоритету параметров, что и все остальные параметры Claude Code:
- Управляемые параметры: не могут быть переопределены никаким другим уровнем, включая аргументы командной строки
- Аргументы командной строки: временные переопределения сеанса
- Локальные параметры проекта (
.claude/settings.local.json) - Общие параметры проекта (
.claude/settings.json) - Параметры пользователя (
~/.claude/settings.json)
Если инструмент запрещен на любом уровне, никакой другой уровень не может его разрешить. Например, управляемый параметр deny не может быть переопределен --allowedTools, и --disallowedTools может добавить ограничения сверх того, что определяют управляемые параметры.
То же самое применяется и к областям параметров: если параметры пользователя разрешают разрешение, а параметры проекта его запрещают, правило запрета блокирует его. Обратное также верно: запрет на уровне пользователя блокирует разрешение на уровне проекта, потому что правила запрета из любой области оцениваются перед правилами разрешения.
Хосты встраивания могут предоставлять дополнительную управляемую политику через опцию SDK managedSettings когда parentSettingsBehavior установлен на "merge"; значения встраивающей стороны могут ужесточить политику, но не ослабить её.
Примеры конфигураций
Этот репозиторий включает начальные конфигурации параметров для распространенных сценариев развертывания. Используйте их как отправные точки и настройте их в соответствии с вашими потребностями.
См. также
- Settings: полный справочник конфигурации, включая таблицу параметров разрешений
- Configure auto mode: скажите классификатору режима auto, какую инфраструктуру ваша организация доверяет
- Sandboxing: изоляция файловой системы и сети на уровне ОС для Bash команд
- Authentication: настройка доступа пользователей к Claude Code
- Security: гарантии безопасности и лучшие практики
- Hooks: автоматизация рабочих процессов и расширение оценки разрешений