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

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

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

Claude Code использует многоуровневую систему разрешений для баланса между мощностью и безопасностью:

Тип инструмента	Пример	Требуется одобрение	Поведение “Да, не спрашивать снова”
Только чтение	Чтение файлов, Grep	Нет	Н/А
Bash команды	Выполнение оболочки	Да	Постоянно для каждого каталога проекта и команды
Изменение файлов	Редактирование/запись файлов	Да	До конца сеанса

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

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

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

Правила оцениваются по порядку: deny -> ask -> allow. Первое совпадающее правило побеждает, поэтому правила deny всегда имеют приоритет.

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

Claude Code поддерживает несколько режимов разрешений, которые контролируют, как инструменты одобряются. См. Permission modes для определения того, когда использовать каждый из них. Установите defaultMode в ваших файлах параметров:

Режим	Описание
`default`	Стандартное поведение: запрашивает разрешение при первом использовании каждого инструмента
`acceptEdits`	Автоматически принимает разрешения на редактирование файлов для сеанса
`plan`	Plan Mode: Claude может анализировать, но не может изменять файлы или выполнять команды
`auto`	Автоматически одобряет вызовы инструментов с проверками безопасности в фоне, которые проверяют, соответствуют ли действия вашему запросу. В настоящее время исследовательский предпросмотр
`dontAsk`	Автоматически отклоняет инструменты, если они не предварительно одобрены через `/permissions` или правила `permissions.allow`
`bypassPermissions`	Пропускает запросы разрешений, кроме записей в защищенные каталоги (см. предупреждение ниже)

Режим bypassPermissions пропускает запросы разрешений. Записи в каталоги .git, .claude, .vscode и .idea по-прежнему запрашивают подтверждение, чтобы предотвратить случайное повреждение состояния репозитория и локальной конфигурации. Записи в .claude/commands, .claude/agents и .claude/skills исключены и не запрашивают подтверждение, потому что Claude регулярно пишет туда при создании skills, subagents и commands. Используйте этот режим только в изолированных средах, таких как контейнеры или виртуальные машины, где Claude Code не может причинить вред. Администраторы могут предотвратить этот режим, установив disableBypassPermissionsMode на "disable" в управляемых параметрах.

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

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

Правила разрешений следуют формату Tool или Tool(specifier).

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

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

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

Bash(*) эквивалентен Bash и совпадает со всеми Bash командами.

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

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

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

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

Правила 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

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

Bash(npm run build) совпадает с точной Bash командой npm run build
Bash(npm run test *) совпадает с Bash командами, начинающимися с npm run test
Bash(npm *) совпадает с любой командой, начинающейся с npm
Bash(* install) совпадает с любой командой, заканчивающейся на install
Bash(git * main) совпадает с командами, такими как git checkout main, git merge main

Когда * появляется в конце с пробелом перед ним (например Bash(ls *)), это обеспечивает границу слова, требуя, чтобы префиксу предшествовал пробел или конец строки. Например, Bash(ls *) совпадает с ls -la, но не с lsof. В отличие от этого, Bash(ls*) без пробела совпадает с обоими ls -la и lsof, потому что нет ограничения границы слова.

Claude Code осведомлен об операторах оболочки (например &&), поэтому правило сопоставления префикса, такое как Bash(safe-cmd *), не даст ему разрешение на выполнение команды safe-cmd && other-cmd.

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

