Claude Desktop Conversations

Overview

Claude Desktop shows the claude.ai web interface inside Electron, so conversations are cached the way a browser would cache them. Two independent local sources hold message content:

1. The IndexedDB conversation store, a LevelDB database whose values are serialized with the V8 structured-clone format.
2. The Chromium HTTP cache, which keeps cached chat_conversations API responses as compressed JSON.

A third source, Cowork agent transcripts, is covered in Cowork Sessions.

Conversation history is authoritative on the server. These local stores are caches, so they hold a window of recent or recently opened conversations, not the account history. On the one reference host studied, the IndexedDB store held 16 conversations and the HTTP cache held roughly 200 cached conversation responses. Treat those numbers as an illustration, not an expectation.

IndexedDB Conversation Store

File Locations

Whether a given host uses the legacy path, the bucket path, or both depends on the app version. Whether the two represent a migration or coexistence is not established, so check for both. Resolve a bucket directory to its origin through the QuotaManager database rather than by guessing.

Copy the whole LevelDB directory (.ldb, .log, MANIFEST-*, CURRENT) before parsing. If the app is running the directory holds a LOCK file; work from a copy.

Format

IndexedDB on Chromium is stored in LevelDB. Keys carry prefixes that encode the database, object store, and index IDs. Values are wrapped: a V8 serialization header (0xFF version byte), a Blink envelope, and optionally Snappy compression or a pointer to an external blob. Blob files are located by number under the .blob directory in <db_id>/<hex byte>/<hex number> form. LevelDB SSTable blocks are Snappy-compressed.

Databases

Only claude-conversation-store carries message content. The others are useful to inventory (names and record counts) but were not found to hold conversation text.

meta Store

One record per conversation.

All of these are Unix milliseconds. A record with tombstone set marks a conversation the user deleted. The metadata that survives can still show that the conversation existed and when it was last opened.

trees Store

One record per cached conversation tree.

Each message carries:

Content blocks are text, thinking, tool_use (id, tool name, input), and tool_result (matching tool_use_id, error flag, text). Thinking blocks mean the assistant's reasoning text can be present locally.

parent_message_uuid forms a tree. When a user edits a prompt or regenerates a response, the older branch remains under a sibling. Reconstruct the conversation by walking from the selected option, and consider unselected siblings as evidence of prompts the user abandoned.

HTTP Cache

File Locations

Format

The cache is a Chromium Simple Cache: one file per entry, named with a 16-hex-digit hash and a _0 suffix (sparse _s files hold range data and are not useful here). Each entry file starts with a magic number, followed by the key and the response stream, with the pickled response metadata (status, headers, request and response times) near the end. The key looks like 1/0/_dk_<site> <site> <url>. Bodies are compressed according to Content-Encoding; the cached claude.ai conversation responses are usually zstd, and brotli and gzip also occur.

What the Cache Holds

The parseable prize is the conversation API response:

https://claude.ai/api/organizations/<org>/chat_conversations/<uuid>?...

Its JSON body yields the same message fields as the IndexedDB tree, with the request and response times from the cache entry as timestamps. Other cached claude.ai endpoints are worth indexing even when the body is not parsed, because the URL, status, size, and time show what the user did:

By default a collector should restrict body parsing to claude.ai, a.claude.ai, api.anthropic.com and *.claudeusercontent.com hosts, since the cache also holds unrelated third-party content.

Deduplication and Provenance

The same message commonly appears in both stores. macfor merges them per message and records provenance:

• source is indexeddb or http_cache for the primary record.
• also_seen_in lists the other sources that held the same message.
• content_differs flags a message whose text is not identical across sources.

A difference between sources is worth examining: it can indicate an edit, a regeneration, or a cache that was captured at a different moment.

Recovered Values

LevelDB does not overwrite in place. A changed or deleted key leaves the old value in an earlier SSTable or in the write-ahead .log until compaction removes it. Reading every sequence number rather than only live entries can therefore surface:

• Earlier versions of a conversation tree (superseded values)
• Trees for conversations that were deleted (deleted values)

macfor flags these records recovered: true. In a report, state clearly that a value is recovered and not live, and that its timestamps describe the stored content, not when it was removed. How long old values persist depends on compaction, so absence of recovered values proves nothing.

Messages whose body lives in an external blob that cannot be found are emitted with blob_missing: true.

Timestamps

-- Chromium microseconds since 1601 to a readable UTC time
SELECT datetime(:chromium_us / 1000000 - 11644473600, 'unixepoch');

Investigation Notes

• Establish the account. accountUuid and orgUuid tie records to an account. The same UUIDs appear in the local-agent-mode-sessions/ path and in config.json.
• Cached is not complete. hasOlder and messageCount against the number of cached messages show how much of a conversation is missing locally.
• Attachments. files[] names uploaded files and their sizes. The file content may be recoverable from the cache /files/ responses or from a Cowork uploads/ folder.
• Deletion. A tombstone and deletedAt show a deliberate delete. Look in recovered values for the content.
• Redaction. Conversation text is user content. macfor's skip_content option collects structure, counts and tool names without message text.

What macfor Collects

The ai.claudedesktop plugin emits claude_conversation, claude_message, claude_conversation_event, claude_idb_inventory, and claude_api_cache_entry records. IndexedDB, blob, cache, and QuotaManager files are copied byte-for-byte as original evidence.

{
  "type": "claude_message",
  "source": "indexeddb",
  "recovered": false,
  "conversation_uuid": "00000000-0000-4000-8000-000000000001",
  "product": "hub",
  "message_uuid": "00000000-0000-4000-8000-0000000000a2",
  "sender": "assistant",
  "created_at": "2026-08-02T10:15:03Z",
  "stop_reason": "end_turn",
  "text": "Example response text",
  "tool_names": [],
  "also_seen_in": ["http_cache"],
  "schema_version": "2.2"
}

All values above are illustrative.

References

• Chromium IndexedDB source
• Chromium Simple Cache
• ccl_chromium_reader
• Related: Chrome Local Storage, State and Storage