Как настроить Claude Code перед первой задачей: 8 шагов защиты секретов

Что Claude Code видит в проекте и почему секреты нужно закрыть?

Claude Code не сидит внутри одного текстового окна. Он работает с проектными файлами, запускает shell-команды и дочерние процессы, а также может использовать сеть. Если запуск происходит из домашней рабочей директории, область риска выходит за пределы папки с кодом.

Проблема не в том, что агент обязательно начнёт искать ключи. Проблема в границе. Агент может неверно понять, где заканчивается тестовая среда и начинаются реальные системы.

Anthropic описывала похожую ошибку в собственных оценках:

Одной инструкции оказалось мало. Поэтому я держу простое правило: настоящий секрет не должен попадать в доступную область вообще.

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

Безопаснее ли запускать Claude Code локально?

Слово «локально» отвечает только на вопрос, где запущен процесс. Оно не отвечает на вопрос, что процесс может прочитать.

Если Claude Code запущен на ноутбуке, рядом могут находиться:

• .env и локальные конфиги;
• ~/.ssh;
• ~/.aws;
• ~/.config/gh;
• .netrc;
• shell-профили;
• macOS Keychain;
• OAuth-токены и другие credentials.

При разрешённом Bash команда выполняется с правами текущего пользователя.

Anthropic формулирует границу прямо:

Локальный запуск удобен для тестовой копии. Но «на своём компьютере» не значит «изолированно». Изоляцию создают отдельная директория без секретов, sandbox или контейнер. Если нужен автономный режим, я бы не запускал его в домашней рабочей директории.

Как подготовить тестовую копию проекта без ключей и паролей?

Точные команды копирования для Windows, macOS и Linux здесь не привожу: в фактуре нет проверенного варианта для всех трёх систем. Сделай копию через привычный файловый менеджер или имеющийся у тебя способ, но не смешивай её с настоящей рабочей директорией.

1. Создай отдельную рабочую копию.

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

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

2. Удали файлы с секретами.

   Убери .env, .env.*, приватные ключи, credential-файлы, локальные конфиги, дампы, выгрузки и production-данные.

   Не оставляй рядом с копией ~/.ssh, ~/.aws, .netrc, .config/gh и другие домашние хранилища. Они не становятся безопасными только потому, что код лежит в папке с названием test.

3. Замени значения на тестовые.

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

   Тестовое значение должно быть искусственным. Не вставляй настоящий API key, пароль, OAuth-токен или production-адрес. Если приложение требует доступ к сервису, используй тестовую среду и тестовые токены с минимальными правами.

4. Защити секреты в Git.

   Добавь чувствительные пути в .gitignore, чтобы случайно не отправить их в историю.

   .gitignore решает задачу Git. Он не скрывает файл от Claude Code, если файл физически лежит в рабочей области.

5. Проверь состав копии глазами.

   Просмотри дерево файлов до запуска агента.

   Ищи не только .env. Проверь расширения .pem, .key, credential-файлы, архивы, дампы, логи, выгрузки и приватные конфиги. Отдельно проверь, не открыты ли такие файлы в IDE.

6. Перед запуском убери секреты из IDE.

   Закрой вкладки с .env, ключами и токенами, не выделяй из них строки и не копируй вывод терминала в чат.

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

7. Добавь правила доступа.

   Создай .claude/settings.local.json или другой файл настроек с permissions.deny, затем проверь его искусственным секретом.

   json

   Скопировать

   {
     "permissions": {
       "deny": [
         "Read(./.env)",
         "Read(./.env.*)",
         "Read(./secrets/**)",
         "Read(./config/credentials.json)",
         "Read(./build)"  // авторское дополнение: в официальном примере этой строки нет
       ]
     }
   }

   Этот пример взят из документации Claude Code. В фактуре есть отчёты о проблемах с ./ и совпадением путей, поэтому не считай файл рабочим без проверки на конкретной версии.

8. Запусти первую задачу после проверки.

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

   Проверка границ перед первой задачейСкопировать промпт

   Перед началом перечисли только файлы и каталоги в текущей рабочей области.
   Не читай содержимое файлов с именами .env, .env.*, secrets, credentials, .pem и .key.
   Не запускай команды Bash.
   Не используй MCP-инструменты.
   Не обращайся к домашним каталогам и хранилищам учётных данных.
   Если нужного файла нет, сообщи об этом и остановись.

После этого искусственно проверь запрет. Создай в очищенной копии тестовый .env со значением вроде APP_ENV=dev. Затем проверь, что Claude не читает файл через встроенный Read и не получает значение через окружение. Команды env, printenv и echo $APP_ENV упоминаются в фактуре как направления проверки, но не как полностью подтверждённый сценарий для каждой системы.

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

Между чистой копией и рабочим проектом держи физическую границу. Не делай одну общую тестовую директорию, где лежат и очищенный код, и домашние ключи.

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

Какие настройки Claude Code запрещают доступ к секретам?

Официальная документация предлагает permissions.deny вместо устаревшего ignorePatterns:

Минимальные категории такие:

• .env и .env.*;
• secrets/**;
• config/credentials.json;
• приватные ключи;
• локальные конфиги;
• дампы и production-данные;
• домашние каталоги с credentials.

В фактуре есть примеры для Read, а также рекомендация учитывать Edit, Write, Bash, Grep и Glob. Но нельзя превращать этот список в обещание полной изоляции. Read(./.env) блокирует встроенный Read, но не обязательно блокирует cat .env через Bash.

Порядок правил такой:

1. deny - жёстко запрещает совпавшее действие;
2. ask - просит подтверждение;
3. allow - разрешает без дополнительного подтверждения.

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

С синтаксисом путей есть отдельная ловушка. В issue официального репозитория пользователь сообщил, что ./ может совпадать не с корнем проекта, а с буквальным путём. Другой отчёт описывает ситуацию, когда deny вообще не сработал. Я бы не копировал правило вслепую. Создай искусственный секрет, проверь совпадение и только потом считай настройку рабочей.

Что написать в CLAUDE.md, а что он не защитит?

В CLAUDE.md можно зафиксировать намерение:

# Правила работы в тестовой копии

- Работай только с файлами текущей тестовой копии.
- Не читай и не меняй .env, .env.*, secrets/**, credentials и приватные ключи.
- Не обращайся к домашним каталогам с учётными данными.
- Не запускай Bash без отдельного подтверждения.
- Перед изменением файлов сначала опиши план.
- После изменения покажи результат проверки.

Это делает задачу понятнее для модели. Но текстовая инструкция не остановит чтение через другой канал. В полевом отчёте описан случай, когда даже явная просьба не читать .env не помешала Claude иногда читать или менять файл.

CLAUDE.md задаёт правила работы с проектом. Для истории изменений есть .gitignore, а технический запрет обеспечивает deny. Главным слоем всё равно остаётся отсутствие настоящих секретов. Я бы держал все четыре слоя рядом.

Как настроить разрешения Claude Code перед первой задачей?

Claude Code оценивает правила в порядке deny -> ask -> allow. Это позволяет сначала закрыть секретные пути, затем оставить опасные действия на подтверждении, а безопасные разрешить отдельно.

Для первой задачи я бы действовал так:

1. Запретил чтение и изменение категорий с секретами.
2. Оставил Bash под подтверждением.
3. Не выдавал общий Bash(*).
4. Не подключал MCP-инструменты без необходимости.
5. Запустил короткую проверку в очищенной копии.
6. Остановился, если команда обращается к домашней директории, окружению или сети.

Запрос подтверждения не означает, что команда безопасна. Ты можешь не понять длинную shell-команду, устать от постоянных вопросов или подтвердить действие автоматически. Anthropic прямо называет такой подход подверженным ошибкам.

Для автономной работы Anthropic описывает два пути: встроенный sandbox или флаг --dangerously-skip-permissions. Второй отключает подтверждения и не даёт защиты. Даже sandbox не стоит воспринимать как замену проверке инфраструктуры.

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

Почему запрет на .env может не сработать?

Вот основные точки отказа.

Неверный путь. Запись Read(./.env) выглядит как путь от корня проекта, но в issue официального репозитория описано другое совпадение. Не считай шаблон доказанным без теста на текущей версии.

Окружение процесса. В отдельном отчёте Claude Code загружал и экспортировал .env при старте даже при запрете чтения. Значит, файл мог не пройти через Read, но значение уже оказалось доступно процессу.

Bash. Документация прямо разводит встроенный Read и shell. Read(./.env) не блокирует cat .env в Bash. Та же проблема касается команд, которые ищут строки или печатают окружение.

Grep и Glob. Полевое исследование сообщает, что Bash, Grep и Glob могут обходить файловые deny-правила. Не делай вид, что запрет одного инструмента накрывает остальные.

MCP. Подключённый MCP-инструмент может иметь собственный путь чтения. В исследовании приведён пример, где deny для встроенного Read не блокировал MCP-чтение файла.

IDE. Открытый .env или выделенный фрагмент может попасть в контекст через расширение IDE. В этом случае Claude не обязан был читать файл сам.

Hooks. PreToolUse-хук может выглядеть настроенным, но не запускаться. В issue пользователь сообщил о проблеме с вызовом PreToolUse и PostToolUse. Хук нужно проверять логом, а не считать включённым по наличию файла.

Домашние хранилища. При полном Bash-доступе процесс работает с правами текущего пользователя. В полевом отчёте описан поиск OAuth-токена в macOS Keychain после того, как токен не нашёлся в файлах.

Проверка искусственным секретом должна быть отдельным сценарием:

1. Положи в тестовую копию значение, которое нигде больше не используется.
2. Проверь отказ встроенного чтения.
3. Проверь, что значение не появилось в окружении.
4. Проверь команды Bash, Grep и Glob.
5. Не открывай файл в IDE и не выделяй его содержимое.
6. Если подключён MCP, проверь его отдельно.
7. Для hook проверь появление строки в логе.

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

Вопросы и ответы