Claude Code через Git: 7 шагов в 2026 году для передачи контекста между сессиями

Что именно нужно сохранить, чтобы Claude Code продолжил незавершённую задачу?

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

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

Cross-session messaging решает другую задачу. Одна сессия сообщает другой найденную поломку, принятое решение или статус тестов. Это короткий текстовый канал для передачи факта или статуса между сессиями.

Документация описывает сообщение как текст, который одна сессия передаёт другой; история разговора и файлы не передаются.

• Официальная документация Claude Code, Cross-session messaging

Выбирай так:

Разрешения тоже не переходят. Если первая сессия могла выполнить действие, это не означает, что вторая получит те же права.

Как передать незавершённую задачу через Git в новую сессию?

Я использую Git здесь для фиксации состояния. Он передаёт состояние файлов и оставляет след, который можно проверить.

Перед переключением сначала посмотри, что изменилось:

git status
git diff

После проверки зафиксируй результат:

git add .
git commit -m "Save progress on password reset"

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

Порядок такой:

1. Убедись, что текущий кусок работы не сломан.
2. Запусти проверку, которая относится к этому куску.
3. Посмотри изменения через git diff.
4. Создай коммит с понятным сообщением.
5. Передай следующей сессии идентификатор коммита и ближайшую задачу. Такой handoff можно сверить с Git, а не восстанавливать по памяти.

Я бы не отправлял сообщение «продолжи проект». В нём нет контрольной точки. Лучше написать: «миграция сохранена в коммите, тесты проходят, следующий файл такой-то». Сам код лежит в Git, а смысл перехода лежит в коротком handoff.

Как сохранить план Claude Code между сессиями?

План в переписке исчезает из практической работы, когда начинается новая сессия. Поэтому запрос claude code plans лучше закрывать внешним state-файлом, а не новым пересказом в чате. Даже если старая история доступна через resume, для долгой задачи полезнее иметь короткую внешнюю запись.

Подойдёт файл с таким содержанием:

# Task state

## Done
- created password reset migration
- added reset token model
- unit tests pass

## Blocked
- email provider is not configured

## Next
- implement POST /auth/password-reset/confirm
- run integration tests

## Do not
- change the database schema
- replace the email provider

Блоки служат рабочими ориентирами. Они отвечают на четыре рабочих вопроса:

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

Anthropic отдельно советует использовать чек-листы и scratchpad для сложных процессов. Внешний файл переживает завершение context window и не требует восстанавливать план по памяти.

Не превращай список в техническое задание на весь продукт. Чем крупнее следующий пункт, тем выше шанс, что агент снова начнёт делать всё сразу. Для claude code switch оставь один ближайший шаг, который можно проверить отдельно.

Как перенести договорённости из чата Claude Code в новую сессию?

Если ты ищешь, как перенести историю чата Claude Code в новую сессию, для полной беседы нужен resume. Короткое сообщение работает иначе. Запрос claude code prompts здесь полезно разделить на две части: что передать новой сессии и что попросить её проверить.

Хороший handoff отвечает на пять вопросов:

1. Что изменилось?
2. Где это лежит?
3. Какое решение принято?
4. Что делать дальше?
5. Чего не делать?

Пример:

Auth: миграция password reset сохранена в коммите 8f31c2a.
Таблица токенов использует user_id, а не email.
Изменения находятся в src/auth/reset.ts и migrations/014_reset_tokens.sql.
Следующий шаг: реализовать endpoint подтверждения сброса пароля.
Не создавай новую миграцию и не меняй схему базы.
Проверь результат командой npm test -- reset.

Такое сообщение передаёт решение и направление, но не выдаёт второй сессии разрешения на действия. Получатель сам читает файлы и проверяет Git.

Я бы отправлял сообщение после фиксации кода и обновления файла состояния. Если сделать наоборот, текст может описывать правку, которая ещё не сохранена или уже изменилась.

Практикум по вайб-кодингу нужен именно на этом стыке: там руками собирается связка из постановки задачи, внешнего контекста, проверки и безопасного перехода между итерациями. Посмотри программу: . О том, как не потерять рабочие правила при передаче агенту, смотри также разбор CLAUDE.md.

Что записать в CLAUDE.md для следующей сессии?

Я разделяю два слоя и не смешиваю постоянные правила с текущим прогрессом. Для запроса claude code settings это важное различие: настройки и правила проекта живут отдельно от временного handoff.

