Куда деваются сессии Claude Code desktop при смене аккаунта

Я веду несколько аккаунтов Claude, потому что существуют недельные лимиты: когда один аккаунт упирается в лимит, я переключаюсь на следующий. Каждое переключение перестраивает список сессий в desktop-приложении Claude Code, и сессии предыдущего аккаунта пропадают из окна, но не с диска. В апреле на этой машине было около 710 сессий в шести папках аккаунтов, примерно 49 МБ истории, а приложение показывало из них 69. В этом посте описано, где сессии физически лежат, четыре скрипта, которые я написала, чтобы их находить и восстанавливать, что я намеренно не стала автоматизировать и почему мой настоящий долгосрочный ответ — handoff-файл в собственном репозитории. Пересмотрено в сентябре 2026 года: добавлены исправления и то, что с этими сессиями произошло с тех пор.

Где лежат сессии

На macOS desktop-приложение хранит каждую сессию в ~/Library/Application Support/Claude/claude-code-sessions/<accountId>/<orgId>/local_<sid>.json. На Windows та же структура лежит в %APPDATA%\Claude\claude-code-sessions\. Нигде это не документировано. В апреле документация desktop-версии говорила, что каждый разговор — это сессия со своей историей чата, папкой проекта и изменениями кода, и ни слова о том, где она хранится.

Имя папки взято из бандлового JavaScript приложения: в .vite/build/index.js, в строке 771, стоит const $6t="claude-code-sessions". Автор issue #29373 нашёл ту же строку, и папка действительно была на моей машине. Приложение загружает сессии только из папки активного аккаунта, поэтому сессии всех остальных аккаунтов остаются на диске целыми и не видны в окне. Быстрый скрипт по папкам дал такой результат:

[372ac280…] sessions=4    size=2K     last=2026-04-13  → a test account
[4d1f33a2…] sessions=330  size=44M    last=2026-04-08  → the main archive (abandoned)
[a4ea2866…] sessions=83   size=4.5M   last=2026-04-10  → archive
[a9e945b6…] sessions=83   size=252K   last=2026-04-26  → recent parallel
[be2110e2…] sessions=69   size=203K   last=2026-04-29  → ACTIVE RIGHT NOW
[c53acc1e…] sessions=141  size=244K   last=2026-04-26  → recent parallel

Шесть аккаунтов, а не четыре, как я была уверена. Я просто забыла про два старых, и самый забытый из них, 4d1f33a2, хранил основной архив: 44 МБ, 330 сессий, пять месяцев работы.

Исправление, сентябрь 2026. В апрельском тексте было 715 сессий и 48 МБ. Таблица выше в сумме даёт 710 сессий и около 49 МБ, поэтому здесь используются именно эти числа.

Официально никто не отвечал

Я насчитала как минимум десять issue на GitHub на эту тему, семь из них были активны 30 апреля. #48511, открытый 15 апреля, буквально называется «session history lost when switching accounts» — история сессий теряется при переключении аккаунтов. #26452, открытый с февраля, собрал 40 комментариев и ни одного от аккаунта, помеченного как участник, владелец или соавтор репозитория. Я проверила каждый комментарий вручную: сорок жалоб в тишину.

Обновление, сентябрь 2026. #48511 закрыли со статусом «not planned» 24 мая после периода неактивности. Люди продолжали комментировать и после закрытия, а между июнем и сентябрём в ветке появились три скрипта от сообщества для переключения аккаунтов или восстановления сессий. #26452 всё ещё открыт, теперь с 53 комментариями, и по-прежнему без единого от участника репозитория.

Четыре скрипта для поиска и восстановления сессий

Набор — четыре кроссплатформенных Python-скрипта в моём публичном репозитории claude-code-config, в папке skills/operational/desktop-sessions-discovery/:

• sessions_registry.py, главная точка входа. Он читает каждую сессию из каждого аккаунта и собирает один самодостаточный HTML-дашборд с поиском и сортировкой, затем открывает его в браузере. Каждая карточка показывает заголовок, дату, число ходов, проект, размер и выделяемый id сессии. Активный аккаунт подсвечен, а уже восстановленные сессии помечены по журналу миграций ~/.claude/desktop-migrations.jsonl, есть фильтр, чтобы их скрыть. Он читает и текущую claude-code-sessions/, и старую local-agent-mode-sessions/, переименованную в феврале 2026 года.
• sessions_inventory.py, текстовый отчёт, сгруппированный по аккаунтам, со сводкой проектов, которые встречаются больше чем в одном аккаунте.
• sessions_find.py, поиск по подстроке в заголовках и рабочих папках, с фильтрами по аккаунту и временному окну.
• sessions_restore.py, который копирует одну сессию в активный аккаунт, проверяет копию побайтово, пишет запись в журнал и никогда не удаляет оригинал. После перезапуска desktop-приложения сессия появляется в окне.

