Как безопасно допустить Claude Code к проекту: 7 шагов от папки до правки

Что такое Claude Code?

Anthropic представила Claude Code как инструмент для агентного программирования через командную строку:

На старте продукт имел статус limited research preview. 22 мая 2025 года Claude Code стал общедоступным. В changelog переход отмечен как версия 1.0.0.

Обычный чат-бот и Claude Code отличаются по типу действий.

Именно здесь начинается риск. Агент видит больше одного сообщения и может получить доступ к инструментам проекта. Чтение файла, изменение файла, Bash-команда и сетевое действие не равны друг другу. У каждого действия своя граница доступа.

Я бы не начинал с доверия всему проекту. Внутри папки могут лежать настройки, hooks, скрипты и инструкции, которые агент прочитает при запуске. Сам факт, что файл находится рядом с кодом, не делает его безопасным.

Как Claude Code работает через командную строку?

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

У действий разные уровни доступа:

Эти границы нельзя сливать в одну настройку. Встроенный sandbox ограничивает Bash-подпроцессы. Инструменты Read, Edit и Write работают через отдельную permission-систему.

Из этого следует простой порядок. Сначала проверь, какие файлы агент видит. Затем отдельно проверь, что ему разрешено менять. После этого разбирай Bash и сетевые действия.

Фраза «агент работает в песочнице» не означает, что вся сессия закрыта одной защитой. Переменные окружения родительского процесса по умолчанию доступны sandboxed Bash-командам. Поэтому секреты нельзя держать в зоне, где агент может получить к ним доступ.

Как начать работу с проектом?

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

   Не открывай агенту домашний каталог, весь диск, рабочие облачные аккаунты или production-среду.

   Отдельная папка уменьшает blast radius: если агент ошибётся, область возможного ущерба будет ограничена этой средой. Для первой задачи подойдёт копия проекта или тестовая рабочая среда без настоящих данных.

   Не клади туда .env, SSH-ключи, production credentials и Docker socket. Секреты не должны попадать в контекст только потому, что рядом лежит нужный файл.

2. Начни с чтения и анализа.

   Сначала попроси агента изучить структуру проекта и назвать файлы, которые относятся к задаче.

   Не проси сразу «починить всё». Первая задача должна показать, как агент читает проект, какие зависимости считает связанными и какие действия собирается выполнить.

   Анализ проекта без измененийСкопировать промпт

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

3. Сформулируй одну небольшую задачу.

   Опиши конкретный результат и границы правки.

   Хорошая первая задача - изменение, которое можно проверить глазами и тестом. Например: разобраться, где находится нужная страница, и предложить минимальную правку. Плохая формулировка - «приведи проект в порядок»: она оставляет агенту слишком широкое поле решений.

4. Проверь план до записи.

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

   Если в плане появились удаление, перенос большого числа файлов, установка пакетов, сетевой доступ или работа вне папки, остановись. Уточни задачу и сузь разрешения.

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

   Самые успешные команды относятся к Claude Code как к партнёру для размышлений, а не просто как к генератору кода.

   • Anthropic, How Anthropic teams use Claude Code

5. Разреши только нужные изменения.

   Дай доступ к записи после проверки плана. Отдельно решай, нужны ли Bash-команды и сеть. Для смены текста в файле сеть обычно не относится к задаче. Если агент просит её включить, попроси объяснить конкретную причину.

6. Проверь результат.

   Сравни изменённые файлы с задачей и запусти доступную проверку.

   Не принимай сообщение «готово» как доказательство. Нужны фактические признаки: список изменённых файлов, вывод проверки и понятное описание того, что именно поменялось.

7. Останови сессию после проверки.

   Не оставляй агенту лишний доступ после завершения задачи.

   Checkpoints и отдельная рабочая среда нужны для обратимости. Если правка пошла не туда, сначала останови работу и вернись к сохранённому состоянию вместо просьбы агенту «самому отменить всё».

Что агент может делать в проекте?

Реальные сценарии работы включают:

• навигацию по проекту;
• анализ существующего кода;
• запуск тестов;
• отладку;
• подготовку документации;
• прототипирование;
• изменение файлов.

Для новичка полезно разделять два вопроса:

1. Поможет ли это действие решить задачу?
2. Должен ли агент иметь право выполнять его без отдельного подтверждения?

Например, чтение нескольких файлов может быть полезным и низкорисковым. Изменение конфигурации уже требует проверки. Bash-команда может удалить данные, установить пакет или обратиться к внешнему адресу. Сетевая операция может вынести секрет за пределы рабочей среды.

