Коротко · ШІ-агенти
Я змінив обліковий запис Claude і не втратив 5 ГБ історії: вона лежить на диску
Розмови в Claude Code — це файли на вашому диску, а не в обліковому записі. Типове очищення може видалити їх через 30 днів. Я подовжив цей строк до 100 років одним рядком у налаштуваннях. Після переходу зламалися входи на сайти у вбудованому браузері, опубліковані сторінки й хмарні сесії.
Мій старий обліковий запис Claude був прив’язаний до електронної адреси, яку я більше не міг для нього використовувати. Змінити адресу в обліковому записі не можна — про це прямо написано в довідці Anthropic. Тож 20 вересня я вирішив перейти на новий.
На той момент я працював із Claude Code 63 з попередніх 76 днів. Мої правила, рішення та їхні причини — усе це було в тих розмовах. Я спитав агента, чи можна взагалі перенести розмови в новий обліковий запис. У тому самому повідомленні додав вимогу:
«Переконайся, що нічого не видалиться — у жодному разі, за жодних обставин», — так я сказав своєму агенту 20 вересня.
Одне попередження: частина описаного нижче залежить від внутрішньої роботи настільного застосунку, а Anthropic її не документує. У мене це працювало на Маку у вересні та жовтні 2026 року. Після будь-якого оновлення все може зламатися.
Де Claude Code зберігає ваші розмови
На вашому комп’ютері. Кожна розмова — це файл у ~/.claude/projects/: по одній папці на кожну папку проєкту, у якій ви працювали, і по одному файлу .jsonl на кожну розмову. Коли агент запускає допоміжних агентів — субагентів (subagents), їхні транскрипти потрапляють у папку subagents усередині папки з назвою батьківської розмови. У документації Anthropic описано таку саму структуру.
Тож історія зберігається не у вашому обліковому записі. Файл правил, скіли (skills), нотатки пам’яті й налаштування теж лежать у ~/.claude. Увійдіть в інший обліковий запис на тому самому комп’ютері — і все це залишиться на місці.
4 жовтня в мене було:
- 5,0 ГБ у 29 папках проєктів, загалом 7 879 файлів.
- 18 основних розмов, 1,95 ГБ. Я тримаю небагато розмов і веду їх довго. Найбільший окремий файл займає 0,83 ГБ — це одна розмова, яка триває з 10 липня.
- 3 027 транскриптів субагентів, 2,8 ГБ. Помічники займають більше місця, ніж самі розмови.
З чого складаються мої 4,9 ГБ історії Claude Code
3 027 транскриптів субагентів — 2,8 ГБ, 18 основних розмов — 1,95 ГБ, 1 401 великий вивід інструментів — 0,15 ГБ, усе інше — 0,03 ГБ.
Перш ніж кудись копіювати цю папку, варто знати одне: це звичайний текст. У транскрипт потрапляє все, що проходить через інструмент, — вміст файлів, результати команд, усе, що ви вставляли. Якщо ви колись вставляли в чат ключ API, він там є. Те саме написано в документації Anthropic.
cleanupPeriodDays: чому розмови можуть зникнути через 30 днів
Це здивувало мене ще більше. За початковими налаштуваннями Claude Code видаляє транскрипти, яким понад 30 днів. Очищення непомітно запускається у фоновому режимі на початку сесії, а транскрипти субагентів видаляються разом із батьківською розмовою. Налаштування називається cleanupPeriodDays.
Для сесій, які почали або востаннє продовжили в настільному застосунку, діє інше правило. Як написано в документації, починаючи з версії 2.1.248 їхні транскрипти зберігаються незалежно від віку, якщо ви не встановили для них окреме обмеження — desktopSessionCleanupPeriodDays. У попередніх версіях їх видаляли через ті самі 30 днів. Я не хотів, щоб моя історія залежала від цього винятку: усе, що почалося поза настільним застосунком, досі підпадає під правило 30 днів. Тому 20 вересня я додав один рядок до ~/.claude/settings.json:
{
"cleanupPeriodDays": 36500
}
36 500 днів — це близько 100 років. У документації вказано мінімум 1, а максимум не згадано.
Я не можу сказати, чи щось видалилося до того дня. Моя найстаріша розмова, з першого дня роботи 7 липня, досі на місці.
Збереження всього має свою ціну — місце на диску. У вересні моя історія виросла на 2,5 ГБ. Близько 0,4 ГБ із них припало на одну довгу розмову, скопійовану в новий файл; решта, 2,1 ГБ, — нові дані. У три дні з найбільшим приростом 83–91% нових даних створили субагенти.
Моя історія Claude Code на диску, ГБ
Від майже нуля 7 липня до 4,8 ГБ 3 жовтня: 0,15 ГБ наприкінці липня, 1,6 ГБ наприкінці серпня, 2,7 ГБ 20 вересня, 4,1 ГБ наприкінці вересня.
Чому після зміни облікового запису бічна панель порожня
30 вересня я ввійшов у настільний застосунок під новим обліковим записом і відкрив вкладку Code. Бічна панель була порожня. Нічого не видалилося — на диску досі лежало понад 4 ГБ історії, — але застосунок більше її не показував.
Причина в тому, що бічна панель будується не з транскриптів. Вона використовує маленькі файли-вказівники, по одному на кожну сесію, і вони лежать у папці, яка належить одному обліковому запису. На Маку вона тут:
~/Library/Application Support/Claude/claude-code-sessions/<account>/<organization>/
Вказівник містить назву сесії, папку проєкту та ідентифікатор транскрипту, який він відкриває. Новий обліковий запис отримує нову порожню папку. Тому панель і порожня.
На диску · спільне
Усі розмови й транскрипти субагентів, а також правила, скіли, пам’ять і налаштування в ~/.claude. Усі облікові записи на цьому комп’ютері бачать ті самі файли.
Для кожного облікового запису
Один маленький файл-вказівник на кожну сесію у власній папці настільного застосунку для цього облікового запису. Бічна панель читає лише папку облікового запису, у який ви ввійшли.
У хмарі
Опубліковані сторінки, конектори, хмарні сесії. Вони залишаються в обліковому записі, який їх створив.
Мій агент знайшов розв’язання в дописах спільноти. На GitHub у відкритому запиті на нову можливість ще з липня просять Anthropic додати саме це. Рішення просте: повністю закрити застосунок, скопіювати файли-вказівники до папки нового облікового запису, не перейменовуючи їх, і знову відкрити застосунок. Я зробив це 30 вересня. Усі 16 сесій повернулися — уже в новому обліковому записі, а закріплені й архівовані залишилися на своїх місцях.
Якщо не хочете чіпати файли застосунку, є задокументований спосіб повернутися до будь-якої розмови: термінальна версія Claude Code відкриває її командою claude --resume <session-id> із будь-якої папки. Ви втрачаєте бічну панель, а не історію.
Що зламалося після зміни облікового запису
- Входи на сайти у вбудованому браузері застосунку. Вони зникли відразу після зміни облікового запису. На кожному сайті, де я був авторизований, довелося ввійти знову. Список дозволених сайтів і довірених папок залишився.
- Опубліковані сторінки. Сторінки, які я публікував як артефакти зі старого облікового запису, не відкриваються з нового. Повторна публікація створює нове посилання.
- Усе в хмарі. Хмарні сесії та конектори належать обліковому запису, який їх створив. Вони не переносяться.
Усе на диску залишилося без змін: розмови, пам’ять, правила, скіли, налаштування. Так само й усе поза Claude — git, мій менеджер паролів, Cloudflare та інші сервіси, з якими працює агент.
Два скрипти: резервна копія та синхронізація бічної панелі
Резервна копія
Перш ніж чіпати файли застосунку, агент написав скрипт резервного копіювання. Він пакує кожну папку проєкту в окремий архів, додає папку налаштувань без транскриптів і файла з даними входу, а також папки бічної панелі настільного застосунку. Потім порівнює кількість файлів у кожному архіві проєкту з джерелом. Якщо числа не збігаються, це помилка, а не попередження.
Резервна копія навмисно лежить поза ~/.claude/projects. Коли ви продовжуєте розмову за її ідентифікатором з іншої папки, Claude Code шукає в усіх проєктах. Якщо знаходить дві копії, відповідає «не знайдено» — це описано в документації. Папку з резервною копією можу читати лише я, і вона ніколи не потрапляє ні до хмарного сховища, ні до git.
30 вересня повна резервна копія складалася з 29 архівів: 4,2 ГБ файлів стиснулося до 2,2 ГБ, і кількість файлів збіглася в кожному. Мінімальну версію можна запустити самостійно з Термінала, коли жодна сесія не працює:
mkdir -p ~/Backups/claude-history
tar -czf ~/Backups/claude-history/projects-$(date +%F).tar.gz -C ~/.claude ./projects
tar -tzf ~/Backups/claude-history/projects-$(date +%F).tar.gz | grep -c '\.jsonl$'
find ~/.claude/projects -name '*.jsonl' | wc -l
Останні два числа мають збігатися.
Синхронізація бічної панелі
Перша версія копіювала вказівники лише в один бік. Того самого дня вона стала двосторонньою, бо я досі час від часу перемикаюся між двома обліковими записами, а кожне перемикання приховує те, що я робив в іншому. Її правила:
| Ситуація | Що робить скрипт |
|---|---|
| Сесія є лише в одній папці | Копіює її до іншої. |
| Після останньої синхронізації вона змінилася в одній папці | Переносить цю версію до іншої папки. |
| Вона змінилася в обох папках | Бере версію з пізнішою активністю та перелічує поля, які відрізнялися. |
| Вона змінилася в обох папках, але час останньої активності однаковий | Нічого не змінює й повідомляє про це. Надішліть будь-яке повідомлення в потрібній версії, знову запустіть синхронізацію — і ця версія переможе. |
| Дві версії відкривають різні транскрипти | Нічого не змінює й повідомляє про це. |
| Її видалили з однієї папки | Не повертає її та не видаляє з іншої папки. |
Правила безпеки важливіші за логіку. Скрипт ніколи не видаляє файли. Перед будь-якою зміною він робить знімок усієї папки бічної панелі. Він відмовляється щось змінювати, поки застосунок відкритий, бо той перезапише папку даними з пам’яті. І він порівнює вміст вказівників, а не час зміни файлів, ігноруючи поле «востаннє відкрито», яке змінюється, щойно ви натискаєте на сесію.
Без прапорців він лише показує план. 4 жовтня він вивів це (перекладено англійською, скорочено, ідентифікатори приховано):
Account/organization folders: 3
xxxxxxxx…/xxxxxxxx… pointers: 0 (empty, not included)
xxxxxxxx…/xxxxxxxx… pointers: 17 ← active account synced 03.10 15:13
xxxxxxxx…/xxxxxxxx… pointers: 17 synced 03.10 15:13
To copy: 0; to update: 7; conflicts: 1; unreadable: 0; deleted, not restored: 0
This was a preview. To run it: restore-desktop-sessions --apply (the app must be closed)
Після останньої синхронізації сім сесій змінилися в одному з облікових записів. Одна змінилася в обох, і скрипт не вгадуватиме, яка версія правильна. В обох папках лежать ті самі 17 сесій, і кожен вказівник відкриває транскрипт, який є на диску.
Перед першим справжнім запуском синхронізація пройшла 44 перевірки у 14 сценаріях — перемикання туди й назад, конфлікти, видалення, пошкоджений файл, третій обліковий запис — на копії моєї справжньої бічної панелі. А під час окремого рецензування її намагалися зламати. Ця копія водночас і слабке місце: перевірки залежать від поточного стану. 4 жовтня, коли в ній був один невирішений конфлікт, пройшли 36 із 44 перевірок. Тест вибрав конфліктну сесію для «видалення», і вона повернулася замість того, щоб залишитися видаленою. Помилка в безпечний бік — нічого не втрачено, — але перевіркам потрібна власна фіксована вибірка.
Я поки не публікую скрипти: вони написані під мої папки, а тести містять справжні ідентифікатори облікових записів. Таблиці достатньо, щоб відтворити їх або попросити про це власного агента.
Як експортувати окрему розмову
Усередині сесії введіть /export. Команда копіює розмову до буфера обміну або зберігає її як текстовий файл, перетворюючи результати інструментів на читабельний текст (документація). Це найчистіший спосіб передати комусь одну розмову. Тільки спершу перевірте, чи немає в ній ключів.
Файли .jsonl також можна читати власними скриптами, але формат внутрішній і змінюється між версіями — про це попереджає документація. Моя резервна копія просто копіює файли як є й не розбирає їх, тому зміна формату її не зламає.
Експорт даних на claude.ai — це інше. Він призначений для чатів у вкладці Chat, а посилання на завантаження надсилають на електронну адресу облікового запису. Ваші розмови Claude Code уже лежать на диску.
Якщо змінюєте обліковий запис: порядок, який спрацював у мене
- Зробіть резервну копію та перевірте кількість файлів.
- Увійдіть у новий обліковий запис і один раз відкрийте вкладку Code, щоб з’явилася його папка.
- Повністю закрийте застосунок клавішами ⌘Q. Просто закрити вікно недостатньо.
- Скопіюйте вказівники або запустіть синхронізацію з Термінала, а не з термінала всередині застосунку.
- Відкрийте застосунок і перевірте бічну панель.
- Знову ввійдіть на сайти, якими користувалися у вбудованому браузері.
І хоч би що ще ви пропустили, встановіть cleanupPeriodDays сьогодні. Для цього потрібен один рядок, і це єдиний крок, який працює ще до того, як ви зрозумієте, що він вам потрібен.