Как откатить изменения в Claude Code: /rewind, git и 5 способов в 2026

Claude Code сломал тебе код - и это чинится за секунды, если знать, каким инструментом откатывать. Внутри сессии выручает встроенная команда /rewind: мгновенный возврат файлов и диалога к нужной точке. Если правки уже вышли за пределы сессии, откатывает git checkout до последнего коммита. А если кто-то снёс работу деструктивной командой, последняя страховка - git reflog, в нём остаются хэши даже уничтоженных коммитов.

Три уровня, и каждый ловит свой класс аварий. /rewind не заменяет git, git не заменяет reflog. Знать только /rewind - значит остаться без защиты в первый же серьёзный косяк, когда Claude тронет не только файлы. Ниже разберём каждый уровень со своими командами и ограничениями, покажем реальную историю потери четырёх часов работы и настроим проект так, чтобы откатывать было почти нечего.

Что такое откат в Claude Code и почему трёх уровней мало

Откат тут устроен слоями, и это важно понять сразу, иначе будешь давить одну кнопку там, где нужна другая. Уровень первый - встроенный /rewind, возврат внутри текущей сессии. Уровень второй - git checkout, восстановление незакоммиченных правок средствами системы контроля версий. Уровень третий - git reflog, катастрофическая страховка на случай, если ветку переписали через git reset --hard.

Разберём на трёх типичных ситуациях, они хорошо показывают границы каждого уровня.

Возьмём эксперта, который включил /rewind в первую же неделю: Claude за пару промптов поломал auth-логику, человек откатился одним движением и пошёл дальше. Через месяц другая история - писал миграцию схемы, закоммитил, переключил ветку и понял, что забыл шаг. Тут /rewind уже бессилен, сессия другая. Спас git checkout на предыдущий коммит. Ещё через месяц он случайно дал агенту команду «откати всё к последнему пушу», агент выполнил git reset --hard и снёс три часа работы. Вытащил только git reflog, в нём остались хэши уничтоженных коммитов.

Три ситуации - три уровня защиты. Работают по-разному, ловят разные ошибки, и нужны все три.

Вот три уровня одной таблицей: что покрывает каждый и чего не умеет.

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

Как вызвать /rewind в Claude Code: команда или Esc Esc

Открыть меню отката можно двумя способами. Первый - напечатать /rewind в поле ввода. Второй - дважды нажать Esc, когда поле пустое. Если в поле уже есть текст, первое двойное Esc сначала очистит его и сохранит в историю, а меню откроет только повторное двойное нажатие. У команды /rewind есть алиас /checkpoint, он ведёт туда же.

Работает это потому, что после каждого своего ответа Claude автоматически делает снимок всех файлов, которые редактировал в этой сессии. Снимки лежат в ~/.claude/file-history/{sessionId}/ и держатся до 30 дней. Ты в любой момент можешь отмотать на любую точку своего рабочего дня.

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

[поле ввода пустое]
> _

[нажми Esc, Esc]

Rewind to which message?
  1. Сделай миграцию для User-таблицы          (3 файла изменены)
  2. Добавь поле lastLoginAt                    (1 файл изменён)
  3. Перепиши логику авторизации                (5 файлов изменены)
  ...

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

Если в поле prompt есть текст, двойной Esc сначала очистит его, а не откроет меню. Очищенный текст сохраняется в истории ввода, поэтому после меню отката его можно вернуть стрелкой вверх.

- Anthropic Docs, Checkpointing

Какой способ удобнее - дело привычки. Печатать /rewind нагляднее, если ты забыл про хоткей. Esc Esc быстрее, руки не уходят с клавиатуры.

Какие 6 режимов есть в Rewind-меню и какой выбрать

Выбрал точку отката - открывается второе меню, уже с шестью режимами. Три отвечают за восстановление состояния, два за сжатие истории, один просто закрывает меню. Самый частый режим - Restore code and conversation, вернуть и файлы, и диалог. Его и берёшь в девяти случаях из десяти.

