Claude Desktop и Claude Code в Windows хранят на диске долгоживущие идентификаторы, которые живут отдельно от аккаунта. Основная точка входа — файл %USERPROFILE%\.claude.json: внутри лежат machineID и userID, по 32 случайных байта в hex, то есть строки длиной 64 символа. К логину они не привязаны: под какой учёткой вы ни зашли на этой машине, пара значений остаётся прежней.
Метки распределены по трём слоям, и слои независимы друг от друга. CLI-слой — ~/.claude.json с machineID и userID. Десктопный слой — ant-did, файл ant-device-registry.json и соли телеметрии. Браузерный слой — Chromium-профиль внутри Electron с cookies claude.ai, Local Storage и analytics-идентификаторами. Сброс одного слоя не задевает два других, поэтому чистить приходится все три.
И главное сразу: локальный сброс возможен, но он не делает вас полностью «новым» для сервера. Локаль ОС, часовой пояс, IP, TLS-отпечаток и серверная связка аккаунтов остаются вне досягаемости любого клинера. Ниже — что именно клиент пишет на диск и как этим управлять.
Дисклеймер из самого исследования: это разбор того, что клиент пишет на ваш собственный компьютер, и утилита для управления своими локальными данными. Вмешательства в чужие системы или серверную часть здесь нет.
Что Claude пишет на диск: карта локальных идентификаторов
Локальный след состоит из нескольких файлов, разбросанных по разным подсистемам. Прежде чем что-то сбрасывать, полезно понять, что искать нужно в трёх местах, а не в одном: JSON-конфиг CLI, каталог данных десктопного приложения и профиль Chromium внутри него.
| Слой | Что хранит | Где искать на Windows |
|---|---|---|
| CLI (Claude Code) | machineID, userID, firstStartTime, oauthAccount | %USERPROFILE%\.claude.json |
| Десктоп (Claude Desktop) | ant-did, реестр устройств, соли телеметрии | ant-device-registry.json в каталоге данных приложения |
| Chromium-профиль Electron | cookies claude.ai, Local Storage, analytics-идентификаторы | профиль Chromium внутри каталога данных приложения |
Три слоя идентификаторов: CLI, десктоп, Chromium-профиль
CLI-слой отвечает за machineID и userID в ~/.claude.json. Это статические строки, которые клиент читает при старте и записывает обратно только при генерации новых значений.
Десктопный слой добавляет ant-did, ant-device-registry.json и соли телеметрии. Эти метки относятся к самому приложению Claude Desktop, а не к CLI, и живут в его каталоге данных.
Браузерный слой — Chromium внутри Electron. Cookies claude.ai, данные Local Storage и analytics-идентификаторы лежат в профиле браузерного движка. Формально это часть десктопного приложения, но хранилище у него своё, и почистить его отдельно от JSON-конфигов можно только понимая, что оно существует.
Пути на Windows: где искать файлы
Подтверждённый путь один: %USERPROFILE%\.claude.json. В Unix-нотации это ~/.claude.json, о котором пишет автор разбора на Habr. Откройте файл в любом текстовом редакторе — это обычный JSON.
Для десктопной части точные каталоги зависят от сборки приложения, и публичный разбор их не приводит. Практичный подход: искать файл по имени ant-device-registry.json в каталоге данных приложения. Приложения на Electron в Windows обычно держат пользовательские данные в каталоге вида %APPDATA%\<Имя приложения>, но это общая конвенция платформы, а не гарантия. Проверяйте по факту на своей машине, а не по чужому скриншоту.
Профиль Chromium лежит внутри того же каталога данных. Опознаётся по характерному набору файлов браузерного профиля: хранилище Local Storage, база cookies, кэш. Точные имена файлов зависят от версии Chromium, встроенного в сборку, поэтому надёжнее искать по структуре каталога.
machineID и userID в ~/.claude.json: что это и почему они не привязаны к аккаунту
%USERPROFILE%\.claude.json хранит не только кэши фич и список проектов. Внутри лежат два долгоживущих идентификатора, и выглядят они так:
{
"userID": "29751f55233dc772e0f88584ffbd5317d59c84d782caf321b2ad408cc237bfb1",
"machineID": "c6604aae3f882f340123383c64ddf99644b7d2f060177351910f4de23ecedddb",
...
}Значения выглядят случайными, и они действительно случайны: machineID и userID — это 32 случайных байта в hex, отсюда и длина 64 символа у каждого.
Ключевой момент для приватности: к аккаунту они не привязаны. Под какой учёткой вы ни зашли на этой машине, пара ID остаётся прежней. Именно это позволяет связать разные аккаунты, которые работали на одном ПК: серверная сторона может сшить их через общий локальный идентификатор, даже если вы выходили из одного аккаунта и заходили в другой.
Как CLI генерирует ID: логика из claude.exe
Автор разбора вытащил логику генерации прямо из бинаря CLI claude.exe, который представляет собой упакованный Bun-проект. Это снимает вопрос «а может, это просто кэш»: значения именно генерируются и сохраняются в конфиг.
Алгоритм getUserID и getMachineID одинаковый. Если в конфиге есть валидное значение, используется оно. Если значения нет или оно не проходит проверку, клиент генерирует 32 случайных байта в hex и записывает результат в конфиг:
if (typeof r.userID === "string" && qc.test(r.userID)) return r.userID;
...
let s = Dc(32).toString("hex");
return n.setGeneratedUserID(s), Ce((g) => ({ ...g, userID: s }), e), s;Словесное описание логики в публикации обрывается на середине фразы, но приведённый фрагмент кода показывает схему целиком: проверка формата, ветка с существующим значением, ветка с генерацией и записью.
На практике это значит ровно две вещи. Удалите поле из конфига, и при следующем запуске CLI создаст новое значение и сохранит его в тот же файл. Подставьте прежнюю строку вручную, и клиент примет её как свою, потому что проверяет формат, а не происхождение.
firstStartTime и oauthAccount: что рядом с ID
В том же файле лежат поля, которые напрямую с аккаунтом связаны:
"firstStartTime": "2026-06-10T21:27:47.643Z",
"oauthAccount": {
"accountUuid": "…",
"emailAddress": "…",
"organizationUuid": "…"
}firstStartTime фиксирует момент первого запуска на этой машине, а не дату публикации материала, из которого взят пример. Блок oauthAccount с accountUuid, emailAddress и organizationUuid — это уже привязка к аккаунту: она меняется при смене учётки.
Разделение важное. Аккаунтные поля уходят вместе с выходом из аккаунта, а machineID и userID остаются на диске и переживают эту операцию. Один и тот же компьютер под разными аккаунтами несёт одну и ту же пару локальных ID.
Десктопный слой: ant-did, ant-device-registry.json и соли телеметрии
Claude Desktop формирует собственную метрику устройства. В разборе упоминаются ant-did, файл ant-device-registry.json и соли телеметрии. ant-did работает как идентификатор устройства на стороне десктопа, ant-device-registry.json хранит реестр устройств, соли телеметрии используются как дополнительные параметры для аналитики.
Точные форматы полей и внутреннюю структуру этих файлов публичный разбор не раскрывает: они упомянуты как часть карты локального следа, без разобранных примеров. Поэтому здесь честнее говорить о назначении и расположении, чем выдумывать схему, которой в источнике нет.
Важнее другое: это отдельный слой, никак не связанный с ~/.claude.json. Сброс CLI-меток не затронет ant-did и реестр устройств, потому что они лежат в другом каталоге и обслуживаются другим кодом.
Чем десктопный слой отличается от CLI
CLI хранит machineID и userID в одном JSON-файле и не создаёт реестра устройств. Десктоп добавляет ant-did и ant-device-registry.json, то есть ведёт собственный учёт устройств.
Если вы работаете и в Claude Code, и в Claude Desktop на одной машине, чистить нужно оба слоя. Сброс только CLI оставит связку через десктопную метку, и наоборот. Это не теория заговора, а обычное следствие того, что два клиента пишут два независимых набора данных.
Chromium-профиль Electron: cookies claude.ai, Local Storage и analytics-идентификаторы
Claude Desktop собран на Electron, а значит внутри у него полноценный Chromium со своим профилем. В этом профиле хранятся cookies claude.ai, данные Local Storage и analytics-идентификаторы. JSON-конфиги и браузерное хранилище — разные вещи, и второе переживает большинство правок первого.
Что именно лежит в профиле и почему это важно
Cookies claude.ai отвечают за сессию и привязку к аккаунту. Local Storage хранит клиентские данные, включая analytics-идентификаторы. Сами analytics-идентификаторы — это метки для телеметрии, которые живут отдельно от пользовательских настроек.
Даже если вы сбросите ~/.claude.json и ant-did, cookies и Local Storage могут сохранить связку с аккаунтом. Полная очистка профиля — самый радикальный шаг из всех описанных, и он разлогинит вас в приложении: придётся входить заново. Это ожидаемый побочный эффект, а не баг, и решение о нём стоит принимать осознанно, а не «заодно».
Сброс через PowerShell: скрипт и что он делает
В разборе показан PowerShell-скрипт, который приводит локальный слой в состояние первого запуска. Чаты при этом остаются на месте. Код открыт на github.com/Soulringen/aegis-claude.
Логика работы укладывается в три шага: обнуление или перегенерация machineID и userID в ~/.claude.json, сброс ant-did и ant-device-registry.json, очистка analytics-идентификаторов в Chromium-профиле. Точных команд в публичном описании нет, поэтому перед запуском сверьтесь с содержимым репозитория: состав полей меняется от версии к версии клиента, и скрипт должен соответствовать вашей сборке.
Пошаговый порядок действий
- Закрыть Claude Desktop и Claude Code. Пока приложение работает, оно держит конфиг и может перезаписать файл после правки.
- Сделать бэкап
~/.claude.jsonи каталога данных десктопного приложения. Это дешёвая страховка на случай, если скрипт отработает не так, как ожидалось. - Запустить скрипт из репозитория под своей учётной записью Windows.
- Проверить, что чаты, настройки и список проектов на месте.
- Перезапустить приложение и убедиться, что новые значения ID записались в конфиг.
Что скрипт не трогает
Скрипт работает только с идентификаторами. Чаты, настройки, список проектов и кэши фич остаются на диске. Полная очистка с удалением истории — другой сценарий, и обсуждать его нужно отдельно, с отдельными предупреждениями о потере данных.
Почему метки возвращаются: резервные копии и откатные бэкапы
Резервные копии конфигов и откатные бэкапы могут восстановить метки: файл вернётся из копии, и клиент снова прочитает старый machineID. Снапшоты системы и откат состояния работают так же. После сброса стоит проверить, не восстанавливается ли ~/.claude.json из какого-нибудь бэкапа.
Где искать бэкапы
Смотрите в трёх направлениях. Первое — собственные папки бэкапов приложений и ручные копии, которые вы делали сами. Второе — точки восстановления Windows и снапшоты файловой системы. Третье — облачные синхронизации: OneDrive, Dropbox, Google Drive и подобные сервисы, если домашний каталог или каталог данных приложения попадает в синхронизируемую папку.
Конкретные пути зависят от вашей конфигурации, поэтому принцип важнее списка: ищите любые копии %USERPROFILE%\.claude.json и каталога данных приложения. На время сброса синхронизацию стоит отключить, иначе файл вернётся с сервера быстрее, чем вы закроете терминал. Честная оговорка: сброс — локальная мера, и никакой гарантии, что метка не вернётся из копии, никто дать не может.
Границы локального сброса: что остаётся вне досягаемости
Локальный сброс не делает вас полностью «новым» для сервера. Вне досягаемости клинера остаются локаль ОС, часовой пояс, IP, TLS-отпечаток и серверная связка аккаунтов. Это не детали реализации, а сигналы, которые формируются за пределами файлов, которые правит скрипт.
Что видит сервер помимо локальных ID
Локаль операционной системы и часовой пояс приходят с каждым запросом и описывают вашу среду. IP-адрес — сетевой идентификатор, который не относится к клиентским файлам вообще. TLS-отпечаток складывается из параметров рукопожатия и характеристик клиента, а не из полей JSON. Серверная связка аккаунтов живёт на стороне сервиса: если два аккаунта уже были связаны в его данных, правки на диске этого не отменяют.
Добавьте к этому accountUuid, emailAddress и organizationUuid из oauthAccount: пока вы залогинены, привязка к аккаунту активна и лежит в том же файле, который трогает скрипт.
Практический вывод: для чего тогда сброс
Сброс полезен для управления своими локальными данными: он приводит клиент к состоянию первого запуска на вашей машине, помогает при тестировании и даёт понять, что именно приложение пишет на диск. Это инструмент прозрачности и контроля, а не способ обойти серверные ограничения. Если задача формулируется как «стать для сервиса другим человеком», локальные правки её не решают, и обещать обратное было бы нечестно.
Дисклеймер и этическая рамка
Автор исследования формулирует рамку прямо: это изучение того, что клиент пишет на диск пользователя, и утилита для управления своими локальными данными. Вмешательства в чужие системы или серверную часть в этой работе нет.
Практический порядок действий для тех, кто хочет разобраться на своей машине: откройте %USERPROFILE%\.claude.json и посмотрите, какие поля там лежат; сделайте бэкап перед любыми правками; проверьте, не синхронизируется ли каталог с облаком; сверьте скрипт с текущей версией клиента и только потом запускайте. И держите в голове, что цифровой след на стороне сервера этим не стирается.
Источники
- Как Claude запоминает ваш компьютер: разбираем локальные идентификаторы и сбрасываем их скриптом — разбор на Habr, из которого взяты данные о
~/.claude.json,machineID,userID,firstStartTime,oauthAccount, десктопном слое и PowerShell-скрипте. - github.com/Soulringen/aegis-claude — открытый репозиторий со скриптом для сброса идентификаторов Claude Code.