Права Claude Code: как защитить .env, Git и опасные команды

Разработчики часто сталкиваются с дилеммой при настройке Claude Code: либо бесконечно подтверждать каждую мелкую команду чтения, либо включить полный bypass (--dangerously-skip-permissions) и рисковать утечкой секретов из .env, случайным git push --force или повреждением окружения.

Оба крайних подхода неэффективны. Безопасная работа строится на принципе минимальных привилегий: разграничении чтения, записи, вызовов shell и работы с контролем версий.

---

1. Карта разрешений: от чтения к внешнему воздействию

Разделите команды и файлы на четыре уровня доступа:

Уровень	Операции	Политика по умолчанию	Примеры
1. Чтение кода	Просмотр файлов проекта	В Manual mode обычно без запроса внутри working directory; зависит от mode и managed settings	cat, grep, чтение исходников src/
2. Секреты и окружение	Доступ к .env, ключам, токенам	Явный Read deny плюс sandbox/credential isolation	.env*, id_rsa, *.pem, credentials.json
3. Правка файлов	Редактирование и создание кода	В Manual mode требует approval; правила организации могут быть строже	Правки в пределах выделенного workspace
4. Опасные команды shell & Git	Пакетные менеджеры, деструктивные операции	Явный deny либо разовый ручной approval в изолированной среде	rm -rf, git push --force, npm publish, DROP TABLE

---

2. Изоляция файлов .env и секретов

Шифрование канала (TLS) защищает трафик при передаче, но не защищает от попадания секрета в контекстное окно модели, системный лог или файл handoff.

.gitignore предотвращает случайный commit, но не запрещает агенту читать файл. Инструкция в CLAUDE.md или AGENTS.md влияет на поведение модели, но также не является технической границей. Используйте оба уровня только вместе с исполняемыми permission rules.

1. Добавьте файлы с секретами в .gitignore и оставьте безопасный .env.example.
2. В project settings запретите встроенным file tools читать секретные пути.
3. Включите sandbox filesystem deny для subprocess, которые permission rule не может разобрать.
4. Проверьте итог через /permissions и отрицательный тест с фиктивным значением.

Минимальный пример .claude/settings.json для актуальной версии Claude Code:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": [
        "./**/.env",
        "./**/.env.*",
        "./secrets"
      ]
    }
  }
}

Read deny применяется к built-in file tools и распознаваемым file-командам. Произвольный Python или Node subprocess может читать файлы иначе, поэтому для OS-level ограничения нужен включённый sandbox. Пара failIfUnavailable: true и allowUnsandboxedCommands: false превращает отсутствие sandbox в отказ, а не в незаметный запуск команды без изоляции. Нативный Windows sandbox не поддерживается: для такого режима используйте WSL2 или контейнер. Поддержку конкретных settings сверяйте с документацией вашей версии; в managed environment администратор должен закрепить правила так, чтобы project config не мог их ослабить.

В файле инструкций дополнительно зафиксируйте намерение:

## Правило безопасности секретов
- Никогда не читай, не копируй и не выводи содержимое файлов `.env`, `.env.local` или приватных ключей.
- Для проверки наличия переменных используй проверку ключей в `.env.example`.

[!IMPORTANT] Управление API-ключами: Собственный API Key для Claude Code создаётся в аккаунте пользователя и задаётся через переменные окружения ОС. Схема безопасного подключения описана в BetterToken Docs: https://docs.bettertoken.ai/ai-tools/claude-code. Никогда не передавайте ключ в запросах к модели.

---

3. Приоритетный чек-лист контроля Git и команд

При выполнении задач с участием Claude Code соблюдайте следующий порядок проверок:

graph TD
    A[Агент предлагает команду] --> B{Команда содержит rm, drop, push --force?}
    B -- Да --> C[Отклонить или выполнить вручную под контролем]
    B -- Нет --> D{Затрагивает .git, .env или внешние сети?}
    D -- Да --> E[Запросить явное объяснение и ограничить scope]
    D -- Нет --> F[Разрешить выполнение в рабочей ветке]

Пошаговые правила:

1. Шаг 1: Запрет неконтролируемых Git-мутаций. Не разрешайте агенту выполнять git push напрямую в ветку main или делать коммиты без предварительного git diff --check.
2. Шаг 2: Изоляция установки пакетов. Команды npm install <package>, pip install или вызовы внешних curl-скриптов должны подтверждаться вручную, чтобы исключить supply-chain уязвимости.
3. Шаг 3: Локализация правок. Ограничивайте область действия агента конкретной подпапкой или Git worktree.

---

4. Контур доступа к production

Локальные разрешения Claude Code не заменяют IAM, сетевые политики и approval самой production-системы. По умолчанию агенту не нужен production-доступ. Если диагностика без него невозможна, выдавайте отдельную read-only роль только на нужный ресурс и на ограниченное время.

Этап	Разрешение	Обязательная проверка
Диагностика	Read-only к конкретному сервису, логам или метрикам	Scope, срок действия и владелец доступа
Подготовка изменения	Локальный diff или план без production-записи	Review человеком и точный список ресурсов
Запись	Отдельный approval на одну операцию	Команда, цель, окно, rollback и наблюдатель
После изменения	Проверка состояния и audit log	Ожидаемый результат, отсутствие побочных изменений
Завершение	Отзыв временного credential	Проверка revoke и сохранение безопасного audit trail

Короткоживущий credential должен выпускаться доверенным механизмом секретов или identity broker и истекать автоматически. Не вставляйте его в prompt, репозиторий, HANDOFF.md, shell history или transcript. Агенту передаётся только имя разрешённой команды либо уже настроенный credential helper; значение секрета не нужно читать или печатать.

Approval для записи должен описывать один конкретный эффект. Разрешение «исправить production» слишком широкое; разрешение «изменить параметр X у ресурса Y в окне Z, затем выполнить проверку Q» можно проверить и отозвать. Если результат внешней операции неизвестен, сначала прочитайте фактическое состояние и не повторяйте запись вслепую.

Rollback подготовьте до записи: известная предыдущая конфигурация, команда возврата, критерий остановки и ответственный человек. Логи должны содержать время, identity, ресурс, разрешённое действие и результат, но не secret value или чувствительный payload.

5. Проверка безопасности в тестовом окружении

Перед тем как доверить Claude Code реальный репозиторий, выполните контрольный тест в отдельной непроизводственной копии или worktree:

1. Убедитесь через git status --short, что тест не затронет чужие изменения.
2. Поместите незакоммичиваемый фиктивный .env с явно тестовым значением.
3. Дайте агенту задачу на рефакторинг модуля авторизации.
4. Проверьте:
   • Не прочитал ли агент .env во время поиска файлов;
   • Не попали ли секреты в промежуточные комментарии или diff: git diff;
   • Выполняются ли тесты без прямого обращения к скрытым файлам.
5. Убедитесь, что фиктивный secret не отслеживается Git, и сохраните только безопасный результат проверки.

Такой подход защищает кодовую базу от утечек и сохраняет высокую скорость автономной работы агента.

Источники

• Claude Code security
• Claude Code permissions
• Claude Code sandboxing
• BetterToken Docs: Claude Code