Шаблоны разрешений Bash, которые пытаются ограничить аргументы команды, хрупкие. Например, Bash(curl http://github.com/ *) предназначен для ограничения curl на URL-адреса GitHub, но не будет совпадать с вариациями, такими как:

Опции перед URL: curl -X GET http://github.com/...
Другой протокол: curl https://github.com/...
Перенаправления: curl -L http://bit.ly/xyz (перенаправляет на github)
Переменные: URL=http://github.com && curl $URL
Дополнительные пробелы: curl http://github.com

Для более надежной фильтрации URL рассмотрите:

Ограничение сетевых инструментов Bash: используйте правила deny для блокировки curl, wget и подобных команд, затем используйте инструмент WebFetch с разрешением WebFetch(domain:github.com) для разрешенных доменов
Использование PreToolUse hooks: реализуйте hook, который проверяет URL-адреса в Bash командах и блокирует недопустимые домены
Инструктирование Claude Code о ваших разрешенных curl шаблонах через CLAUDE.md

Обратите внимание, что использование только WebFetch не предотвращает сетевой доступ. Если Bash разрешен, Claude все еще может использовать curl, wget или другие инструменты для доступа к любому URL-адресу.

Read и Edit

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

Правила Read и Edit deny применяются к встроенным инструментам файлов Claude, а не к подпроцессам Bash. Правило deny Read(./.env) блокирует инструмент Read, но не предотвращает cat .env в Bash. Для принудительного применения на уровне ОС, которое блокирует все процессы от доступа к пути, включите sandbox.

Правила 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`

Шаблон, такой как /Users/alice/file, НЕ является абсолютным путем. Это относительно корня проекта. Используйте //Users/alice/file для абсолютных путей.

На 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.txt
Read(src/**): чтение из <current-directory>/src/

В шаблонах gitignore * совпадает с файлами в одном каталоге, а ** совпадает рекурсивно по каталогам. Чтобы разрешить весь доступ к файлам, используйте только имя инструмента без скобок: Read, Edit или Write.

WebFetch

WebFetch(domain:example.com) совпадает с запросами выборки на example.com

MCP

mcp__puppeteer совпадает с любым инструментом, предоставленным сервером puppeteer (имя настроено в Claude Code)
mcp__puppeteer__* синтаксис подстановочных символов, который также совпадает со всеми инструментами с сервера puppeteer
mcp__puppeteer__puppeteer_navigate совпадает с инструментом puppeteer_navigate, предоставленным сервером puppeteer

Agent (subagents)

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

Agent(Explore) совпадает с subagent Explore
Agent(Plan) совпадает с subagent Plan
Agent(my-custom-agent) совпадает с пользовательским subagent с именем my-custom-agent

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

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

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

Claude Code hooks предоставляют способ регистрации пользовательских команд оболочки для выполнения оценки разрешений во время выполнения. Когда Claude Code выполняет вызов инструмента, PreToolUse hooks запускаются перед запросом разрешения. Выход hook может отклонить вызов инструмента, принудить запрос или пропустить запрос, чтобы позволить вызову продолжиться. Пропуск запроса не обходит правила разрешений. Правила deny и ask все еще оцениваются после того, как hook возвращает "allow", поэтому совпадающее правило deny все еще блокирует вызов. Это сохраняет приоритет deny-first, описанный в Управление разрешениями, включая правила deny, установленные в управляемых параметрах. Блокирующий hook также имеет приоритет над правилами allow. Hook, который выходит с кодом 2, останавливает вызов инструмента перед оценкой правил разрешений, поэтому блокировка применяется даже когда правило allow иначе позволило бы вызову продолжиться. Чтобы запустить все Bash команды без запросов, кроме нескольких, которые вы хотите заблокировать, добавьте "Bash" в список allow и зарегистрируйте PreToolUse hook, который отклоняет эти конкретные команды. См. Block edits to protected files для скрипта hook, который вы можете адаптировать.

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

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

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

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

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

Разрешения и sandboxing являются дополняющими уровнями безопасности:

Разрешения контролируют, какие инструменты может использовать Claude Code и какие файлы или домены он может использовать. Они применяются ко всем инструментам (Bash, Read, Edit, WebFetch, MCP и другим).
Sandboxing обеспечивает принудительное применение на уровне ОС, которое ограничивает доступ инструмента Bash к файловой системе и сети. Это применяется только к Bash командам и их дочерним процессам.

Используйте оба для защиты в глубину:

Правила deny разрешений блокируют Claude от попытки доступа к ограниченным ресурсам
Ограничения sandbox предотвращают Bash команды от доступа к ресурсам вне определенных границ, даже если инъекция подсказки обходит принятие решений Claude
Ограничения файловой системы в sandbox используют правила Read и Edit deny, а не отдельную конфигурацию sandbox
Ограничения сети объединяют правила разрешений WebFetch со списком allowedDomains sandbox

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

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

Параметры только для управления

Некоторые параметры эффективны только в управляемых параметрах:

Параметр	Описание
`allowManagedPermissionRulesOnly`	Когда `true`, предотвращает определение правил разрешений `allow`, `ask` или `deny` в параметрах пользователя и проекта. Применяются только правила в управляемых параметрах
`allowManagedHooksOnly`	Когда `true`, предотвращает загрузку hooks пользователя, проекта и плагина. Разрешены только управляемые hooks и SDK hooks
`allowManagedMcpServersOnly`	Когда `true`, только `allowedMcpServers` из управляемых параметров учитываются. `deniedMcpServers` все еще объединяется из всех источников. См. Managed MCP configuration
`blockedMarketplaces`	Список блокировки источников marketplace. Заблокированные источники проверяются перед загрузкой, поэтому они никогда не касаются файловой системы. См. managed marketplace restrictions
`sandbox.network.allowManagedDomainsOnly`	Когда `true`, только `allowedDomains` и правила `WebFetch(domain:...)` allow из управляемых параметров учитываются. Недопустимые домены блокируются автоматически без запроса пользователю. Запрещенные домены все еще объединяются из всех источников
`sandbox.filesystem.allowManagedReadPathsOnly`	Когда `true`, только пути `allowRead` из управляемых параметров учитываются. Записи `allowRead` из параметров пользователя, проекта и локальных параметров игнорируются
`strictKnownMarketplaces`	Контролирует, какие marketplace плагинов могут добавлять пользователи. См. managed marketplace restrictions

Доступ к Remote Control и веб-сеансам не контролируется ключом управляемых параметров. На планах Team и Enterprise администратор включает или отключает эти функции в Claude Code admin settings.

Настройка классификатора режима auto

Auto mode использует модель классификатора для определения того, безопасно ли запускать каждое действие без запроса. Из коробки он доверяет только рабочему каталогу и, если присутствует, удаленным репозиториям текущего репо. Действия, такие как push в организацию управления исходным кодом вашей компании или запись в командный облачный bucket, будут заблокированы как потенциальная утечка данных. Блок параметров autoMode позволяет вам сказать классификатору, какую инфраструктуру доверяет ваша организация. Классификатор читает autoMode из параметров пользователя, .claude/settings.local.json и управляемых параметров. Он не читает из общих параметров проекта в .claude/settings.json, потому что проверенный репо иначе мог бы внедрить свои собственные правила allow.

Область	Файл	Использование для
Один разработчик	`~/.claude/settings.json`	Личная доверенная инфраструктура
Один проект, один разработчик	`.claude/settings.local.json`	Доверенные buckets или сервисы для каждого проекта, gitignored
Организация-широко	Управляемые параметры	Доверенная инфраструктура, применяемая для всех разработчиков

Записи из каждой области объединяются. Разработчик может расширить environment, allow и soft_deny личными записями, но не может удалить записи, которые предоставляют управляемые параметры. Потому что правила allow действуют как исключения к правилам блокировки внутри классификатора, запись allow, добавленная разработчиком, может переопределить запись организации soft_deny: комбинация является аддитивной, а не жесткой границей политики. Если вам нужно правило, которое разработчики не могут обойти, используйте permissions.deny в управляемых параметрах вместо этого, что блокирует действия перед консультацией классификатора.

Определение доверенной инфраструктуры

Для большинства организаций autoMode.environment - это единственное поле, которое вам нужно установить. Это говорит классификатору, какие репо, buckets и домены доверены, без касания встроенных правил блокировки и разрешения. Классификатор использует environment для определения того, что означает “внешний”: любой пункт назначения, не указанный в списке, является потенциальной целью утечки данных.

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

Записи являются прозой, а не regex или шаблонами инструментов. Классификатор читает их как правила на естественном языке. Напишите их так, как вы описали бы вашу инфраструктуру новому инженеру. Тщательный раздел environment охватывает:

Организация: название вашей компании и для чего Claude Code в основном используется, например разработка программного обеспечения, автоматизация инфраструктуры или инженерия данных
Управление исходным кодом: каждая организация GitHub, GitLab или Bitbucket, в которую ваши разработчики push
Облачные провайдеры и доверенные buckets: имена buckets или префиксы, которые Claude должен иметь возможность читать и писать
Доверенные внутренние домены: имена хостов для API, панелей управления и сервисов внутри вашей сети, например *.internal.example.com
Ключевые внутренние сервисы: CI, реестры артефактов, внутренние индексы пакетов, инструменты инцидентов
Дополнительный контекст: ограничения регулируемой отрасли, многопользовательская инфраструктура или требования соответствия, которые влияют на то, что классификатор должен рассматривать как рискованное

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

{
  "autoMode": {
    "environment": [
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}

Чем более специфичный контекст вы предоставляете, тем лучше классификатор может различать обычные внутренние операции и попытки утечки данных. Вам не нужно заполнять все сразу. Разумный rollout: начните с значений по умолчанию и добавьте организацию управления исходным кодом и ключевые внутренние сервисы, что решает наиболее распространенные ложные срабатывания, такие как push в ваши собственные репо. Затем добавьте доверенные домены и облачные buckets. Заполните остальное по мере появления блокировок.

Переопределение правил блокировки и разрешения

Два дополнительных поля позволяют вам заменить встроенные списки правил классификатора: autoMode.soft_deny контролирует, что получает блокировку, и autoMode.allow контролирует, какие исключения применяются. Каждое является массивом описаний прозы, читаемых как правила на естественном языке. Внутри классификатора приоритет: правила soft_deny блокируют первыми, затем правила allow переопределяют как исключения, затем явное намерение пользователя переопределяет оба. Если сообщение пользователя прямо и конкретно описывает точное действие, которое Claude собирается выполнить, классификатор позволяет это даже если правило soft_deny совпадает. Общие запросы не считаются: просьба Claude “очистить репо” не авторизует force-push, но просьба Claude “force-push этот branch” авторизует. Чтобы ослабить: удалите правила из soft_deny, когда значения по умолчанию блокируют что-то, что ваш pipeline уже охраняет с помощью PR review, CI или staging окружений, или добавьте в allow, когда классификатор повторно флагирует обычный шаблон, который исключения по умолчанию не охватывают. Чтобы затянуть: добавьте в soft_deny для рисков, специфичных для вашего окружения, которые значения по умолчанию пропускают, или удалите из allow, чтобы удержать исключение по умолчанию к правилам блокировки. Во всех случаях запустите claude auto-mode defaults, чтобы получить полные списки по умолчанию, затем скопируйте и отредактируйте: никогда не начинайте с пустого списка.

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow",
      "...copy full default soft_deny list here first, then add your rules..."
    ]
  }
}

Установка allow или soft_deny заменяет весь список по умолчанию для этого раздела. Если вы установите soft_deny с одной записью, каждое встроенное правило блокировки отбрасывается: force push, утечка данных, curl | bash, production deploys и все остальные правила блокировки по умолчанию становятся разрешены. Чтобы настроить безопасно, запустите claude auto-mode defaults, чтобы напечатать встроенные правила, скопируйте их в файл параметров, затем просмотрите каждое правило против вашего собственного pipeline и допуска риска. Удалите только правила для рисков, которые ваша инфраструктура уже смягчает.

Три раздела оцениваются независимо, поэтому установка только environment оставляет списки allow и soft_deny по умолчанию нетронутыми.

Проверка значений по умолчанию и вашей эффективной конфигурации

Потому что установка allow или soft_deny заменяет значения по умолчанию, начните любую настройку, скопировав полные списки по умолчанию. Три подкоманды CLI помогают вам проверить и валидировать:

claude auto-mode defaults  # the built-in environment, allow, and soft_deny rules
claude auto-mode config    # what the classifier actually uses: your settings where set, defaults otherwise
claude auto-mode critique  # get AI feedback on your custom allow and soft_deny rules

Сохраните выход claude auto-mode defaults в файл, отредактируйте списки, чтобы соответствовать вашей политике, и вставьте результат в файл параметров. После сохранения запустите claude auto-mode config, чтобы подтвердить, что эффективные правила - это то, что вы ожидаете. Если вы написали пользовательские правила, claude auto-mode critique просматривает их и флагирует записи, которые неоднозначны, избыточны или вероятно вызовут ложные срабатывания.

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

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

Управляемые параметры: не могут быть переопределены никаким другим уровнем, включая аргументы командной строки
Аргументы командной строки: временные переопределения сеанса
Локальные параметры проекта (.claude/settings.local.json)
Общие параметры проекта (.claude/settings.json)
Параметры пользователя (~/.claude/settings.json)

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

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

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

См. также

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

Конфигурация

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

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

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

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

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

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

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

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

​Bash

​Read и Edit

​WebFetch

​MCP

​Agent (subagents)

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

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

​Как разрешения взаимодействуют с sandboxing

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

​Параметры только для управления

​Настройка классификатора режима auto

​Определение доверенной инфраструктуры

​Переопределение правил блокировки и разрешения

​Проверка значений по умолчанию и вашей эффективной конфигурации

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

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

​См. также

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

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

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

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

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

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

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

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

Bash

Read и Edit

WebFetch

MCP

Agent (subagents)

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

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

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

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

Параметры только для управления

Настройка классификатора режима auto

Определение доверенной инфраструктуры

Переопределение правил блокировки и разрешения

Проверка значений по умолчанию и вашей эффективной конфигурации

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

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

См. также