1. Цифровые следы Claude Code
Git baseline, проектные правила, граница разрешений, общие инструкции — безопасный старт почти собран. Остался тихий слой: следы сессии.
Сессия не исчезает с закрытием окна. Компьютер складывает всё: историю диалога, вывод команд, снимки файлов, точки отката, память о проекте. В Commerce OS Claude видит файлы, логи, результаты команд — и локально оседают артефакты с тем, что вы не собирались показывать: внутренние адреса, конфиги, токены, клиентские данные, секрет из вывода неудачной команды.
Карта того, что остаётся:
| Что может остаться локально | Откуда это берётся | Чем это опасно |
|---|---|---|
| История сессий и transcripts | ваши сообщения и ответы Claude | туда могут попасть внутренние детали проекта, ссылки, имена модулей, чувствительные данные |
| История запросов | то, что вы отправляли в Claude | иногда там остаются куски логов, конфигов и неудачно вставленные фрагменты |
| Вывод инструментов и команд | git diff, docker compose logs, cat, результаты тестов | именно здесь чаще всего «выпрыгивают» секреты и внутренние адреса |
| Снимки файлов и контрольные точки | автосохранения и точки отката | в них могут жить старые версии файлов с чувствительным содержимым |
| Память о проекте | автоматически запомненные правила и факты | там может осесть устаревшая или вообще неверная информация |
Детали хранения наизусть не нужны — они меняются по версии и среде. Правило проще: видел Claude данные через файл, команду или ваш текст — следы могли остаться.
flowchart TD
A["Вы открыли файл или запустили команду"] --> B["Данные появились в выводе"]
B --> C["Claude получил этот вывод в сессии"]
C --> D["Следы остались в transcripts или snapshots"]
D --> E["Позже вы делитесь логом, скриншотом или проектом"]
Утечка редко выглядит как «я выложил секрет в интернет». Чаще: скриншот терминала коллеге, лог в тикет, transcript ментору, gist. Local data hygiene — это инженерная аккуратность, не паранойя.
2. Типичные места утечки secrets
Большинство утечек начинается с «сейчас быстро покажу Claude, что у меня в .env». После этого секрет уже не в файле — он путешествует по логам, transcripts и выводам инструментов.
Секреты живут не в одном месте: .env, переменные окружения контейнеров, вывод неудачных команд, экспортированные CSV, дампы конфигурации, тестовые webhook-ключи, логи платёжных интеграций. В Commerce OS особенно опасно всё про базу, платежи, интеграции поддержки и внутренние сервисы. Сырой доступ без нужды — и чувствительное размазано по новым артефактам.
Привычка одна: Claude видит структуру конфигурации, но не реальные секреты. Для этого и есть разделение .env и .env.example.
.env
.env.*
!.env.example
.claude/CLAUDE.local.md
.claude/settings.local.json
Реальные значения не уходят в репозиторий, а шаблон остаётся опорой для разговора с Claude.
Пример шаблона:
# Локально заполните своими значениями
POSTGRES_URL=postgres://app:ваш_пароль@localhost:5432/commerce
STRIPE_SECRET_KEY=sk_test_заполните_локально
SUPPORT_API_TOKEN=token_заполните_локально
PAYMENT_WEBHOOK_SECRET=whsec_заполните_локально
Claude анализирует, какие переменные нужны проекту, не видя значений. Вопрос не «прочитай мой секрет», а «скажи, чего приложению не хватает по шаблону и конфигам».
Хорошая постановка:
Проверь, какие переменные окружения нужны приложению.
Используй `.env.example`, `README.md` и конфиги запуска.
Файл `.env` не открывай.
Реальные значения ключей не запрашивай.
Если переменной не хватает, перечисли только её имя.
Задачу не скрываете, лишнее не тащите. Одна строчка экономит много нервов.
Проверяйте себя: покажу завтра этот transcript коллеге или ментору — будет ли там то, что нельзя показывать? «Возможно» — значит, уже зашли слишком далеко.
3. Transcripts, логи и публикация
«Я же просто отправил лог в поддержку» — типовая ошибка с лицом невинности. Лог, transcript или скриншот терминала — не текст, а пакет данных: адреса, токены, почты, внутренние хосты, идентификаторы клиентов. Вспоминаешь о них через две минуты после отправки.
Делясь чем-то наружу — интернет, чат команды, тикет, ментор — думайте не «это вывод команды», а «это артефакт, который надо подготовить»: очистить, сократить, спрятать лишнее. Это sanitation.
Нагляднее на примере:
До очистки:
Authorization: Bearer sk_live_xxxxx
DB host: pg-prod.internal.company
Customer email: olga@company.com
После очистки:
Authorization: Bearer ***REDACTED***
DB host: ***INTERNAL_HOST***
Customer email: ***REDACTED_EMAIL***
Лог не теряет пользы: видно авторизацию, проблему во внутренней базе, клиентские данные в потоке. Чувствительного больше не торчит.
То же с transcripts. «Удобно для разбора» не значит «слать как есть». Перед отправкой пройдитесь по категориям:
токены и ключи; внутренние домены и IP; e-mail и персональные данные; реальные ID заказов и платежей; содержимое .env; служебные пути компании.
Отдельный момент — handoff проекта между машинами или людьми. Кажется, что это просто git push. На деле шире: локальные заметки, чувствительные transcripts, старые снимки, история сессий — передаёте не только код, но и шлейф вокруг него. Перед сменой машины, публикацией учебного репозитория и показом материалов думайте о локальном состоянии, а не только о репозитории.
4. Длинная сессия дороже и глупее
Свести usage к деньгам — узко. Даже бесплатная сессия с длинным грязным контекстом дорога по времени, вниманию и качеству. Уставшая сессия думает хуже: AI путается, когда на стол высыпали сразу все бумаги из шкафа.
Команда или экран для usage в Claude Code есть. Названия меняются от версии к версии — сомневаетесь, смотрите /help и подсказки продукта. Смотрят usage не ради статистики, а чтобы понять, где вы начали платить за хаос.
«Дорогими» оказываются типовые паттерны:
| Паттерн | Что обычно происходит | Что лучше сделать |
|---|---|---|
| Вставили огромный лог целиком | Claude тратит внимание на шум и теряет саму задачу | дать только фрагмент вокруг ошибки |
| Пять попыток подряд чинить одно и то же | в сессии накапливаются старые гипотезы и путаница | остановиться и пересобрать контекст |
| Держите одну сессию «на всё» | смешиваются несвязанные задачи и решения | разделять работу по задачам |
| Оставили фоновую работу висеть без нужды | растут затраты и теряется управляемость | закрывать лишнее и фиксировать состояние |
| Подключили лишние инструменты и плагины | растёт контекстная нагрузка | держать только то, что реально нужно |
Замечайте не только стоимость, но и симптом качества. Claude повторяет старую неверную гипотезу, забывает границы задачи, просит перечитать прочитанное, предлагает «на всякий случай переписать половину проекта» — это не злая воля. Сессия располнела и устала.
Тогда не уговаривайте модель ещё одним уточнением — сделайте шаг назад. Иногда хватает сократить лог и переформулировать вопрос; иногда лучше начать свежую сессию; иногда — разбить задачу на две. После «ещё один разок» начинается цифровая археология.
Перед длинной вставкой задайте два вопроса:
это действительно нужно модели для решения задачи?
если убрать девять десятых текста, останется ли суть?
В девяти случаях из десяти на второй ответ «да». Знак, что сессией управляете вы, а не она вами.
5. Безопасная модель работы: пять опор
Безопасная работа держится не на одном приёме, а на нескольких опорах. Уберёте любую — система не рухнет мгновенно, но станет заметно хрупче.
| Опора | Вопрос, который стоит задать себе |
|---|---|
| Git baseline | Я точно работаю в понятной ветке и из чистого состояния? |
| Permissions | Claude не может больше, чем нужно для этой задачи? |
| Project instructions | Он знает команды, правила и границы проекта? |
| Local data hygiene | Я не тащу в сессию секреты и не размазываю их по логам? |
| Review человеком | Я всё равно проверю diff и результат сам? |
Опоры соединяются с CLAUDE.md, который вы писали в прошлой лекции. Туда уместно вписать напоминание о data hygiene, чтобы не надеяться на память:
## Гигиена данных
- не читать `.env` и файлы с секретами без явной причины
- для конфигурации опираться на `.env.example`
- перед публикацией логов и transcripts делать sanitation
- при длинной сессии сначала сократить контекст, потом продолжать
Это не жёсткая защита, а контекст для себя и для Claude. .gitignore, permissions и человеческий контроль он не заменит, но напоминает о правильном поведении, когда хочется срезать угол.
Обычная ситуация: открываете Commerce OS или pet-проект — чистая ветка, понятный scope, умеренный permission mode, короткий CLAUDE.md, нормальный .env.example, secrets только локально. Показали Claude нужный кусок лога, а не весь сериал. Посмотрели diff и не отправили transcript без очистки. Это и есть спокойная, взрослая работа.
Так формула уровня становится привычкой: безопасный Claude Code workflow — это Git baseline, аккуратные permissions, полезные project instructions, чистая local data hygiene и обязательный человеческий review. Когда эти пять вещей на месте, Claude ускоряет разработку. И только тогда имеет смысл говорить с ним не бытовым «сделай вот это», а инженерной задачей — с границами, критериями и проверкой.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