Безпека 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 щодо дозволів, першу — журнал змін версії 2.1.317 і самі розробники.

Причина в обох історій одна. Агент водночас бачить ваші дані й уміє надсилати їх назовні — через мережу або через коміт. Дослідник Саймон Віллісон називає це «смертельною тріадою» (lethal trifecta, 2025): доступ до приватних даних, недовірений контент і канал зв’язку із зовнішнім світом. Поки агент має всі три, витік — питання часу. Тому кожен пункт чек-листа нижче прибирає хоча б одне ребро: секрет не потрапляє в контекст, файл не читається, коміт не йде, те, що витекло, знаходять і відкликають.

USDT→

Binance · Wall Street 24/7Акції США без брокераТоргуйте ціною Apple, Nvidia і Tesla прямо з акаунта Binance

AAPLNVDATSLA

Перша угода за 5 кроків

Масштаб другої історії дві компанії — постачальники сканерів — рахували по-різному, і цифри не варто змішувати:

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. У журналі змін версії 2.1.317 від 3 листопада 2026 року записано: додано перевірку, яка питає дозволу, перш ніж веб- або shell-інструмент надішле e-mail акаунта в мережу.
2. Не вимикайте вбудовану перевірку. Вона називається cc-plugin-privacy, увімкнена за замовчуванням і видна в /plugins. Там же її можна вимкнути — робити цього не потрібно.
3. Стежте за повним виправленням. Команда пообіцяла прибрати e-mail із контексту моделі в наступному релізі «на початку наступного тижня». Станом на 9 листопада в журналі змін до версії 2.1.319 (6 листопада) такого пункту немає, а issue #107757 лишається відкритим. Перевіряйте журнал змін у день, коли читаєте цю статтю.
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.

Binance · Wall Street 24/7А якби ви купили золото влітку?+? %Тренажер на реальних цінах Binance покаже результат. Без грошей і реєстрації

GOLDNVDATSLA

Відкрити тренажер

Скрипт нижче — наш синтез на основі задокументованого прикладу 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 дозволяє за замовчуванням. Свіжі дані — у журналі змін Claude Code та в issue #107757.

Часті запитання

Як вимкнути надсилання e-mail у Claude Code?

Оновіться до версії 2.1.317 або новішої (claude update): у ній вбудована перевірка cc-plugin-privacy питає дозволу, перш ніж адреса піде в мережу. Вона увімкнена за замовчуванням, вимикати її в /plugins не потрібно. Перевірка не ловить скрипти, які Claude пише сам, тому додайте власний PreToolUse-хук і стежте за журналом змін: повне вилучення адреси з контексту станом на 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 і сканер потрібні і в цьому режимі.