Безопасность Claude Code: 15 минут настроек против утечки e-mail, паролей и ключей

Коротко (TL;DR)

Чтобы Claude Code не раскрывал e-mail, пароли и ключи, путь секрета наружу надо перекрыть в нескольких местах сразу: обновиться до версии 2.1.317 или новее, закрыть чтение .env deny-правилами, не давать паролю попадать в текст команды, держать .claude/settings.local.json вне git и Docker, а затем проверить свои репозитории сканером. Всё, что уже утекло, — сменить.

• E-mail аккаунта. Начиная с 2.1.317 (3 ноября 2026) встроенная проверка спрашивает, прежде чем e-mail уйдёт в сеть. Она ловит не всё, поэтому ниже есть свой хук.
• «Yes, and don’t ask again». Для Bash-команды это правило навсегда записывается в .claude/settings.local.json — вместе с паролем, если он был в команде.
• Чтение секретов. Read(./.env) в permissions.deny закрывает файл от встроенных инструментов, но не от grep -r и скриптов. Глубже защищает песочница.
• Git. Claude Code прячет свой файл только в глобальном git excludes, поэтому в .gitignore репозитория и в .dockerignore строку нужно добавить самим.
• Аудит и утечка. gitleaks и TruffleHog, плюс ручной поиск: по данным Apiiro, сканеры пропустили 215 из 1 122 файлов. Утёкший ключ сначала отзывают, историю чистят потом.

Все версии, статусы и цифры в статье — на 9 ноября 2026 года. Устройство защитных механизмов, обучение на данных и маскирование учётных данных подробно разобраны в нашем материале о пяти периметрах безопасности Claude Code. Здесь — практический чек-лист по двум свежим историям.

Две утечки ноября 2026: e-mail в User-Agent и пароли на GitHub

В первую неделю ноября 2026 года вокруг Claude Code всплыли две истории. Первая: агент иногда вписывал e-mail вашего аккаунта в заголовок User-Agent, когда сам составлял команду curl, и адрес уходил на чужие сайты. Вторая: кнопка «Yes, and don’t ask again» сохраняла команду целиком, с паролем внутри, в файл проекта, и этот файл тысячами оказывался в публичных репозиториях на GitHub. Вторую историю подтверждает документация Claude Code по разрешениям, первую — changelog версии 2.1.317 и сами разработчики.

У обеих историй одна причина. Агент одновременно видит ваши данные и умеет отправлять их наружу — через сеть или через коммит. Исследователь Саймон Уиллисон называет это «смертельной триадой» (lethal trifecta, 2025): доступ к приватным данным, недоверенный контент и канал связи с внешним миром. Пока у агента есть все три, утечка — вопрос времени. Поэтому каждый пункт чек-листа ниже убирает хотя бы одно ребро: секрет не попадает в контекст, файл не читается, коммит не уходит, утёкшее находится и отзывается.

Сейчас в Нью-Йорке--:--Binance торгует

Binance · Wall Street 24/7Нью-Йорк спит. Рынок — нет24/7Акции США, золото и нефть на Binance — даже ночью и в выходные

NVDATSLAGOLD

Смотреть цены

Масштаб второй истории две компании-вендора сканеров считали по-разному, и цифры не надо смешивать:

Claude Fable 5.2 вышла для всех: на 30% быстрее, $8 за миллион токенов на входе

Замена Claude для кодинга дешёвой моделью: что остаётся от 10× Revolut в цифрах

Claude Fable 5.2 подешевела на 20% — но Anthropic советует начинать с Opus 5.5

GPT-6 Cyber от OpenAI — 948 эксплойтов для Linux, но доступ только по одобрению

Хакеры КНДР отмывают украденное у Binance через самодельные мемкоины на NEAR

