Ключ к разумному использованию Claude Code - понять, что это не автокомплит с длинным ответом, а замкнутый цикл. На каждом шаге модель получает system prompt, инструкции, историю разговора и результаты прошлых вызовов инструментов, а затем решает: ответить текстом или вызвать tool. Если это вызов, runtime сопоставляет его с permissions, hooks и sandbox, инструмент выполняется или блокируется, результат возвращается модели - и цикл продолжается, пока задача не решена, не задан вопрос или не завершён turn.
Инструменты делятся на категории, и у каждой свой профиль риска. Чтение (Read, Glob, Grep) грозит утечкой секретов. Правка файлов (Edit, Write) - повреждением исходников и конфигов. Shell (Bash) - это произвольный subprocess, сеть и файловая система. Web (WebFetch, WebSearch) приносит внешние данные и риск prompt injection. Агентность, интеграции и состояние добавляют своё: параллельный расход, действия во внешних системах, ошибочную модель прогресса.
Есть тонкость, важная для правил и hooks: имя инструмента в транскрипте может отличаться от canonical-имени, по которому работают permission rules и hook-матчеры. Правило должно использовать именно канонический идентификатор из tools reference, а не то, что показано в логе. Если в deny или ask попадает неизвестное имя, новые версии показывают startup-предупреждение - это подсказка, что правило написано мимо реального инструмента.
Полезно один раз свести категории инструментов и их риск в таблицу, чтобы видеть, где проходит граница опасного. Ниже такая карта - от чтения до состояния. К ней возвращаются, настраивая permissions и sandbox: она напоминает, что не все инструменты равны, и что shell, web и агентность требуют более узких правил, чем безобидное на первый взгляд чтение, которое тоже может утечь секретами.
| Категория | Примеры | Риск |
|---|---|---|
| Чтение | Read, Glob, Grep | Утечка secrets и лишний контекст |
| Правка файлов | Edit, Write, NotebookEdit | Повреждение source/config/generated |
| Shell | Bash, PowerShell | Произвольный subprocess, сеть, ФС |
| Web | WebFetch, WebSearch |
| Внешние данные и prompt injection |
| Агентность | Agent, Workflow, tasks | Параллельный расход и конфликты |
|---|
| Интеграции | MCP, Chrome, computer use | Действия во внешних системах |
|---|
| Состояние | Todo, checkpoints, worktrees | Ошибочная модель прогресса |
|---|
Второе важное понимание - что модель реально знает. "Весь репозиторий" в контекст не попадает автоматически. Внутри - startup-prompt и определения инструментов, CLAUDE.md, rules без path-ограничения и auto memory, тексты ваших сообщений, фактически прочитанные файлы и выводы, summary после compaction, содержимое загруженных skills и результаты subagents (а не весь их транскрипт). Остального модель не видит, пока это не прочитано инструментом.
Отсюда следует правило, спасающее от ложной уверенности: утверждение "Claude понял проект" нужно подтверждать доказательствами, а не принимать на веру. Доказательства бывают четырёх уровней. Объяснение - модель описала предполагаемую причину. Статическая проверка - прошли typecheck, lint, компиляция или анализ diff. Динамическая - тест воспроизводит поведение и проходит после фикса. Наблюдение продукта - приложение собрано, запущено, и результат проверен через /run, /verify, браузер или ручной сценарий.
Хороший итог задачи выражает эти уровни явно: причина, изменённые файлы, команды с кодами возврата, что проверено наблюдением, что осталось непроверенным, какие риски сохраняются. Ниже - такой шаблон отчёта. Он превращает расплывчатое "готово" в проверяемое утверждение, по которому видно, на каком уровне доказательства остановился агент и где вам нужно перепроверить.
Причина:
Изменённые файлы:
Команды и exit codes:
Что проверено наблюдением:
Что не проверено:
Оставшиеся риски:Наконец, стоит держать в голове границу между checkpoint и git. Claude Code автоматически отслеживает правки файлов для rewind, но checkpoint - это локальный механизм сессии, а не долговременная история. Git остаётся системой истории, совместной работы и review; перед рискованным изменением полезно иметь чистый status или отдельный worktree. Типичный провал - принять объяснение за доказательство и понадеяться на checkpoint как на замену коммиту; правильный подход - требовать проверку наблюдением и держать git как настоящую страховку.