Self-Hosted Claude Code Transcript Storage

Why self-hosted Claude Code transcript storage is a real question

Run Claude Code from a terminal and the transcript goes wherever the tool that launched the session decided to put it. For a side project, nobody cares. For a team shipping regulated software, that transcript is a record of every file the agent read and every command it ran, and "wherever the tool decided" is not an answer a security review will accept.

This setup flips the default. Instead of a session living in somebody else's cloud, or scattered across a laptop's local disk, it lands in a database your team operates, under your retention rules, searchable the way any other operational record is searchable.

DataShield Commander is built around exactly that default. Sessions and transcripts write to a PostgreSQL database on the server that runs Commander, whether that server is your own cloud, your own data center, or a dedicated single-tenant server DataShield operates for you. Not Anthropic's servers. Not a personal Claude web account. Not DataShield's own systems. The only network call that leaves the building is the API call to the model itself, the same call any Claude Code install makes to do its job.

What Commander actually keeps from a session

Every logged Claude Code session is indexed, searchable and archivable, and it is linked deterministically to its transcript file rather than guessed at from a filename. A session row carries its persona, the prompt count, the transcript size, and timestamps, alongside the actual conversation.

That is not a summary written after the fact. It is the session itself: the boot prompt a persona launched with, the turns that followed, and anything the agent produced along the way, screenshots and generated artifacts included, captured into a provenance registry rather than left loose in a directory somewhere. Model, effort level and the account that ran the session sit in the breadcrumb too, so nobody has to reconstruct whose API key was active from memory.

That setup is only useful if the record is actually complete enough to answer a real question later: which persona ran this, what did it read, what did it call, and when. Commander's session row is built to answer exactly that, not a curated version of it.

That completeness is also what makes the record boring in the best way. A boring, complete transcript beats an exciting, curated one every time someone actually needs the truth instead of a summary.

Search: finding one session in a thousand

A transcript archive nobody can search is a compliance liability with extra steps. Commander indexes the logged transcript so it can be searched from the top bar, and the transcript-search capability governs the endpoint that serves it (GET /api/claude-sessions/:sid/prompts), so it is a gated feature rather than an afterthought bolted onto the session list.

That matters for the ordinary case as much as the audit case. An engineer trying to remember which session fixed a flaky migration six weeks ago should not have to grep a folder of raw JSON files by hand. A security reviewer trying to answer "did any agent read this file" needs the same search, aimed at a different question. It earns its name only if the storage part comes with a way back in, and search is that way back in.

How retention works for this kind of storage

Transcripts do not sit in one undifferentiated pile forever. Commander runs a hot-to-cold roll on a configurable cadence (archive_sweep_interval_ms), moving idle sessions from an active state into an archived one after a configurable idle window (session_archive_park_idle_minutes). Archived sessions still exist, still search, and can be reopened, they are simply out of the way of the active session list.

A session can also be trashed rather than archived, and a trashed transcript is not kept indefinitely. claude_trash_retention_days sets how long a trashed transcript survives before a scheduled purge sweep (trash_sweep_interval_ms) removes it for good. That is a setting you control, not a fixed policy DataShield decided for you, which is the entire point of running this on your own PostgreSQL instead of a vendor's multi-tenant store: your retention window is your own compliance program's answer, not ours.

That is also the practical answer to a data-retention question a policy team will eventually ask. Not "does the vendor retain this forever," but "what did we configure, and can we prove it." A retention window you set and can point to in a config file is a very different conversation than a vendor's undocumented default.

Erasure, and what it does not solve

Erasure needs an honest caveat, so here it is, in the spirit of GDPR's Article 17 right to erasure, which expects a controller to know exactly where a subject's data lives before it can honor a deletion request. Purging a trashed transcript past its retention window is a straightforward delete against your own database, the same mechanism as any other row in any other application you run. It is not the crypto-shred pattern DataShield Auth uses to erase tokenized PII, where destroying a per-subject key makes every token for that subject unrecoverable while the audit chain itself stays intact.

That distinction matters if a session transcript captured PHI or another regulated field directly, rather than a token standing in for it. The practical fix is upstream of storage, not downstream of it: tokenize identifiers before an agent's context ever includes them, using DataShield Ontology, so what lands in a transcript is a token, not the value a deletion request has to hunt down later. This approach gives you control over where the data lives and how long it stays. It does not, by itself, turn a transcript containing raw PHI into something a single erasure request cleanly resolves, and no vendor should tell you otherwise.

What this is not: a compliance certificate

None of the above makes a deployment HIPAA certified, because the HIPAA Security Rule does not certify products, and this post will not pretend a database schema is a legal shield. What it does give you is a straight answer to the question an auditor or an incident responder actually asks. Where is the data, who can reach it, how long does it live, and can you produce it without a subpoena aimed at a third party.

Commander is self-hosted in your own cloud or data center, or on a dedicated single-tenant server DataShield operates for you. There is no multi-tenant SaaS tier and no shared control plane sitting between your Claude Code sessions and your own infrastructure. Read the Commander architecture or see how DataShield Auth governs the MCP tools those sessions can call.

Self-hosted Claude Code transcript storage is the precondition for that conversation to even start. A vendor-hosted transcript you cannot point to is not a control you can describe to an auditor, no matter how good the underlying model is.

Frequently asked questions