• Apiiro (данные собраны 1–3 ноября 2026, исследование опубликовано 5 ноября): 104 185 публичных копий .claude/settings.local.json в 103 617 репозиториях, из них 1 122 файла содержали хотя бы один настоящий секрет — всего 1 379 разных секретов. Эти цифры — по текущим копиям файлов, валидность ключей не проверялась. Старые версии файла Apiiro считала отдельно: в них ещё 734 секрета в 509 репозиториях (по Breach Signal), а вместе с историей, общими настройками и транскриптами набирается 2 539 секретов в 1 994 репозиториях (по Cybersecurity News).
• GitGuardian (январь 2025 — 7 ноября 2026, данные компании): 31 088 разных секретов в этом файле в 23 276 репозиториях за всё время, включая историю коммитов. 5 343 из них работали в момент обнаружения.
• Кто коммитил. По данным Apiiro (это же повторяет GitGuardian), в 539 из 1 105 прослеженных репозиториев с настоящим секретом файл менял коммит, где соавтором стоит сам Claude.

Обе компании продают сканеры секретов, так что у них есть коммерческий интерес к теме. Но механизм утечки описан в официальной документации, и от методики подсчёта он не зависит.

E-mail в User-Agent: обновление, проверка и свой хук на Bash

Почему вообще e-mail попадал в запросы: Anthropic добавила адрес аккаунта в контекст модели для вошедших пользователей, чтобы Claude не выдумывал автора в тегах вроде @author. Когда же Claude сам писал команду curl, он иногда ставил этот адрес как контактный в User-Agent. Так это объяснила сотрудница команды Claude Code Лидия Халли в треде Hacker News 6 ноября 2026 года.

Что понадобится:

• Claude Code версии 2.1.317 или новее;
• утилита jq для хука (без неё хук молча пропускает все команды — проверьте jq --version);
• gitleaks и/или TruffleHog для аудита;
• GitHub CLI (gh) для поиска файла в своих репозиториях.

Что сделать по шагам:

1. Проверьте версию. Выполните claude --version. Если ниже 2.1.317 — обновитесь командой claude update. В changelog версии 2.1.317 от 3 ноября 2026 года записано: добавлена проверка, которая спрашивает разрешения, прежде чем веб- или shell-инструмент отправит e-mail аккаунта в сеть.
2. Не выключайте встроенную проверку. Она называется cc-plugin-privacy, включена по умолчанию и видна в /plugins. Там же её можно отключить — делать этого не нужно.
3. Следите за полным исправлением. Команда пообещала убрать e-mail из контекста модели в следующем релизе «в начале следующей недели». На 9 ноября в changelog до версии 2.1.319 (6 ноября) такого пункта нет, а issue #107757 остаётся открытым. Проверяйте changelog в день, когда читаете эту статью.
4. Не смешивайте рабочий и личный аккаунты. В треде HN советуют не смешивать рабочие и личные аккаунты — это мнение сообщества, а не рекомендация Anthropic. От себя добавим: отдельный адрес под Claude Code снижает цену утечки, если она всё же случится.

Чего встроенная проверка не ловит. По словам самой Халли, она не перехватывает случаи, когда Claude пишет скрипт и запускает его сам: адрес оказывается внутри файла, а не в тексте команды. Кроме того, пользователи сообщают в комментариях к issue, что вариант curl -A на версиях 2.1.318 и 2.1.319 не блокировался. Мы это не воспроизводили, поэтому подаём как жалобу пользователей, а не как факт.

PreToolUse-хук Claude Code, который блокирует ваш e-mail в командах

Хук — это ваша команда, которую Claude Code запускает автоматически перед вызовом инструмента. Механизм документирован: событие PreToolUse получает на вход JSON, для Bash в поле tool_input.command лежит текст команды, а выход с кодом 2 и сообщением в stderr блокирует вызов. Подробно механика разобрана в нашем гайде про хуки PreToolUse в Claude Code.

#1Фьючерсы#2Спот#3Акции и TradFi

Binance · Wall Street 24/7Турниры Binance: призы за торговлюПризыВсе актуальные турниры и акции Binance с условиями — на одной страницеСмотреть турниры

Скрипт ниже — наш синтез на основе документированного примера protect-files.sh, а не официальная рекомендация. Проверьте его на своей версии, прежде чем полагаться на него: попросите Claude выполнить безобидный echo с вашим адресом и убедитесь, что вызов заблокирован.

