~/.claude/projects/ на локальной файловой системе. Адаптер SessionStore позволяет зеркалировать эти стенограммы в собственный бэкенд, такой как S3, Redis или база данных, чтобы сеанс, созданный на одном хосте, можно было возобновить на другом.
Основные причины использования хранилища сеансов:
- Развертывания на нескольких хостах. Бессерверные функции, автомасштабируемые рабочие процессы и CI-раннеры не используют общую файловую систему. Общее хранилище позволяет любой реплике возобновить любой сеанс.
- Надежность. Локальные контейнеры являются временными. Хранилище, поддерживаемое S3 или базой данных, сохраняется при перезагрузках и переразвертываниях.
- Соответствие и аудит. Сохраняйте стенограммы в хранилище, которым вы уже управляете, с собственными правилами хранения, шифрованием и контролем доступа.
Интерфейс SessionStore
SessionStore — это объект с двумя обязательными методами, append и load, и тремя необязательными методами. SDK вызывает append для записи записей стенограммы во время запроса и load для их чтения при возобновлении.
SessionKey адресует одну стенограмму. projectKey — это стабильное, безопасное для файловой системы кодирование рабочей директории, sessionId — это UUID сеанса, а subpath устанавливается, когда запись принадлежит стенограмме подагента или файлу сайдкара, а не основному разговору. Рассматривайте subpath как непрозрачный суффикс ключа; он следует макету на диске, например subagents/agent-<id>. Когда subpath не определен, ключ ссылается на основную стенограмму.
Быстрый старт
SDK поставляется сInMemorySessionStore для разработки и тестирования. Пример ниже запускает запрос с подключенным хранилищем, захватывает ID сеанса из результирующего сообщения, а затем возобновляет из хранилища во втором вызове query(). Второй вызов передает тот же экземпляр хранилища плюс resume, поэтому SDK загружает стенограмму из хранилища вместо локальной файловой системы:
Напишите собственный адаптер
Реализуйтеappend и load для вашего бэкенда. Добавьте listSessions, delete и listSubkeys, если вы хотите, чтобы listSessions(), deleteSession() и возобновление подагента работали с хранилищем.
Записи, переданные в append, типизированы как SessionStoreEntry (объект { type: string; ... }). Рассматривайте их как непрозрачные значения, безопасные для JSON: сохраняйте их по порядку и возвращайте из load в том же порядке. load должен возвращать записи, которые глубоко равны тому, что было добавлено; сериализация, равная по байтам, не требуется, поэтому бэкенды, такие как Postgres jsonb, которые переупорядочивают ключи объектов, подходят.
Эталонные реализации
Репозиторий TypeScript SDK включает запускаемые эталонные адаптеры для S3, Redis и Postgres вexamples/session-stores/. Они не опубликованы в npm; скопируйте нужный файл src/ в ваш проект и установите соответствующий клиент бэкенда.
Каждый адаптер принимает предварительно настроенный экземпляр клиента, поэтому вы контролируете учетные данные, TLS, регион и пулинг. Например, с S3:
TypeScript
Проверьте ваш адаптер
Оба SDK поставляются с набором соответствия, который утверждает поведенческий контракт, который должны удовлетворятьappend, load и необязательные методы. Тесты для необязательных методов автоматически пропускаются, когда эти методы не реализованы.
В TypeScript скопируйте shared/conformance.ts из директории примеров в ваш набор тестов. В Python набор поставляется в пакете:
Python
Примечания о поведении
Архитектура двойной записи
Хранилище — это зеркало, а не замена. Подпроцесс Claude Code всегда сначала записывает на локальный диск; затем SDK пересылает каждый пакет вappend(). Если вы хотите, чтобы локальная копия была временной, укажите CLAUDE_CONFIG_DIR на временную директорию в options.env. Поскольку зеркало зависит от локальных записей, sessionStore не может быть объединен с persistSession: false; SDK выбрасывает исключение, если вы установите оба. Он также выбрасывает исключение, если объединен с enableFileCheckpointing, поскольку резервные копии истории файлов записываются непосредственно на локальный диск и не зеркалируются в хранилище.
Зеркальные записи — это лучшие усилия
Еслиappend() отклоняет, SDK повторяет попытку пакета еще два раза с коротким отступом, всего максимум три попытки. Вызов, который истекает по времени, не повторяется, поскольку исходный вызов может все еще приземлиться. Если пакет все еще не удается, ошибка регистрируется, сообщение { type: "system", subtype: "mirror_error" } выдается в итератор, пакет отбрасывается и запрос продолжается. Локальная стенограмма уже надежна на диске, поэтому сбой хранилища не прерывает агента и не теряет данные локально. Отслеживайте mirror_error, если вам нужно обнаружить потерю данных хранилища. Поскольку повторный пакет может повторно доставить записи, которые уже приземлились, дедублируйте по entry.uuid в вашей реализации append().
getSessionMessages возвращает цепь после компактирования
getSessionMessages({ sessionStore }) возвращает связанную цепь сообщений, которую агент видел бы при возобновлении. После автоматического компактирования более ранние ходы заменяются резюме, поэтому сеанс, чье хранилище содержит 503 необработанные записи, может возвращать 18 сообщений из getSessionMessages. Для полной необработанной истории, включая ходы до компактирования и записи метаданных, вызовите store.load(key) напрямую.
forkSession — это не побайтовая копия
forkSession({ sessionStore }) читает исходные записи, переписывает каждое поле sessionId и переназначает UUID сообщений, затем добавляет преобразованные записи под новым ключом. Копия на уровне адаптера или ярлык CopyObject создали бы стенограмму, которая все еще ссылается на старый ID сеанса, поэтому SDK не использует один.
Стенограммы подагентов
Стенограммы подагентов зеркалируются подsubpath: "subagents/agent-<id>". listSubagents({ sessionStore }) требует, чтобы адаптер реализовал listSubkeys; getSubagentMessages({ sessionStore }) использует его, когда доступно, но возвращается к прямому подпути, когда он не определен. Возобновление также вызывает listSubkeys для восстановления файлов подагентов; без него материализуется только основная стенограмма.
Хранение
SDK никогда не удаляет из вашего хранилища самостоятельно. Хранение — это ответственность адаптера: реализуйте TTL, политики жизненного цикла S3 или запланированную очистку в соответствии с вашими требованиями соответствия. Локальные стенограммы вCLAUDE_CONFIG_DIR очищаются независимо параметром cleanupPeriodDays.
Поддерживается на
Следующие функции SDK принимают опциюsessionStore и работают с хранилищем вместо локальной файловой системы, когда она предоставляется:
query()startup()listSessions()getSessionInfo()getSessionMessages()renameSession()tagSession()deleteSession()forkSession()listSubagents()getSubagentMessages()
Связанные ресурсы
- Работа с сеансами: Продолжение, возобновление и разветвление без пользовательского хранилища
- Размещение SDK: Шаблоны развертывания для сред с несколькими хостами
- TypeScript
Options: Полная справка по опциям examples/session-stores/: Запускаемые эталонные адаптеры S3, Redis и Postgres