Полная таблица, что делает каждый режим и когда он твой:

Режим Summarize up to here появился в Claude Code v2.1.139-v2.1.142, релиз пришёлся на 11-15 мая 2026, двадцатую неделю года.

Через меню отката можно сжать ранний контекст пунктом Summarize up to here.

- Anthropic What's new, Changelog

Разница между Restore и Summarize принципиальная, её стоит держать в голове. Restore возвращает состояние, то есть отменяет всё, что случилось после выбранной точки. Summarize ничего не отменяет, он только сжимает: оригинальные сообщения остаются в транскрипте сессии для справки, но в активном контексте живёт лишь сводка. Restore бери, когда хочешь «как будто этого вообще не было». Summarize - когда нужно «оставить, но не занимать место в контексте».

Если хочешь глубже разобраться, как режимы отката вписаны в общую иерархию управления Claude Code, посмотри разбор 7 уровней Claude Code.

Какие изменения /rewind не откатывает

Это главная ловушка, на которую натыкаются почти все. /rewind отслеживает только правки, сделанные Claude через его собственные тулы редактирования файлов. Всё остальное он не видит и вернуть не может. Три класса невидимых изменений: bash-команды (rm, mv, cp), внешние правки (твоя ручная правка в IDE, правки от других сессий) и операции за пределами файлов (миграции БД, push в git, удалённые вызовы API).

Выглядит это коварно: /rewind показывает зелёную галочку и рапортует «откат успешен», а проект всё равно сломан, потому что Claude трогал не только файлы. Разберём три случая по очереди.

1. Bash-команды не отслеживаются. Если Claude в своём ходе выполнил rm file.txt или mv old.txt new.txt, эти изменения в снимок не попадут. Документация Anthropic говорит об этом прямым текстом.

Контрольные точки не отслеживают файлы, изменённые через bash-команды. Например, если Claude Code запустит rm file.txt, mv old.txt new.txt, cp source.txt dest.txt - эти изменения файлов через откат вернуть нельзя.

- Anthropic Docs, Checkpointing

То есть если Claude по своей инициативе через bash-тул удалил, переместил или скопировал файл, /rewind назад всё не откатит. Спасёт git checkout или восстановление из бэкапа, но это уже не нажатие двух кнопок.

2. Внешние правки не ловятся. Открыл файл руками в VS Code и что-то поправил, или вторая сессия Claude параллельно меняла те же файлы - первая сессия этих изменений не видит. Снимок сделан на момент завершения хода Claude в текущей сессии. Что произошло между ходами, снаружи его зоны ответственности.

3. Операции вне файлов не охватываются совсем. Миграция Prisma через npx prisma migrate dev изменила схему базы - /rewind её не откатит, потому что база живёт за пределами файловой системы проекта. Force-push в origin/main - та же история: коммит уехал на удалённый сервер, контрольная точка его не вернёт. Удалённый вызов API, который списал деньги или удалил запись, откатывается только средствами самого API.

/rewind vs git: чем отличаются и зачем нужны оба

/rewind - это локальный откат внутри одной сессии Claude Code. Хранит снимки до 30 дней, до 100 на сессию, инкрементально. Git - долгосрочная история всего проекта: коммиты, ветки, merge-конфликты, удалённый репозиторий, общий для команды. Один не заменяет другой. Практика простая: делаешь git commit на каждой логической вехе, а между коммитами полагаешься на /rewind.

В документации Anthropic эта связка зафиксирована прямо.

Контрольные точки сделаны для быстрого восстановления на уровне сессии. Для коммитов, веток и долгой истории продолжай пользоваться системой контроля версий (например, Git). Они дополняют, но не заменяют нормальный version control. Думай о контрольных точках как о local undo, а о Git как о permanent history.

- Anthropic Docs, Checkpointing