#!/bin/bash
# ~/.claude/hooks/block-email.sh — пример insidepc.tech, проверьте на своей версии
MY_EMAIL="you@example.com"   # замените на адрес своего аккаунта

INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // .tool_input.url // empty')

shopt -s nocasematch
if [[ "$CMD" == *"$MY_EMAIL"* ]]; then
  echo "Blocked: команда содержит e-mail аккаунта" >&2
  exit 2
fi
exit 0

Сделайте файл исполняемым (chmod +x ~/.claude/hooks/block-email.sh) и зарегистрируйте его в пользовательских настройках ~/.claude/settings.json, чтобы хук работал во всех проектах:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|WebFetch",
        "hooks": [
          { "type": "command", "command": "$HOME/.claude/hooks/block-email.sh" }
        ]
      }
    ]
  }
}

Учтите две особенности. Хук заблокирует любую команду с вашим адресом, включая безобидную git config user.email — такие команды придётся выполнять самому. А если jq не установлен, переменная CMD останется пустой, и хук молча пропустит всё.

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

«Yes, and don’t ask again» сохраняет пароль в файл проекта

Когда Claude Code просит разрешения на Bash-команду, а вы нажимаете «Yes, and don’t ask again», он сохраняет правило allow в файл .claude/settings.local.json в корне git-репозитория. По таблице документации такое разрешение для Bash действует навсегда для этого репозитория и этой команды, для WebFetch — навсегда для домена, а разрешение на правку файлов живёт только до конца сессии и в файл не пишется.

Проблема в том, что диалог сохраняет точную команду или её префикс (например, Bash(npm test *)). Секрет попадает в файл, если он стоит в сохранённой части команды. Если в команде был токен (curl -H "Authorization: Bearer …") или пароль базы (PGPASSWORD=… psql), он лежит в файле открытым текстом. Составную команду вроде git status && npm test Claude Code разбивает и сохраняет до пяти отдельных правил — по одному на каждую подкоманду, которой нужно разрешение. Секрет может оказаться в любом из них.

Как вычистить файл:

1. Откройте .claude/settings.local.json в корне репозитория (в worktree — в основном checkout). Правила также видны командой /permissions внутри сессии.
2. Найдите в permissions.allow строки с секретами: токены, Bearer, PGPASSWORD=, -p с паролем, ключи API в URL.
3. Если файл хоть раз попадал в коммит, образ Docker или чужие руки — сначала смените секрет (раздел про утечку ниже), потом правьте файл.
4. Удалите эти правила и сохраните файл. Это строгий JSON: комментарий // или лишняя запятая дадут ошибку настроек при следующем запуске.
5. Перенесите секрет в переменную окружения, а в команде ссылайтесь на неё: $API_KEY вместо самого ключа. Тогда в правило попадёт имя переменной, а не значение.

Так выглядит проблемный файл (значения выдуманы для примера):

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(PGPASSWORD=Hunter2-prod psql -h db.example.com -U admin)"
    ]
  }
}

GitGuardian в своём разборе советует ещё и сужать сохраняемые правила: вместо широкого Bash(curl *) одобрять конкретную команду к конкретному хосту, где ключ передаётся переменной. Здесь важна оговорка документации: шаблоны, которые пытаются ограничить аргументы команды, хрупкие. Bash(curl http://github.com/ *) не совпадёт с curl -X GET http://github.com/…, с https:// или с запросом через переменную. Узкое правило нужно, чтобы секрет не сохранялся в файл, а не как защитный барьер.

Deny-правила в settings.json: закрываем .env и папки с ключами

Deny-правило — это запрет в блоке permissions.deny файла настроек. Правила проверяются в порядке deny → ask → allow, и первое совпадение решает исход, поэтому запрет побеждает любое разрешение. Ниже — блок из документации, дополненный правилами для папки secrets и каталога ~/.ssh в синтаксисе той же документации. Его можно вставить как есть. Это и есть базовые security settings Claude Code в формате JSON: положите их в ~/.claude/settings.json, чтобы они действовали во всех проектах, или в .claude/settings.json репозитория, чтобы их получила вся команда.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)"
    ]
  }
}

