Where data lives

Stellar stores your work in your machine’s configuration folder. Knowing what is in there — and what is not — is what makes the promise of carrying your work house to another PC honest.

What is on disk

The database runs in WAL, and the schema is versioned. A new card type requires no migration: the kind is loose text.

Three of these files deserve a sentence:

• providers.json is how you teach Stellar to spawn a CLI it does not know. The app watches the file: editing does not require a restart, and the live registry re-syncs saying how many providers came in, went out and which entry was refused. The file has a format version, and an unknown version is refused whole — never “interpreted by luck”, which is how a format breaks a user’s config in silence.
• update-prefs.json keeps the version you deferred. Only one, and it is a string, not a clock: a newer version notifies again. “Skip this version” does not exist on purpose — skipping is a stronger promise than deferring, and whoever skips stops being told about a fix.
• update-swap.log exists only on macOS, where installing unsigned swaps the bundle. The app shows the path of that file on its own screen: it is what you send if the swap fails.

The card screen is not saved by default

Closing a card stores the identity and the registry facts — when it died, whether it died from quota, whether the kill was requested. The screen, no: the scrollback does not become durable text.

It is not technical shyness. The screen is a real work screen, with paths and code excerpts, and persisting that shifts the regime from “ephemeral pixels on your monitor” to “durable text, read by any agent that can open the board database”. This house has already been bitten once by a card that did a recursive grep in the user’s directory; storing screens without thinking would repeat the mistake with more reach. Whoever enables persistence takes on the burden — it comes with secret redaction, but the redaction is by pattern, not by semantics, and it does not reach a secret written in free prose.

Three buckets

When people talk about syncing, each item falls into one of three buckets.

Travels — the board content (cards, notes, tasks, reports, connectors, sprints, assets) and the innocuous preferences. Also travels, through git, the half that was already resolved: AGENTS.md, CLAUDE.md, the ai/ layer and the repository skills.

Stays — what is local by nature: Chromium caches, sockets, MCP ports, pan/zoom (which does not even persist), PIDs, and session identities tied to project paths.

You decide — API keys and provider credentials. They would technically travel, but they cost security; retyping them on each machine is zero custody, and custody is responsibility over a third party’s key.

The exception that cannot be hidden

The keys stored via the system keychain do not open on another machine: the cryptographic material lives in the OS vault. Copying the secrets file leaves opaque keys, and the app treats that as “no key” — which is correct, and is why the entry screen says “you decide” about them, instead of promising “the same on any PC” without the exception.

Absolute paths

Boards and cards store absolute paths of the working directory. A board that points at a path that does not exist on the other machine breaks more than not syncing — that is why path remapping is a declared decision, not a side effect of sync.