Различия удобнее смотреть в таблице:

Связка на практике такая. Каждый раз, когда дошёл до состояния «вот это уже работает, терять не хочу», делаешь git commit. Между коммитами полагаешься на /rewind: он мгновенный, не требует писать сообщение, не засоряет git-историю промежуточными состояниями. Работа закончена - коммит, желательно осмысленный и атомарный.

Откат - это частный случай контекст-инжиниринга. Когда ты управляешь контекстом сессии (когда коммитить, когда жать /rewind, какие правила в CLAUDE.md), Claude становится предсказуемым и перестаёт ронять проект. Сам по себе навык узкий: уметь вернуть состояние, когда оно сломалось. Но в связке с планированием и правилами проекта он даёт стабильную работу вместо ежедневной борьбы с галлюцинациями.

Как разработчик потерял 4 часа из-за git reset —hard

Показательная история, задокументированная в трекере Claude Code. 9 января 2026 разработчик Jeff Kelling попросил Claude Code «сохранить текущее состояние и откатиться к последнему пушу». Claude сделал git stash (правильно), а следом git reset --hard 35eb731 (деструктивно). Около четырёх часов работы исчезли. Три урока из этого: «откатить» в естественном языке означает «посмотреть историю», а не «уничтожить её»; Claude по умолчанию должен предлагать git checkout, а не reset --hard; защита ставится в CLAUDE.md.

Случай зафиксирован в GitHub Issue #17190 репозитория anthropics/claude-code, закрыт как дубликат, но описан подробно. Версия Claude Sonnet 4.5, формулировка пользователя была такой:

Хочу сохранить, где мы сейчас, и ОТКАТИТЬСЯ к последнему push.

- Jeff Kelling, GitHub Issue #17190

Claude выполнил последовательно две команды:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # сохранил незакоммиченные правки
git reset --hard 35eb731                                                # уничтожил коммиты d63695e..882e618

Первая команда правильная, она спрятала незакоммиченные изменения в stash. Вторая деструктивная: переписала ветку на коммит 35eb731, и все коммиты между ним и 882e618 стали orphaned, сиротами. По умолчанию такие коммиты живут в .git/objects/ до запуска git gc, который обычно срабатывает автоматически в течение двух недель. Но если в этот момент ты не знаешь, что делать, время работает против тебя.

Главный урок сам пострадавший сформулировал в комментарии к issue:

НИКОГДА не используй git reset —hard, пока я явно не произнесу именно эти слова.

- Jeff Kelling, GitHub Issue #17190

Логика тут прямая. В живой речи «roll back», «go back», «restore», «revert», «undo» значат «посмотреть назад» или «вернуться в безопасное место». Они не про уничтожение истории. А git reset --hard именно уничтожает: переписывает ветку и убирает коммиты из достижимых через HEAD. Безопасная альтернатива - git checkout <commit>, она создаёт detached HEAD и даёт посмотреть старое состояние, не трогая ветки.

Практический вывод один: перед любой ёмкой задачей, особенно перед рефакторингом нескольких файлов, делай git commit текущего состояния. Один коммит превращает любой косяк Claude в одну команду git checkout . без потери работы.

Как git reflog спасает после деструктивного reset

git reflog показывает локальную историю всех движений HEAD в репозитории, включая те коммиты, которые снесли через git reset --hard или force-push. Каждое движение хранится 90 дней по умолчанию. Если Claude (или ты сам, или коллега) уничтожил коммиты деструктивной командой, git reflog покажет их хэши, и ты восстановишь ветку через git reset --hard <reflog-hash>.

История из прошлого раздела закончилась бы хорошо, запусти Jeff git reflog сразу:

git reflog

Вывод выглядит примерно так:

35eb731 HEAD@{0}: reset: moving to 35eb731
882e618 HEAD@{1}: commit: middleware refactoring complete
d63695e HEAD@{2}: commit: leaveRemove method finalized
1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled
35eb731 HEAD@{4}: pull origin main