Учтите: правило с ./ закрывает только .env в корне папки, где запущена сессия. Для вложенных .env (например, в монорепозитории) нужны правила Read(**/.env) и Read(**/.env.*).

Как устроена иерархия файлов и почему массивы правил из разных уровней складываются, а не заменяют друг друга, мы подробно разбирали в статье про settings.json в Claude Code. Для безопасности важны четыре детали путей:

Если вы годами вели файл .claudeignore — документация прямо пишет, что он «has no effect», то есть ничего не делает. Его записи нужно перенести в Read-deny. The Register ещё 28 января 2026 года (версия 2.1.12) показала, что Claude читает .env вопреки .claudeignore.

Что обходит deny-правила Claude Code: grep -r, скрипты, путь к curl

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

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

Ещё одна полезная деталь касается чужих репозиториев. Правила allow из .claude/settings.json проекта Claude Code применяет только после того, как вы приняли диалог доверия к папке, а deny и ask действуют сразу. Клонированный проект не может молча выдать агенту лишние разрешения, но может сразу добавить запреты.

Песочница и переменные окружения: что видит агент при закрытом .env

Песочница (sandbox) — это изоляция Bash-команд Claude Code на уровне операционной системы. По документации на 9 ноября 2026 года она выключена по умолчанию: включается командой /sandbox или ключом sandbox.enabled. И даже включённая, по умолчанию она разрешает читать большую часть машины, включая ~/.ssh и ~/.aws/credentials, а переменные окружения со всеми секретами наследуются от Claude Code. Встроенного списка запретов нет: закрыто только то, что вы перечислили.

Пример из документации закрывает файл AWS и папку SSH и убирает два токена из окружения команд в песочнице:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Три оговорки к этому блоку:

• Где хранить. Источник настроек можно исключить при запуске (например, чтобы не подгружать настройки чужого репозитория). Начиная с версии 2.1.246 в таком случае Claude Code не применяет ни одной записи credentials из исключённых настроек проекта и локальных настроек. А записи mask он учитывает только из пользовательских и управляемых настроек или флага --settings. Надёжное место — пользовательский ~/.claude/settings.json.
• Что покрывает. sandbox.credentials действует только на Bash-команды внутри песочницы. Чтобы вычистить учётные данные из окружения всех подпроцессов, включая хуки и stdio-серверы MCP, задайте переменную CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 (например, export в профиле оболочки). Она узнаёт секрет по имени или значению переменной, но токены GitHub и настройки прокси оставляет.
• Транскрипты. Даже если секрет не попал в файл правил, он мог попасть в диалог. Claude Code хранит транскрипты сессий локально открытым текстом в ~/.claude/projects/ 30 дней по умолчанию; срок меняется ключом cleanupPeriodDays. Эту папку стоит сканировать вместе с репозиториями.

Режим mask (агент видит подставное значение, а настоящее подставляет прокси) подробно разобран в статье о пяти периметрах. Если настроек мало и нужна полная изоляция, вынесите агента в контейнер, где ключей просто нет, — как это сделать, мы показывали в разборе песочницы для ИИ-агентов.

Auto mode и YOLO: что они не гарантируют для секретов

Auto mode — режим, в котором действия агента вместо вас оценивает классификатор. С версии 2.1.283 он стал стартовым режимом для интерактивных сессий в терминале и VS Code. Глава Claude Code Борис Черни на Hacker News назвал его более безопасным выбором и посоветовал всем. Критики в том же треде возражают, что модель угроз у классификатора не определена. Это спор мнений; ниже — только то, что записано в документации.

Два вывода из таблицы. Первый: auto mode не обещает, что агент не прочитает .env, — чтение там разрешено по умолчанию. Deny-правила из предыдущих разделов нужны и в этом режиме. Второй: сохранение команд с секретами в файл настроек в auto mode тоже возможно — на замечание пользователя об этом Черни ответил «good catch», то есть признал проблему (по данным Ars Technica).

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

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

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

