DOCS · DURABILITY

Conversations & data

Cortex stores coding conversations and run history in a protected SQLite database owned by the server. Browser storage remains a convenience cache rather than the authoritative record.

Durable conversations

Open and archived conversations retain their workspace, title, provider, model, OpenCode session identity, state and ordered transcript events. Refreshing the browser—or opening Cortex from another browser—loads the server-side conversation history after authentication.

Legacy browser migration

When the database contains no conversations, Cortex imports the existing browser-local sessions once. After that first migration, the server is authoritative. This preserves earlier dogfooding conversations without allowing stale browser caches to overwrite established server history.

Agent-run evidence

Each agent invocation records its conversation, prompt, state, start/finish time, OpenCode session identity, token counts, estimated cost and failure text. Conversation snapshots and run records are separate: the transcript provides the human view while run rows preserve execution history.

SQLite foundation

The database lives in Cortex's private data directory as cortex.db, uses numbered transactional migrations, foreign-key enforcement, WAL journaling, a busy timeout and restrictive file permissions. Startup rejects a database schema newer than the running Cortex binary rather than guessing how to interpret it.

Single-binary frontend

Nift remains the source frontend workflow: content/ and templates/ build into public/. Go embeds that generated output, so release archives and go install produce a self-contained Cortex executable. --static and CORTEX_STATIC_DIR remain development/custom-deployment overrides.

Back up the data directory.Embedding the frontend makes the executable portable; it does not embed instance data. Preserve cortex.db, authentication state and stored provider configuration when moving an installation.

Consistency and recovery

Conversation, event and run changes use SQLite transactions. Bulk imports are all-or-nothing, and a restart marks any persisted running work interrupted before serving clients. Lists and searches are capped at 250 results; narrow the query when the cap is exceeded.

Database and accounting

Cortex uses owner-only SQLite with foreign keys, WAL and FULL synchronization. Migrations are transactional and a database newer than the running binary is refused. Token counts and estimated cost come from provider/OpenCode events; use provider billing records for financial reconciliation.