Строки HEAD@{1} - HEAD@{3} и есть те самые «уничтоженные» коммиты. Из локального хранилища объектов git они никуда не делись, просто стали недоступны через ветку. Чтобы вернуть:

# Создать ветку из последнего «уничтоженного» коммита
git branch recovered-work 882e618

# Или переключиться напрямую
git reset --hard 882e618

После этого ветка снова содержит всю историю до катастрофы.

У reflog есть ограничения, про которые стоит знать заранее:

• Только локально. Reflog лежит в .git/logs/HEAD, на удалённом репозитории его нет. Сделал force-push и потом удалил локальную копию репо - reflog ушёл вместе с папкой.
• 90 дней по умолчанию. Старше - git gc может их вычистить. Настраивается через git config gc.reflogExpire 200.days.ago.
• Не покрывает то, чего никогда не было в HEAD. Если коммит был только в stash и stash уничтожили, reflog покажет лишь последнее состояние stash, а не его внутреннюю историю.

Как защитить проект от разрушающих git-команд через CLAUDE.md

В CLAUDE.md твоего проекта добавляешь блок с инструкцией: какие git-команды Claude может выполнять сам, какие требуют явного подтверждения, какие запрещены без точной фразы. Claude уважает CLAUDE.md как системный промпт проекта и по умолчанию этим правилам следует. Один такой блок превращает опасный промпт «откати всё» в две безопасных команды с вопросом к тебе.

Корень проблемы из issue #17190 в том, что у Claude по умолчанию нет защитного контекста. Он трактует «roll back» как git reset --hard, потому что технически это валидный способ. Защиту мы переносим в CLAUDE.md, файл с системным промптом проекта.

Минимальное правило, вставляешь в свой CLAUDE.md:

## Git Safety Protocol
 
- NEVER run destructive git commands (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) unless I explicitly request these actions. Taking unauthorized destructive actions is unhelpful and can result in lost work.
- When I say "roll back", "go back", "restore", "revert", "undo" - interpret as REVIEW commands: use `git log`, `git diff`, `git checkout <commit>` (creates detached HEAD), or `git stash` (preserves changes).
- ALWAYS ask for confirmation before ANY command that:
  - Changes HEAD position to a different commit on a branch
  - Modifies commit history
  - Could lose uncommitted work
  - Includes flags --hard, --force, --aggressive
- Before any destructive command, output a numbered comparison:
  - SAFE: use `git checkout <commit>` to view temporarily
  - DESTRUCTIVE: use `git reset --hard` to permanently destroy
- Wait for my explicit choice before executing.

Расширенное правило для командной работы, добавляешь в CLAUDE.md корня репозитория:

## Git Workflow Rules
 
