В репозиторії Claude Code на GitHub за останні кілька місяців з’явилася низка відкритих тікетів, у яких користувачі повідомляють про раптове зникнення транскриптів розмов. Схоже, проблема полягає в опції конфігурації cleanupPeriodDays. За замовчуванням вона встановлена на 30 днів і запускається щоразу під час старту Claude Code, безповоротно видаляючи всі файли .jsonl, які вважає «застарілими», пише The Register.
Читайте также: Італія профінансує українську кібербезпеку на 1 млн євро в рамках «Талліннського механізму»
В Anthropic натякнули, що провина лежить на самих користувачах, які не заглядають у документацію. У компанії заявили, що 30-денна політика очищення даних діяла з моменту запуску Claude як захід безпеки, і про це чітко написано в інструкції.
«Безстрокове зберігання текстових транскриптів кодинг-сесій на диску створює реальні ризики для безпеки та конфіденційності, оскільки вони можуть містити вихідний код, облікові дані та іншу чутливу інформацію», — йдеться в заяві компанії. «30 днів за замовчуванням — це баланс між можливістю відновити нещодавню роботу та прагненням не тримати ці дані на диску довше, ніж потрібно. Це рішення було частиною архітектури Claude Code з моменту запуску саме як захід безпеки».
Це не було б такою великою проблемою, якби Claude Code спромігся попередити необізнаних користувачів про те, що історія їхніх 30-денних розмов із ботом буде стерта під час наступного запуску програми, або хоча б повідомив про існування такого налаштування. Проте користувачі стверджують, що цього немає.
«Очищення працює „з коробки“ — без жодних попереджень під час інсталяції чи діалогових вікон при першому запуску», — написав у своєму першому дописі користувач GitHub під ніком FTSBrand (згодом цей тред став головною гілкою обговорення проблеми). «Користувачі, які вважають історію своїх розмов надійним джерелом робочих знань, просто тихо помиляються щодо моделі збереження даних».
Інший користувач у власній гілці обговорення повідомляє, що код і git-історія проєкту після очищення залишилися на місці, «але весь ланцюжок міркувань — обговорення архітектури, контекст відлагодження, аналітика — зник».
«Для дослідницької роботи саме цей контекст і є головним результатом», — зазначив користувач GitHub під ніком joekhochstetter.
Читайте также: Надихнуло старе залізо: айтівець вирішив влаштувати ШІ-челендж і за вихідні створив суперлегкий редактор коду
Схоже, ця функція очищення взагалі не передбачає можливості відновлення: тут немає ні тимчасового видалення в «кошик», ні пільгового періоду, ні опції відкату. Ба більше, судячи зі скарг користувачів, програма навіть не веде лог видалених файлів, тож люди взагалі позбавлені можливості перевірити, що саме зникло після чергового чищення.
Аналіз першопричин, проведений користувачем GitHub під ніком ojura, свідчить про те, що видалення прив’язане до mtime (часу зміни) файлу транскрипту, а не до фактичної мітки його останньої активності.
«Оскільки mtimes можна змінити ззовні, будь-що, що його зачіпає, повністю змінює результат: відновлення з бекапу, клієнт синхронізації або скрипт, який встановлює mtimes на справжню (стару) дату останньої сесії. Це змушує поточну сесію виглядати застарілою, і під час наступної перевірки вона просто тихцем видаляється», — пояснює ojura.
Єдине рішення, яке пропонують у треді, — переконатися, що транскрипти Claude Code копіюються, при цьому користувачі радять кілька різних варіантів такого обхідного шляху (воркаунду). Проте деяких розробників це не влаштовує — вони вимагають виправлення самого багу.
«Резервне копіювання — це хороша гігієна, але воно не замінює інформування на рівні продукту про деструктивне очищення даних», — пише користувач GitHub caioribeiroclw-pixel.
Читайте также: Дослідження: компанії, які найбільше витрачають на ШІ, наймають людей швидше — зокрема й джунів