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 lands wherever the launching tool put it. No one cares for a side project. For a team shipping regulated software, that transcript is a record. It shows each file the agent read and each command it ran. "Wherever the tool decided" is not an answer a security review will accept.

This setup flips the default. A session might otherwise live in someone else's cloud. Or it might sit spread across a laptop's local disk. Instead, it lands in a database your team runs. It follows your retention rules. It stays as easy to search as any other day-to-day record.

DataShield Commander runs on that default already. Sessions and transcripts write to a PostgreSQL database on the server that runs Commander. That server can be your own cloud or your own data center. Or a single-tenant server DataShield runs just for you. Not Anthropic's servers. Not a personal Claude web account. It doesn't sit on DataShield's own systems either. The only network call that leaves the building is the API call to the model itself. Any Claude Code install makes that same call to do its job.

What Commander actually keeps from a session

Commander indexes, searches, and archives each logged Claude Code session. It links to its transcript file in a fixed way, never guessed from a filename. A session row carries its persona, the prompt count, the transcript size, and timestamps. The actual conversation sits alongside all of it.

That is not a summary written after the fact. It is the session itself. The boot prompt a persona launched with came first. Then the turns that followed, and anything the agent produced along the way. Screenshots and generated artifacts come along too. A provenance registry captures all of it, not left loose in a directory somewhere. Model, effort level, and the account that ran the session sit in the breadcrumb too. No one has to reconstruct whose API key was active from memory.

That setup only earns its keep if the record answers a real question later. Which persona ran this? What did it read? What did it call, and when? Commander builds the session row to answer that, not a curated version of it.

That completeness also makes the record boring in the best way. A boring, complete transcript beats an exciting, curated one. Someone always needs the truth instead of a summary.

Search: finding one session in a thousand

A transcript archive no one can search is a compliance liability with extra steps. Commander indexes the logged transcript, so you can search it from the top bar. The transcript-search feature governs the endpoint that serves it (GET /api/claude-sessions/:sid/prompts). It is a gated feature, not an afterthought bolted onto the session list.

That matters for the ordinary case as much as the audit case. An engineer might need to recall which session fixed a flaky migration six weeks back. They shouldn't have to grep a folder of raw JSON files by hand. A security reviewer asking "did any agent read this file" needs that same search. It is aimed at a different question. Storage only earns its name when it comes with a way back in. Search is that way back in.

How retention works for this kind of storage

Transcripts do not sit in one pile forever. Commander runs a hot-to-cold roll on an adjustable cadence (archive_sweep_interval_ms). It moves idle sessions from an active state into an archived one. That happens after an adjustable idle window (session_archive_park_idle_minutes). Archived sessions still exist, still search, and you can reopen them. They just sit out of the way of the active session list.

You can also trash a session instead of archiving it. A trashed transcript doesn't stick around forever. 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 chose for you. That is the entire point of running this on your own PostgreSQL. Not 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 retention question a policy team will eventually ask. The real question is not whether the vendor retains data forever. It is what your team set, and whether you can prove it. A retention window you set beats a vendor's undocumented default. You can point to it in a config file.

Erasure, and what it does not solve

Erasure needs an honest caveat, so here it is. Take the spirit of GDPR's Article 17 right to erasure. It expects a controller to know where a subject's data lives. Only then can it honor a deletion request. Purging a trashed transcript past its retention window is a simple delete against your own database. That's 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. There, destroying a per-subject key makes each token for that subject unrecoverable. The audit chain itself stays intact.

That distinction matters when a session transcript captures PHI or another regulated field directly. It matters less when a token stands in for it instead. The practical fix sits upstream of storage, not downstream of it. Tokenize identifiers before an agent's context ever includes them, using DataShield Ontology. Then 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 do that by itself. A raw-PHI transcript still resists a single, clean erasure request. No vendor should tell you otherwise.

What this is not: a compliance certificate

None of the above makes a deployment HIPAA certified. The HIPAA Security Rule does not certify products. This post will not pretend a database schema is a legal shield. What it gives you is a straight answer. It answers the question an auditor or an incident responder asks. Where is the data? Who can reach it? How long does it live? Can you produce it without a subpoena aimed at a third party?

You self-host Commander in your own cloud or data center. Or on a single-tenant server DataShield runs for you. There is no multi-tenant SaaS tier. No shared control plane sits 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. It's not one you can describe to an auditor. That stays true no matter how good the underlying model is.

Frequently asked questions