Файлы в .gitignore и .dockerignore: что добавить сегодня

Главный сюрприз этой истории в том, что Claude Code действительно прячет свой файл от git, но не там, где многие думают. По документации о файлах настроек, при первой записи он добавляет строку **/.claude/settings.local.json в глобальный git excludes — файл из core.excludesFile или ~/.config/git/ignore. Если файл вы создали руками, добавить его в .gitignore нужно самим.

Отсюда и спор на Hacker News. Черни писал, что команда «автоматически игнорирует файл», а автор исследования Apiiro — что игнор только глобальный; в ответ на возражения он сузил формулировку. Свежий клон файла не содержит: файл не отслеживается, а на новой машине Claude Code сам допишет глобальный игнор при первой записи. Глобальный игнор действует на все репозитории машины. Реальные пути утечки другие:

• файл создан руками до того, как Claude Code впервые записал в него, и глобального игнора ещё нет;
• файл уже отслеживается git — тогда никакой игнор его не исключает;
• рабочую папку скопировали целиком (архив, rsync, общий том, образ Docker, артефакт CI) туда, где глобального игнора нет, и там закоммитили;
• файл добавили принудительно через git add -f.

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

git check-ignore -v .claude/settings.local.json

Если вывод указывает на глобальный файл или пустой, добавьте строки в .gitignore самого репозитория:

.env
.env.*
!.env.example
.claude/settings.local.json

Если файл уже отслеживается git, одной строки в .gitignore мало: git продолжит его коммитить. Уберите его из индекса, оставив на диске:

git rm --cached .claude/settings.local.json
git commit -m "Stop tracking Claude Code local settings"

Этот коммит не удаляет файл из истории — секреты в старых коммитах остаются, поэтому их всё равно нужно сменить.

Отдельный канал утечки — Docker. Команда COPY . . берёт рабочее дерево, а не индекс git, поэтому файл, который git игнорирует, всё равно попадёт в образ. GitGuardian (данные на 7 ноября 2026) нашла в публичных образах Docker Hub 613 разных секретов из этого файла, 99 из них были рабочими. В .dockerignore добавьте:

.env
.env.*
.claude/

Файл .claude/settings.json с общими командными правилами в git коммитить можно и нужно: секретов в нём быть не должно, а deny-правила полезно раздать всей команде. Закрывать от git нужно только settings.local.json. Вместо настоящего .env в репозиторий кладут .env.example с пустыми значениями.

Как проверить свои репозитории: gh search, gitleaks, TruffleHog

Аудит отвечает на вопрос, утекло ли что-то уже, и начинается с поиска самого файла, а заканчивается защитой от следующей утечки. Порядок такой:

1. Найдите файл в своих публичных репозиториях. Через GitHub CLI: gh search code --owner <логин> --filename settings.local.json. Документация CLI предупреждает, что команда работает на устаревшем движке поиска, и результаты могут отличаться от веб-поиска. Для сверки ищите на сайте GitHub с квалификаторами user:<логин> и path:.claude/settings.local.json.
2. Проверьте, попадал ли файл в историю. В каждом локальном репозитории: git log --all --oneline -- .claude/settings.local.json. Пустой вывод означает, что файл никогда не коммитился.
3. Прогоните gitleaks по истории и по папке транскриптов:

gitleaks git -v
gitleaks dir -v ~/.claude/projects

1. Прогоните TruffleHog с проверкой валидности: trufflehog git file://. --results=verified для репозитория и trufflehog filesystem ~/.claude/projects для транскриптов. Флаг --results=verified оставляет только ключи, которые сейчас работают.
2. Поищите руками то, что сканеры пропускают. У пароля после PGPASSWORD= или -p нет узнаваемого формата, как у ключа AWS, поэтому сканер его не видит. Наш вариант поиска (подстройте под свои команды): grep -rnE "PGPASSWORD=|Bearer |api[_-]?key=|password=" .claude/.
3. Включите защиту на GitHub. Для публичных репозиториев secret scanning работает бесплатно и автоматически. Для приватных репозиториев организации нужен GitHub Secret Protection на тарифе Team или Enterprise Cloud. Push protection на уровне пользователя включён по умолчанию и не даёт пушить секреты в публичные репозитории. А на уровне репозитория любой с правом записи может обойти блок, указав причину.
4. Поставьте gitleaks в pre-commit, чтобы ловить секрет до коммита: репозиторий gitleaks/gitleaks, хук gitleaks в .pre-commit-config.yaml.