На практике я говорю Claude «покажи все сессии на этой машине для миграции», скилл подхватывает фразу, и дашборд открывается. Я прокручиваю, например, до сессии на 392 шага из заброшенного архива, копирую её id, говорю «восстанови эти три», перезапускаю приложение — и сессии на месте. На Mac есть бонус: mdfind -onlyin ~/Library/Application\ Support/Claude/ "colour checker" ищет текст внутри файлов сессий через Spotlight. У Windows аналога нет, а sessions_find.py делает то же самое, пробегая файлы примерно за полсекунды.

Обновление, сентябрь 2026. В апрельском тексте описывалась кнопка Restore на каждой карточке. Я убрала её накануне публикации, в версии 3.6.4: она лишь копировала команду в буфер обмена, выглядя так, будто делает больше. Теперь на каждой карточке есть id сессии, который нужно выделить тройным кликом и скопировать. В той же версии исправили поиск: короткий запрос вроде «26» раньше совпадал с серединой чужих id, теперь совпадает только начало id.

Чтобы установить это, я бы не стала копировать ничего вручную. Откройте Claude Code в любой папке и дайте ему репозиторий:

Take https://github.com/AnastasiyaW/claude-code-config, find the
desktop-sessions-discovery skill in skills/operational/, install it into
~/.claude/skills/, then run sessions_registry.py and show me the dashboard.

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

Чего я намеренно не делала

• Никакого массового слияния всех 710 сессий в активный аккаунт. Боковая панель с 700 записями нечитаема, особенно с примерно пятьюдесятью пустыми запланированными запусками, вроде утреннего дайджеста. Массовое копирование ещё и то, что более строгая проверка валидности как раз отклонит. Одна сессия на одну задачу работает лучше.

• Никакой автоматической миграции при запуске. Инструмент, привязанный к нынешнему формату хранения, превращается в тыкву в тот момент, когда формат меняется. Поиск и выборочное восстановление безопаснее автоматизации.

• Никаких симлинков между папками аккаунтов. Мои глобальные правила их запрещают: они ломаются при первом изменении пути, создают невидимые зависимости и через полгода порождают странные баги. Только копирование.

• Оригиналы никогда не удаляются. После восстановления исходный файл остаётся в папке своего аккаунта как резервная копия — на случай, если будущая проверка отклонит копию или восстановление придётся повторить.

У инструмента есть срок годности