Команда Anthropic даёт Claude Code абстрактные задачи, позволяет ему работать автономно, а затем проверяет решения перед финальными изменениями. Рабочая схема включает ограниченную среду и проверку результата.

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

Как задать правила и ограничения для агента?

Файл CLAUDE.md фиксирует рабочие правила, которые агент должен учитывать при чтении и изменении проекта.

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

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

Рабочая область: текущая папка проекта.

Перед изменением файлов:
1. Сначала изучи структуру проекта.
2. Назови файлы, которые относятся к задаче.
3. Составь короткий план.
4. Дождись подтверждения плана.

Правила:
- Не изменяй файлы вне рабочей области.
- Не читай и не выводи секреты, ключи, токены и содержимое .env.
- Не выполняй сетевые действия без отдельного подтверждения.
- Не запускай команды, которые меняют production-системы.
- Не удаляй файлы и не переписывай крупные части проекта без отдельного подтверждения.
- После правки перечисли изменённые файлы и покажи результат проверки.
- Если цель задачи неясна, остановись и задай один уточняющий вопрос.

Это текстовое правило с описанием допустимых действий. Техническая permission-система определяет, какие действия реально доступны агенту.

Настройки проекта, hooks и конфигурация не становятся безопасными только из-за расположения внутри рабочей папки. Anthropic отдельно описывала случай, когда Claude Code читал настройки проекта при запуске до стандартного подтверждения доверия к папке. Поэтому незнакомый проект нужно рассматривать как источник внешних инструкций, который требует проверки.

Hooks тоже равны отдельному механизму контроля. Они запускают произвольные shell-команды с правами текущего пользователя. Их можно использовать для аудита и дополнительных проверок, но не как единственную границу.

Как безопасно допустить Claude Code к проекту?

Anthropic формулирует базовую модель так:

Практический профиль допуска выглядит так:

• Папка. Только отдельная рабочая зона проекта.
• Файлы. Чтение сначала, запись после подтверждения.
• Bash. Только команды, которые понятны и относятся к задаче.
• Сеть. Запрещена по умолчанию или ограничена нужными адресами.
• Секреты. Не лежат в доступной агенту области.
• Среда. Без production-доступа и настоящих ключей.
• Проверка. Перед финальной доработкой нужен тестовый прогон.

Sandbox и permissions отвечают за разные части. Границы sandbox изолируют Bash-подпроцессы. Инструменты чтения и редактирования проходят через собственную систему разрешений. Поэтому проверка должна включать отдельные тесты для чтения, записи, Bash и сети.

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

Проверь также escape hatch sandbox. Claude Code может повторить команду с отключённой песочницей, если внутри неё команда завершилась ошибкой. Для жёсткой границы настройка allowUnsandboxedCommands должна быть установлена в false.

После изменения настроек сделай короткий тестовый прогон:

1. Попроси прочитать безопасный файл.
2. Проверь, что изменение файла требует ожидаемого разрешения.
3. Запусти простую Bash-команду.
4. Проверь сетевую команду.
5. Проверь попытку обратиться к файлу вне рабочей папки.
6. Посмотри фактический результат, а не только текст конфигурации.

Настройка может выглядеть корректной, но поведение не совпадает с ожиданием из-за версии, платформы или managed settings. Поэтому я всегда проверяю не только JSON или текст правил, но и реальную реакцию инструмента.

Безопасный допуск нужен, чтобы ошибка не могла затронуть production, настоящие данные и ключи. Защита нужна, чтобы даже при ошибке ущерб остался внутри рабочей папки.

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

Что ломается, если бездумно снять все разрешения?

Anthropic прямо предупреждает:

Ручное подтверждение кажется надёжным, пока запросов немного. Потом интерфейс начинает спрашивать одно за другим. Anthropic пишет, что пользователи одобряют 93% permission prompts. Такой процент сам по себе ничего не говорит о безопасности. Он показывает, что подтверждение легко превращается в автоматическую кнопку.

Опасные последствия не обязательно выглядят драматично. Агент может неверно понять инструкцию, удалить удалённые ветки Git или попытаться выполнить миграцию в production-базе. Он не обязан «хотеть навредить». Достаточно ошибки в цели и слишком широкого доступа.

Auto mode уменьшает число запросов, но остаётся компромиссом. В тесте на overeager behavior он пропустил около 17% опасных действий. Поэтому auto mode нельзя считать единственной защитой на важной инфраструктуре.

Sandbox тоже не магический купол. Он ограничивает Bash, но не объединяет в одну систему Read, Edit и Write. Также escape hatch позволяет повторить команду вне sandbox, если allowUnsandboxedCommands не запрещает такой выход.

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

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