Your data, your machine

Most products say your data is yours. Sonderr was built so that the sentence is boringly, verifiably true: your sessions, your files, your credentials and your model live under your home directory, and the product is a program that reads and writes them — not a service that holds them. This page is the contract in operational terms. It’s the guide to read before you trust the rest.

1 · The local-first contract

The architecture starts from one decision: the runtime runs on your machine and serves the workspace at 127.0.0.1:4173 — a loopback address, reachable only from your computer. The browser tab is the product; the heavy lifting happens on your hardware; and your work exists as ordinary files that ordinary tools can read. There is no DXN1 server holding your sessions, no account to sync through, and no cloud copy that outlives your machine. When you use a hosted model, the relevant context travels to that provider for the turn — that’s what “provider” means — but the store of record never leaves the disk it’s on.

The corollary matters just as much: you are also the administrator. Backups are yours to make, and so is deletion — which is why this page exists in the docs instead of a settings screen nobody reads.

2 · The data map

Three locations, all plain files. This is the complete list of what Sonderr touches on a standard install:

• ~/.sonderr/ — your data: sessions and store, credentials (owner-only permissions), MCP config, Sonderr-v1 model files if you installed the local model, task notes, and update.log.
• ~/.local/share/sonderr-v1.5 — the app folder: the program itself, plus timestamped backups kept by the updater.
• ~/.local/bin/sonderr — the link: the launcher that puts the command on your PATH.

Uploads follow their sessions under .sonderr/uploads/<session>/, so anything you dragged into a conversation is exactly where the conversation is. Deliverables the agent produces land in your workspace directory like files from any other tool. Nothing is scattered, nothing is hidden, and nothing needs Sonderr to be running in order to be read.

3 · What crosses the wire, and what never does

Two kinds of network traffic exist, and both are documented rather than implied. First, the update check: since v1.5.10, every start of a managed install contacts the official GitHub Releases endpoint. That request shows GitHub your IP and normal request metadata — and nothing else: no version history, no prompts, no files, no credentials. The comparison happens on your machine, and a newer stable release blocks the workspace until it’s installed, fail-closed, with no “skip this version.” Second, model traffic: the context a given turn needs travels to the model provider you chose for that turn — a free-tagged model, your own key, or the local Sonderr-v1 model, which keeps the turn entirely on your machine.

Everything else stays put. Web research is bounded and read-only through verified-domain filters with private hosts blocked. Connectors talk to the services you connected — Gmail, Notion, Slack, Drive, GitHub, Linear — under your authorization, with send-side actions drafting in the open first. Wallet keys never render in chat, and secret scrubbing keeps credentials out of conversation content. The deep version of all of this is in Security, updates & privacy.

4 · Credentials and permissions

Credentials live in ~/.sonderr/ with owner-only permissions — readable by your user, not by the rest of the machine. API keys you add are yours; the local-first design means there is no DXN1-side key vault to breach because there is no DXN1-side vault. Keys used for wallets sit under the strictest rule in the product: they never render in chat, full stop, and wallet actions are prepare-then-confirm — the agent prepares, you confirm, and nothing moves on a stale authorization.

The same philosophy governs agent behavior on disk: task modes decide what a turn can do, shell commands need Full PC access plus an explicit request in the current message, and a permission granted last message doesn’t survive into this one.

5 · Back up in one copy

Because everything that matters is one directory, backup is one command:

cp -a ~/.sonderr /path/to/backup/sonderr-backup

That’s sessions, store, credentials, MCP config, task notes — the whole state of your working life in the product. Do it while Sonderr isn’t mid-task (a checkpoint mid-write is the only moment the copy could be internally inconsistent, and even then the previous checkpoint survives). Restoring is the reverse copy. If you also want the programs, add the app folder and the link — but for data, ~/.sonderr is the world.

6 · Move to a new machine

Moving is backup plus reinstall. On the new machine: install Sonderr with the usual one command, let it create a fresh setup, quit it, then replace the fresh ~/.sonderr with your backup copy. Launch again, and the workspace picks up where it left off — same sessions, same credentials, same task notes. The installer recognizes an existing data directory and treats it as a recognized setup rather than a conflict, so the move doesn’t fight the product. If the new machine is a different platform and you were running the optional Sonderr-v1 local model, reinstall the model there; it’s a fresh verified download, not something to copy blind.

7 · Wipe it all

Three things to remove, all plain files — and one honest distinction. The app folder (~/.local/share/sonderr-v1.5) and the link (~/.local/bin/sonderr) remove the program. The data directory (~/.sonderr) removes your sessions and credentials — that’s the one that matters for privacy, and it’s the one people skip by accident. Remove the app and link but keep ~/.sonderr, and a future reinstall picks everything back up as a recognized setup; that’s the right move for a reinstall and the wrong move for a goodbye. For a full exit: remove all three, and your data is gone because it never existed anywhere else. The site-side story — what the website holds, which is close to nothing — is in Data export and Data retention.