Хранилище уже однажды поменяло форму: local-agent-mode-sessions/ стала claude-code-sessions/ в феврале (#29373). Второе изменение уже намечалось. В одном отчёте пользователя на macOS (#54428, 28 апреля) Claude Desktop 1.4758.0 записывал бандл виртуальной машины, ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/, с rootfs.img (10 ГБ), sessiondata.img и efivars.fd, а в том же логе видно, что сессии по-прежнему загружаются из claude-code-sessions. Дисковый образ — это не JSON. Если сессии переедут внутрь него, копирование файлов local_*.json перестанет работать.

Ещё две трещины были видны уже в апреле. Установки из Microsoft Store сломаны отдельно (#48362): внутри песочницы MSIX атомарное переименование local_<sid>.json.tmp в local_<sid>.json падает с EXDEV, потому что виртуальная файловая система видит источник и цель как разные устройства, и сессии вообще не сохраняются. А в #18645 пользователь CLI сообщил, что сессии, скопированные между машинами и работавшие на версии 2.1.5, перестали распознаваться на 2.1.9, и предположил, что теперь какая-то проверка блокирует сессии, созданные не на текущей машине. Это CLI, а не desktop-приложение, поэтому это скорее предупреждающий знак, чем доказательство. Миграция между аккаунтами на одной машине всё ещё работала.

Обновление, сентябрь 2026. Issue о MSIX закрыли со статусом «not planned» в июне. Его заголовок советует перейти на обычный установщик Win32, но комментарии от 24 апреля и 18 мая говорят, что этого пути больше нет: кнопка загрузки теперь отдаёт пакет MSIX под видом установщика Win32. #54428 тоже закрыли как «not planned» в июне. Из восьми issue, которые я цитировала в апреле, только один закрыли как выполненный: #53717, сессии, в которых пропало содержимое после автообновления на Windows. Его закрыли в августе без комментария, а через неделю пользователь попросил открыть его снова.

Почему handoff — моя настоящая стратегия

Инструмент миграции решает сегодняшнюю проблему, и я не рассчитывала, что он переживёт релиз-другой. Anthropic может переместить сессии в SQLite, зашифрованный дисковый образ или в облако; каждый раз самодельные инструменты восстановления ломаются. Поэтому долгосрочная стратегия другая: handoff после каждой важной сессии.

Память и CLAUDE.md хранят факты и правила проекта. Они не отвечают на вопрос «чем я занималась в прошлой сессии, какие гипотезы проверила, в какие тупики упёрлась». В конце каждой длинной сессии Claude записывает в проект файл .claude/handoffs/YYYY-MM-DD_HH-MM_<session-id>.md с шестью полями:

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

Один файл на сессию, никогда не перезаписывается, рядом — INDEX.md, в который только дописывают. Новая сессия читает около 1500 токенов handoff вместо 50 тысяч токенов истории и не повторяет тупиков предыдущей.

Два инструмента решают разные задачи. Восстановление залезает в чужое хранилище и зависит от него. Handoff записывает состояние в моё собственное хранилище, в тот момент, когда контекст ещё у меня в голове. Старая сессия может потеряться полностью, а новая всё равно знает цель, работу, провалы и следующий шаг. Координация, когда над одним делом работают несколько сессий одновременно, описана в посте о многих Claude в одном репозитории и в mclaude.

Структура хранения решает ещё одно. Desktop-приложение делит сессии по <accountId>/<orgId>/, поэтому handoff, записанный рядом с desktop-сессией, невидим для сессии в другом аккаунте. CLI хранит всё в ~/.claude/projects/<slug>/ независимо от аккаунта: при смене аккаунта меняется только .credentials.json. Это тихая причина, по которой моя работа постепенно переезжает в CLI.

Обновление, сентябрь 2026. Протокол handoff с апреля вырос. Теперь handoff-файлы идут в подпапку каждого проекта, .claude/handoffs/<project-slug>/, чтобы загруженный проект не вытеснял тот, к которому вы вернулись. Хук отклоняет handoff без аудита закрытия: выполнен ли запрос, что проверено, какие связанные задачи проверялись, где отслеживаются незавершённые и почему работа останавливается здесь. А новая сессия больше не открывает разговор вопросом «продолжить или начать заново»: сначала идёт текущий запрос пользователя, а релевантный handoff читается тихо. Актуальное правило — rules/session-handoff.md.

Что произошло с этими сессиями

Добавлено в сентябре 2026 года, замерено на той же машине 23 сентября.

	Апрель 2026	Сентябрь 2026
папки аккаунтов в claude-code-sessions	6	4
файлы сессий	710	522
размер	около 49 МБ	около 10 МБ
самая старая сессия в живой папке	не записано	6 июня 2026

К 6 июня всё хранилище сессий было скопировано в резервную копию восстановления на другом диске: 1003 файла, 49,9 МБ, те же шесть папок аккаунтов. Сегодня в живой папке нет ничего старше этой даты: ни одна из 522 сессий там не создана до 6 июня. Поэтому приложение не может показать ни одной сессии из апрельской таблицы. Их файлы лежат в резервной копии, а не в какой-либо папке, которую читает приложение.

Уцелело то, что жило в моих собственных папках проектов. Handoff от 12 мая в моём проекте по плиточной памяти всё ещё лежит в проекте и открывается сегодня, с целью, провалами и следующим шагом (сам проект здесь). Это аргумент этого поста, проверенный случайно. Одна честная оговорка: этот handoff никогда не коммитился, в git попал только индекс, поэтому он уцелел лишь потому, что папку скопировали. По моему же правилу он должен был лежать в git.

Источники

• #48511: история потеряна при переключении аккаунтов; закрыт как not planned в мае 2026.

• #26452: сессии пропали после выхода или перезапуска; открыт, без ответа участников репозитория по состоянию на сентябрь 2026.

• #48362: MSIX, EXDEV.

• #18645: экспорт и импорт сессий между машинами; гипотеза про 2.1.9.

• #54428: VM-бандл на macOS, 1.4758.0.

• #29373: переименование в claude-code-sessions.

• #53717: пропавшее содержимое после обновления на Windows.

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

• Документация Claude Code desktop (без путей хранения) и документация по каталогу .claude (сторона CLI описана).

• claude-sync: синхронизация CLI между машинами через R2.

• Набор инструментов: desktop-sessions-discovery. Фон про handoff: principles/18-multi-session-coordination.md и alternatives/session-handoff.md в том же репозитории.