В CLAUDE.md живут правила, которые должны действовать долго. Например, принятые ограничения и сжатые документы проекта. Такие документы становятся контекстом для будущей отладки и работы нескольких экземпляров Claude Code. О структуре файла и границах постоянных правил смотри отдельную инструкцию по CLAUDE.md.

Разовый прогресс хранится в другом месте:

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

Не складывай в CLAUDE.md запись «сегодня сделай endpoint». Через день она превратится в старую инструкцию. Постоянные правила и текущая задача должны оставаться разными внешними артефактами.

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

Как продолжить работу Claude Code на другом устройстве?

На одной машине локальный обмен идёт через per-session socket. Между машинами сообщения проходят через серверы Anthropic и зависят от Remote Control, как описано в официальной документации.

Проверь ограничения до попытки передачи:

• 2.1.224+ нужен для cross-session messaging;
• 2.1.225+ нужен, чтобы начать разговор с сессией на другой машине;
• macOS и Linux поддерживаются;
• WSL 2 входит в поддерживаемый сценарий;
• native Windows не поддерживается;
• для межмашинной передачи нужен Remote Control.

Важное различие: Remote Control не делает историю чата общей автоматически. Remote Control даёт путь к удалённой сессии. Рабочее состояние всё равно лучше держать в Git и файле прогресса.

Точная процедура запуска Remote Control здесь не нужна для handoff. Безопасная схема такая: обеспечить нужную версию, запустить Remote Control, убедиться, что целевая сессия видна, затем передать короткое сообщение и проверить результат уже на машине получателя. Для параллельных локальных сессий смотри разбор Agent-Manager.

Как переключиться на новую сессию Claude Code без потери задачи?

1. Заверши текущий кусок работы.

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

   Если задача ещё не закончена, запиши именно промежуточное состояние: что уже работает и где осталась граница.

2. Обнови файл состояния.

   Открой файл прогресса или scratchpad и заполни блоки Done, Blocked, Next и Do not.

   markdown

   Скопировать

   ## Done
   - added reset token model
   
   ## Blocked
   - email provider is not configured
   
   ## Next
   - implement confirmation endpoint
   
   ## Do not
   - change database schema

3. Запусти проверочные тесты.

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

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

4. Зафиксируй изменения в Git.

   Посмотри статус и diff, затем создай коммит с понятным описанием.

   bash

   Скопировать

   git status
   git diff
   git add .
   git commit -m "Save progress on password reset"

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

5. Отправь конкретное сообщение.

   Передай одну полезную связку: изменение, место, решение, следующий шаг и запрет.

   Сообщение следующей сессииСкопировать промпт

   Password reset migration is committed as 8f31c2a.
   Token table uses user_id, not email.
   Next: implement the confirmation endpoint in src/auth/reset.ts.
   Do not create another migration.
   Verify with npm test -- reset.

6. Открой новую сессию.

   Не проси её сразу «продолжить всё». Сначала дай прочитать файл состояния и Git. Если нужно сменить режим работы, сформулируй claude code switch как одну конкретную операцию, а не как просьбу переписать проект.

   Текст для старта:

   Старт новой сессииСкопировать промпт

   Read the project state file, inspect the latest Git commit, and verify the current tests.
   Take only the next task from the Next section.
   Do not redo completed work.
   Report blockers before changing files.

7. Проверь результат новой сессии.

   Сверь файлы, статус Git и тесты после следующего небольшого изменения.

   Если результат не совпал с handoff, остановись и обнови файл состояния. Не позволяй агенту перекрывать неопределённость массовой переписью проекта.

Что делать, если сообщение не приходит или сессии конфликтуют?

У канала есть несколько отдельных поломок.

Сообщение может иметь статус delivered, held или refused. В режиме ожидания оно может истечь через пять минут. Очередь сообщений, ожидающих чтения Claude, ограничена 50 сообщениями, а очередь удерживаемых сообщений составляет 100. Эти значения и статусы приведены в документации cross-session messaging, поэтому перед публикацией их стоит сверять с актуальной версией. Фразу «я отправил» нельзя считать доказательством получения.

Проверь сессию через:

/list-agents

Но список не сообщает автоматически:

• кто пишет код;
• какие файлы открыты;
• какая задача выполняется;
• занята ли сессия;
• ждёт ли она одобрения.

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

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

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