Цифры Apiiro показательны: оба сканера вместе не заметили 215 файлов из 1 122. Поэтому ручной поиск в пункте 5 — не перестраховка, а обязательный шаг.

Ключ API или пароль уже утёк: что делать и в каком порядке

Если аудит что-то нашёл, порядок важнее скорости. Удалить файл недостаточно: история git, форки, клоны и образы Docker хранят копии. Документация GitHub прямо пишет, что первым шагом секрет нужно отозвать или сменить.

1. Отзовите или смените секрет. Ключ Anthropic API: в Console на странице platform.claude.com/settings/keys откройте меню рядом с ключом и выберите «Delete API key». Пароль базы данных, токен GitHub, SSH-ключ — смените там, где они выданы.
2. Проверьте журналы использования. Посмотрите, не было ли запросов с этим ключом, которых вы не делали. Если ключ лежал в публичном репозитории, учтите, что Anthropic автоматически деактивирует найденные там ключи. Но такой ключ мог успеть поработать до деактивации, а пароль базы никто за вас не отключит.
3. Уберите секрет из рабочих файлов: вычистите settings.local.json, добавьте его в .gitignore и выполните git rm --cached, как в предыдущем разделе.
4. Решите, переписывать ли историю. Если секрет уже сменён, переписывание истории (например, через git-filter-repo) по документации GitHub может быть не нужно: старое значение больше ничего не открывает. Переписывают, когда секрет нельзя сменить или в истории лежат персональные данные.
5. Найдите копии вне репозитория. Пересоберите образы Docker с новым .dockerignore и удалите старые теги. Проверьте форки: их владельцы ваши правки не получат.

Масштаб «старых» ключей виден по данным GitGuardian: из 31 088 найденных секретов 5 343 работали в момент обнаружения. Утечка, которой полгода, остаётся опасной, пока ключ не сменён.

Чек-лист безопасности Claude Code на 15 минут

Сжатая версия всей статьи — то, что стоит сделать сегодня. Базовые настройки (пункты 1–7) занимают около 15 минут; аудит и смена ключей (пункты 8–10) — дольше, в зависимости от числа репозиториев:

1. claude --version — не ниже 2.1.317; проверка cc-plugin-privacy в /plugins включена.
2. Хук против своего e-mail в ~/.claude/settings.json проверен на безобидной команде.
3. .claude/settings.local.json открыт, правила с секретами удалены, секреты перенесены в переменные окружения.
4. В ~/.claude/settings.json есть deny на .env, .env.*, папки с ключами и ~/.ssh; .claudeignore удалён или перенесён.
5. Песочница включена, sandbox.credentials перечисляет ваши файлы и токены; задана CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1.
6. disableBypassPermissionsMode стоит, если YOLO-режим вам не нужен.
7. В .gitignore каждого репозитория есть .env* и .claude/settings.local.json, в .dockerignore — .claude/.
8. gh search code и git log по файлу пусты; gitleaks, TruffleHog и ручной grep по репозиториям и ~/.claude/projects ничего не нашли.
9. Secret scanning и push protection включены, gitleaks стоит в pre-commit.
10. Всё, что когда-либо лежало в файле правил или в истории, сменено.

Что настройки Claude Code не закрывают: остаточные риски

Даже полный чек-лист не делает агента безопасным. Он убирает самые частые пути утечки и оставляет несколько рисков, которые надо держать в голове:

• Prompt injection. Агент читает недоверенный контент: страницы, issue, зависимости. Текст в нём может уговорить модель отправить данные наружу способом, который ни deny-правила, ни хук не предусмотрели. Это второй элемент триады — недоверенный контент. Убрать его нельзя, поэтому разрывают третий — канал наружу: изоляция и ограничение сети, а не правила разрешений.
• Обходы deny. grep -r, скрипты и другой путь к бинарнику остаются, пока не включена песочница. Песочница по умолчанию выключена, а включённая читает всё, что вы не запретили.
• Доверие к вендору. E-mail в контекст модели положила сама Anthropic, и пользователи узнали об этом из инцидента. Глава Claude Code признал на HN, что исторически инструмент не вычищает секреты, и пообещал поискать защиту. Поэтому хотя бы один слой проверки — сканер, хук, pre-commit — должен быть вашим, а не встроенным.
• Старые утечки. По GitGuardian, число утечек через этот файл упало на 92%: с пика в 12 535 в апреле 2026 года до 959 в октябре. Причину компания не знает. Это повод не паниковать, но не повод не проверять: уже утёкшие ключи от спада не перестают работать.
• Приватность кода. Код и диалоги уходят на серверы Anthropic, а транскрипты 30 дней лежат на диске открытым текстом. Условия обучения на ваших данных зависят от тарифа — они разобраны в материале о пяти периметрах.

Что устареет первым: статус удаления e-mail из контекста, номера версий и список того, что auto mode разрешает по умолчанию. Свежие данные — в changelog Claude Code и в issue #107757.

FAQ

Как отключить отправку e-mail в Claude Code?

Обновитесь до версии 2.1.317 или новее (claude update): в ней встроенная проверка cc-plugin-privacy спрашивает разрешения, прежде чем адрес уйдёт в сеть. Она включена по умолчанию, выключать её в /plugins не нужно. Проверка не ловит скрипты, которые Claude пишет сам, поэтому добавьте свой PreToolUse-хук и следите за changelog: полное удаление адреса из контекста на 9 ноября 2026 года ещё не вышло.

Что делать, если в settings.local.json уже есть пароль?

Сначала смените пароль или отзовите ключ — особенно если файл хоть раз попадал в коммит или образ Docker. Затем удалите правило из permissions.allow, перенесите секрет в переменную окружения и ссылайтесь на $VAR в командах. Добавьте файл в .gitignore репозитория и, если он отслеживается, выполните git rm --cached. История git после смены секрета уже не опасна для этого секрета.

Защищает ли .gitignore от утечки settings.local.json?

Да, если строка .claude/settings.local.json стоит в .gitignore самого репозитория и файл ещё не отслеживается. Глобальный git excludes, который пишет Claude Code, не спасает, если файл создан руками до первой записи, уже отслеживается git, добавлен через git add -f или папку скопировали целиком туда, где игнора нет. От Docker .gitignore не защищает: COPY . . берёт рабочее дерево, нужен ещё .dockerignore.

Обходит ли команда cat или grep deny-правило Read(./.env)?

cat, head, tail и sed правило блокирует: Claude Code распознаёт эти команды и сверяет их цели с Read-deny. А grep -r pattern ., запущенный из папки с файлом, и скрипт на Python или Node, который сам открывает файл, правило не останавливает — так написано в документации. Для полной блокировки на уровне ОС нужна песочница с sandbox.credentials.

Нужно ли переписывать историю git после утечки ключа?

Чаще всего нет, если ключ уже отозван или сменён: документация GitHub называет смену секрета первым шагом и допускает, что переписывать историю не понадобится. Старое значение в коммитах больше ничего не открывает. Историю чистят через git-filter-repo, когда секрет сменить нельзя или в коммитах лежат персональные данные, и тогда нужно учесть форки и клоны.

Достаточно ли auto mode, чтобы не следить за секретами?

Нет. По документации auto mode по умолчанию разрешает читать .env и отправлять учётные данные в соответствующий им API. Он блокирует пуш секретов в публичный репозиторий и печать живого ключа в файл, но сохранение команд с секретами в настройки в нём тоже возможно. Deny-правила, .gitignore и сканер нужны и в этом режиме.