- Commit на каждой логической вехе. Если задача длиннее 30 минут и ты ещё не коммитил - сначала `git add . && git commit -m "wip: [что сделано]"`, потом следующий шаг.
- Никогда `git add .` или `git add -A` для коммитов от Claude. Только конкретные файлы по имени, после `git status` и `git diff`.
- Перед `git push --force` в main - стоп, спроси меня. В feature-ветках force-push с осторожностью, только если уверен, что я готов потерять предыдущую версию.
- При merge-конфликтах никогда не выбирай "ours" или "theirs" сразу - сначала покажи мне обе версии, потом я решу.
- `.gitignore` обязан содержать `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. Если их нет - добавь.

После этих блоков следующая фраза «откати к последнему пушу» приведёт уже к другому ответу Claude:

Вижу 3 незакоммиченных файла и 4 коммита впереди последнего пуша. Два варианта. SAFE: создать ветку view-last-push через git checkout последнего пуш-хэша, сохраню всю работу и временно покажу состояние пуша. DESTRUCTIVE: git reset —hard на этот хэш, уничтожу 4 коммита и незакоммиченные правки навсегда, восстановить можно будет только через git reflog в течение 90 дней. Что выбираешь?

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

Какие 5 способов отката есть в Claude Code и как выбрать нужный

Когда что-то пошло не так, у тебя пять уровней отчаяния: /rewind (внутри сессии), git checkout . (незакоммиченные правки), git checkout <commit> (вернуться на старый коммит без потери истории), git reset --hard <commit> (вернуть ветку, потеряв коммиты впереди), git reflog с восстановлением (катастрофа, всё пропало). Каждый следующий уровень тяжелее и опаснее предыдущего.

Сценарий «Claude сломал, надо срочно вернуть» проходят снизу вверх по этой лестнице. Начинай всегда с первого уровня.

Уровень 1. /rewind - мгновенный откат внутри сессии. Жми Esc Esc или печатай /rewind. Выбирай точку до момента слома, выбирай режим (обычно Restore code and conversation). Через секунду ты в прошлом и можешь начать заново. Закрывает 80% случаев «Claude сделал не то».

Уровень 2. git checkout . - отмена всех незакоммиченных правок.

git diff                          # сначала посмотри, что вообще изменилось
git checkout .                    # отменить все незакоммиченные правки во всех файлах
# или избирательно:
git checkout -- path/to/file.ts   # только один файл

Полезно, когда /rewind не сработал (Claude трогал файлы через bash) или когда нужна отмена в обход истории сессии. Все незакоммиченные изменения исчезнут безвозвратно. Жалко - сначала git stash.

Уровень 2.5. git stash - сохранить правки на полку.

git stash save "может, ещё понадобится"
# вернуться к чистому состоянию, поработать
# передумал - вернуть из stash:
git stash pop

Компромисс между «потерять навсегда» и «оставить как есть». Stash живёт локально до явной чистки.

Уровень 3. git checkout <commit> - вернуться на старый коммит без потери истории.

git log --oneline               # найди хэш нужного коммита, например abc1234
git checkout abc1234            # detached HEAD - смотришь, ничего не меняешь
# понравилось состояние - создай ветку из него:
git checkout -b recovery abc1234
# вернуться обратно:
git checkout main

Безопасный «временный возврат». Detached HEAD не меняет ветку, текущая работа в main остаётся целой. Хочешь поработать с этим состоянием - делай ветку.

Уровень 4. git reset --hard <commit> - вернуть ветку на точку. Деструктивно, коммиты впереди указанного хэша станут orphaned.

git reflog                       # запомни хэш текущего состояния
git reset --hard abc1234         # переписать ветку
# обнаружил ошибку - вернись через reflog:
git reset --hard HEAD@{1}        # туда, где был до reset

Используй только если уверен, что коммиты впереди тебе не нужны. И всегда смотри git reflog ДО reset, чтобы знать, куда возвращаться, если передумаешь.

Уровень 5. git reflog с восстановлением - катастрофический сценарий. Кто-то уже снёс работу через git reset --hard или force-push.

git reflog                                 # ищи последний хэш до катастрофы
git branch recovered HEAD@{N}              # создай ветку оттуда
git checkout recovered                     # переключись
git diff main                              # сверь с текущим состоянием
git checkout main && git merge recovered   # вернуть в main, если уверен

Если reflog уже почистился (90 дней по умолчанию), последний шанс - git fsck --lost-found, он покажет «болтающиеся» коммиты в .git/objects/. Почти археология, но иногда выручает.

Таблица выбора уровня, чтобы не думать в панике:

Как защитить проект, чтобы откатывать было нечего

Лучший откат - тот, который не понадобился. Три базовых правила защиты: коммит каждые 30 минут даже на черновом коде; .gitignore с обязательными строками для .claude/personal/ и .env*; крупные эксперименты в отдельной ветке через git checkout -b. С такой настройкой даже катастрофическая ошибка Claude обойдётся максимум в полчаса потерянной работы.

Правило 1. Коммит каждые 30 минут. Не жди «когда задача готова». Любой промежуточный шаг, который работает, коммитится. Сообщения могут быть любыми, главное - чтобы ты (или Claude) мог откатиться на рабочее состояние одним git checkout.

# в начале задачи
git status                        # проверь, что нет лишнего
git add .
git commit -m "wip: начинаю миграцию схемы User"

# через 30 минут или после первой рабочей итерации
git add .
git commit -m "wip: User-схема готова, миграция применена локально"

# в конце задачи - осмысленный коммит
git reset --soft HEAD~2           # объединить wip-коммиты в один
git commit -m "feat(auth): добавлено поле lastLoginAt в User-таблицу"

Это можно даже автоматизировать хуком Claude Code: в .claude/settings.json добавляешь PostToolUse-хук, который раз в N минут делает авто-коммит.

Правило 2. .gitignore минимум. В корне проекта обязательны строки:

# секреты
.env
.env.local
.env.*.local

# локальные настройки Claude Code (не пушим в командный репозиторий)
.claude/personal/
.claude/sessions/
.claude/file-history/

# зависимости и сборка
node_modules/
dist/
.next/
build/

Папку .claude/personal/ держишь для своих экспериментов и заметок, которым не место в общем репо. .claude/sessions/ и .claude/file-history/ - локальное хранилище Claude Code, оно много весит и привязано к конкретной машине, в репозитории ему делать нечего.

Правило 3. Эксперименты в отдельной ветке. Задача большая (рефакторинг на 10+ файлов, миграция на новую базу, переписывание модуля) - не делай её в основной ветке.

git checkout -b experiment/auth-rewrite
# работаешь, коммитишь каждые 30 минут
# получилось:
git checkout main
git merge experiment/auth-rewrite
# не получилось:
git checkout main
git branch -D experiment/auth-rewrite     # удалить ветку
# основная ветка целая

Эта привычка превращает «Claude разнёс проект» в «Claude разнёс одну ветку, я её удалил, начинаем заново».

Куда откат встроен: план, правила и память проекта

Откат - не отдельный трюк, а часть управления контекстом сессии Claude Code. Когда ты знаешь, когда жать /rewind, когда git commit, когда git stash, ты управляешь целым потоком работы, а не одной командой. И тогда откатываться приходится редко, потому что рядом стоят ещё четыре рубежа защиты.

Первый рубеж - Plan Mode. Он не даёт сразу писать код: сначала план, потом твоё подтверждение, потом исполнение. Это превентивный откат, ты просто не пишешь то, что придётся откатывать, потому что план просмотрен заранее.

Второй - CLAUDE.md с правилами, которые Claude уважает по умолчанию, включая тот самый Git Safety Protocol. Превентивная защита от деструктивных команд.

Третий - память проекта между сессиями: Claude знает твой код, твою бизнес-логику, прежние договорённости. Чем больше памяти, тем меньше шансов, что он сделает не то.

Четвёртый - скиллы и субагенты, твоя методология в коде. Если в скилл зашит правильный git-workflow, ни один субагент не выполнит git reset --hard без подтверждения.

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

Чек-лист: что у тебя теперь есть

• Понимание трёх уровней отката: /rewind внутри сессии, git checkout до коммита, git reflog после катастрофы
• Умение вызвать меню отката двумя способами (/rewind и Esc Esc) и выбрать один из шести режимов
• Ясность, что /rewind не ловит: bash-команды, внешние правки, миграции БД, push
• Готовый рецепт восстановления коммитов после git reset --hard через git reflog
• Блок Git Safety Protocol для CLAUDE.md, который запрещает Claude деструктивные команды без твоей явной фразы
• Таблица выбора уровня отката под любую аварию
• Четыре правила защиты, чтобы откатывать было почти нечего: коммит каждые 30 минут, .gitignore, ветки под эксперименты, теги перед опасными операциями