CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS: настройка и аудит

Не задавайте переменную CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS на рабочих компьютерах и общих раннерах CI — исполнителях заданий автоматизации. В Claude Code v2.1.311+ она отключает отдельный запрос на подтверждение удаления, причём только в режиме bypassPermissions. Включайте её только в одноразовой изолированной среде, где допустимо потерять любые файлы, доступные для записи.

По состоянию на 2026-10-28 документация Anthropic требует задавать переменную в окружении процесса, который запускает Claude Code. Она не включает bypassPermissions автоматически и не отменяет все остальные проверки.

Почему --dangerously-skip-permissions всё ещё блокирует rm -rf ~?

Проверка критических путей работает отдельно от обычных разрешений на вызов инструментов. Для распознанных команд rm и rmdir Claude Code проверяет, какие каталоги они удалят. Флаг --dangerously-skip-permissions выбирает bypassPermissions, но сам по себе эту проверку не отключает.

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

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

В список критических путей входят:

• Корень файловой системы, например /.
• Каталоги непосредственно под корнем, включая /usr, /etc и /data.
• Домашний каталог, в том числе его короткое имя Windows в формате 8.3, например C:\Users\LONGNA~1.
• Корни дисков Windows и каталоги первого уровня, например C:\ и C:\Windows. Записи корня вида \\?\C:\ и \\localhost\C$ тоже учитываются.
• Рабочий каталог и его родительские каталоги.
• Дополнительные рабочие каталоги и их родительские каталоги, когда цель удаления задана маской внутри них, например rm -rf <dir>/*.

Команда rm -rf <dir> удаляет сам дополнительный каталог и не подпадает под это отдельное правило. При этом может сработать другая проверка: например, если каталог находится непосредственно под корнем файловой системы.

Эта защита действует только для команд, которые Claude Code распознал. Команда, пропущенная при разборе, не получает дополнительной защиты. Другие программы тоже могут удалять файлы, если им разрешено выполнение. Для Remove-Item в PowerShell и команд удаления cmd действуют отдельные проверки.

Как включить переменную для одного изолированного сеанса

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

Нужна установленная консольная версия Claude Code v2.1.311 или новее с настроенной аутентификацией. Выполните проверки в Bash на macOS, Linux или WSL:

claude --version
claude auth status --text

Если проверка аутентификации завершилась ошибкой, используйте claude auth login с разрешённой в вашей команде учётной записью. Если запускается не тот исполняемый файл, проверьте установку Claude Code и переменную PATH. Старую версию обновите перед продолжением.

Запустите нужный сеанс, задав переменную только для одной команды Bash:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions

Так переменную получит этот процесс и его дочерние процессы. В родительской оболочке новое значение не сохранится. Вместо --permission-mode bypassPermissions можно указать --dangerously-skip-permissions.

В изолированной среде запускайте Claude Code от пользователя без прав root. На Linux и macOS режим bypassPermissions обычно не допускает запуск от root или через sudo. Исключение — среда, которую Claude Code распознаёт как песочницу.

Не записывайте переменную в блок env файлов ~/.claude/settings.json, .claude/settings.json или .claude/settings.local.json. Согласно справочнику переменных окружения, Claude Code игнорирует её в этих блоках. Перенос в другой файл настроек не поможет.

Переменная снимает подтверждение только в самом режиме bypassPermissions. В режиме plan она этого не делает. Её действие ограничено проверкой критических путей в инструментах Bash и Monitor. Оно распространяется и на команды, которые эта проверка не может разобрать полностью.

Чтобы убрать ранее экспортированное значение, завершите затронутый сеанс и удалите настройку там, где она задана. Затем выполните unset CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS в оболочке и запустите новый сеанс.

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

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

Для диагностики выполните в Bash внутри изолированной среды:

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions \
  --tools "" --disallowedTools "mcp__*" \
  -p "Reply with READY." 2>claude-startup.log

grep -F 'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' claude-startup.log

Эти флаги CLI отключают встроенные инструменты и запрещают инструменты MCP для диагностического сеанса. Они ограничивают вызовы инструментов моделью. Хуки запуска и расширения по-прежнему загружаются.

Команда просит модель ответить READY в стандартный вывод stdout. Диагностический вывод stderr сохраняется в claude-startup.log. Запрос не просит удалять файлы.

В документации об уведомлениях описаны три варианта:

Фрагмент уведомления	Что он означает
is set, so dangerous rm commands can run without a prompt	Переменная может подействовать после загрузки управляемых настроек организации и хуков плагинов. Другие правила или хуки могут сохранить подтверждение.
has no effect in this session	Обычное подтверждение или отказ сохраняется до конца сеанса. Устраните причину и перезапустите Claude Code.
has no effect while the Windows registry cannot be read for managed settings	Пока не удаётся прочитать реестр, действуют обычные проверки. Если следующее чтение пройдёт успешно, переменная может начать действовать без перезапуска.

В приложении на Agent SDK задайте опцию stderr, чтобы получать уведомление. Если строки нет, это ещё не значит, что подтверждение включено. Проверьте, получил ли процесс переменную при запуске, какой режим активен и не был ли сеанс запущен косвенно.

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

Почему переменная не работает: девять причин

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

Это разные причины, которые нужно проверять по ситуации. Сохраняйте ограничения, которые команда установила намеренно.

Причина	Что проверить и как действовать
1. Подтверждения обрабатывает другой компонент	Проверьте --permission-prompt-tool или обработчик SDK canUseTool, если не указан --permission-prompts none. Также учтите любой хук PermissionRequest, независимо от фильтра, или мод — программное расширение, обрабатывающее это событие. Если обработчик подключён по ошибке, уберите его и перезапустите claude.
2. Сеанс открыт в графическом чате	Переменная не действует в панели чата расширения VS Code и в настольном приложении. Запустите CLI из своего терминала; подойдёт и встроенный терминал IDE.
3. Правило deny или ask относится к Bash, Edit или Read	Любое такое правило отключает действие переменной, даже если не связано с удалением. Когда Claude Code прочитал правило, его удаление уже не включит переменную в этом сеансе. После согласованного изменения правил нужен перезапуск. Чтобы убрать инструмент из доступных, используйте --tools вместо правила deny.
4. Запрещено чтение вне рабочих каталогов	Проверьте permissions.blockReadsOutsideWorkingDirectories. Если это ограничение нужно отключить, удалите настройку во всех файлах, где она равна true, и перезапустите сеанс.
5. Claude Code запущен из другого сеанса	При запуске через инструмент Bash или хук другого сеанса обычные проверки сохраняются. Явное значение переменной в командной строке не поможет. Запускайте claude из своей оболочки. Не рассчитывайте на ограничение вложенных сеансов как на средство изоляции.
6. Хук PreToolUse отвечает ask	Посмотрите, какое решение хук возвращает для удаления. Исправьте непредусмотренный ответ ask. Ответ allow сам по себе не снимает обычную проверку критических путей.
7. Сеанс создан самим Claude Code	Claude Code не передаёт переменную в фоновые сеансы, которые создаёт сам. Это также касается сеансов участников команды агентов в отдельных панелях и сеансов, созданных сервером Remote Control. Если переменная нужна, запустите сеанс в терминале напрямую.
8. Не удалось загрузить управляемые настройки	Попросите администратора исправить источник настроек. Ошибки получения серверных настроек проверьте через claude doctor. Сбой запроса к реестру разобран отдельно ниже.
9. Не удаётся прочитать реестр Windows	Это условие действует в Windows и WSL, даже если WSL не берёт настройки из реестра. Запрос может сбоить при отключённом взаимодействии WSL с Windows, в Windows с неанглийской локализацией или в контейнере на ядре WSL2. Включайте взаимодействие только тогда, когда это допускает политика команды; иначе выполните нужную очистку вручную.

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

Как найти переменную и запретить её в команде

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

Найдите сохранённые значения и добавьте проверку в CI

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

audit_paths=(.)
for audit_path in \
  "$HOME/.bashrc" "$HOME/.bash_profile" "$HOME/.profile" \
  "$HOME/.zshrc" "$HOME/.zprofile" "$HOME/.zshenv"
do
  if [[ -f "$audit_path" ]]; then
    audit_paths+=("$audit_path")
  fi
done

rg -l --hidden --no-ignore -F \
  -g '!.git/**' -g '!node_modules/**' \
  'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' \
  "${audit_paths[@]}"

Сначала просмотрите каждое совпадение: упоминание переменной в документации ещё не означает её экспорт. Дополнительно проверьте подключаемые файлы профиля, скрипты запуска, конфигурацию контейнеров и файлы окружения.

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

В контролируемом скрипте запуска CI добавьте эту проверку на Bash непосредственно перед вызовом Claude Code:

if [[ -n "${CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS+x}" ]]; then
  printf '%s\n' 'Refusing Claude Code launch: critical-path override variable is set.' >&2
  exit 1
fi

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

Запретите bypassPermissions через управляемые настройки

Если команде этот режим не нужен, запретите его централизованной политикой. Переменная не может снять подтверждение без bypassPermissions. Запись в блоке env управляемых настроек не перекроет значение, полученное при запуске.

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

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Если политика распространяется файлом, используйте эти пути:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux и WSL: /etc/claude-code/managed-settings.json
• Windows: C:\Program Files\ClaudeCode\managed-settings.json

Перезапустите Claude Code и выполните /status. В строке Setting sources должен быть нужный источник управляемых настроек. После применения политики новая попытка включить bypassPermissions должна завершиться отказом.

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

Что надёжнее: правила deny или песочница?

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

Сохраняйте полезные правила deny. При этом правила Bash сопоставляют текст команды: Bash(rm *) не охватывает все варианты вызова и другие программы, удаляющие файлы. Проверьте установленные хуки и моды: расширения тоже влияют на решения о разрешениях.

В поддерживаемых средах macOS, Linux и WSL2 добавьте эти настройки песочницы в ту же управляемую политику:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Эта конфигурация запрещает запуск, если песочница недоступна, и не позволяет повторно выполнять команды вне неё. При запуске непосредственно в Windows эта песочница не поддерживается. Поэтому такая политика не даст там запустить Claude Code.

Откройте /sandbox, чтобы проверить итоговые настройки и зависимости. Проверьте excludedCommands и пути, доступные для записи: строгий режим сохраняет исключения для команд. Настройки пользователя и флаг --settings могут расширить некоторые списки.

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

Для автономной работы с более широкой защитой изолируйте весь процесс Claude Code. Используйте контейнер, виртуальную машину или sandbox runtime — среду изоляции процессов. Не монтируйте ценные файлы основной машины с разрешением на запись. Рабочую копию должно быть легко пересоздать.