Where Your Data Lives

Everything lives under ~/.klaus/:

• settings.db: settings and local state (SQLite, WAL mode).
• sessions/: this one directory holds two things. Session records are <creation-timestamp>-<session-id>.jsonl (so sorting by filename is sorting by time, and to find a given session search for its id). The directory with the same name is that session's workspace, used only when you have not pointed the session at a project directory. __klaus__ is the shared anchor directory used when there is no project.
• projects/<working-directory-path, slashes replaced with dashes>/: per-project memory (the memory/ subdirectory). Session metadata no longer lands in a separate sidecar file; it is written into the header of the session record (the jsonl file). So "past sessions of the same project" are grouped by working directory path, and renaming the directory moves the whole group.
• agent-memory/: memory files.
• skills/, agents/, commands/, plugins/: global skills, sub-agents, slash commands and plugins. (The plugin install ledger itself is not in this directory; it lives in the [plugins] section of config.toml. See Plugins.)
• visualizations/<session-id>/: one directory per session, holding its inline visualization pages. It is both the writable root for those pages and the preview allowlist root, so only the current session's pages can be rendered.
• friends/<friendship id>/: each friend's shared subfolder, used as the base directory for tasks that friend sends; see Friends.
• pets/: pets you imported or created (sprite sheet plus pet.json); see Mini and Pets.
• checkpoints/<project-fingerprint>/: the shadow Git repository for file checkpoints. The worktree points at your project while the history lands here, so your own .git, branches and staging area are left completely untouched (this capability is off by default; see The Main Interface and Sessions).
• channels/<platform>/access.json: the access control configuration for each channel. See Channels.
• electron/: desktop runtime data, including resume-ledger.json, the ledger of tasks that are resumed automatically after a restart.
• Logs: the desktop host writes its diagnostics to electron-host.log, one JSON object per line, with a kind field naming the source — scheduled task dispatch and delivery is cron, dreaming and memory maintenance is memory-maintenance, channel startup failures are channel-failed / channel-startup, and automatic resume after a restart is resume-recovery (once the file passes 10 MB it is renamed to electron-host.log.previous at the next launch). logs/ holds per-topic logs: channel traffic in channel-activity.jsonl, MCP diagnostics in mcp-diagnose-*.log, and model request logs in provider-*.log. The cron.log and memory-maintenance.log files left by older versions are no longer written. The desktop app's output never reaches the terminal that launched it, so these mechanisms all write their own files. When troubleshooting, read the relevant file directly; it is more useful than digging through a console.

Settings themselves come from two sources. Most toggles and panel states are key-value rows in settings.db, and a key that has never been written has no row at all, so "this setting cannot be found" usually means it is still at its default value rather than that it was cleared. Engine-side configuration lands in ~/.klaus/config.toml, which the engine reads itself: engine switches that are not surfaced in the UI, the plugin ledger, marketplace catalog registrations and trust records are all there. Credentials such as API keys and pairing tokens are stored here too, but they are never handed to the model: whenever Klaus reads settings for itself, credential fields always come back masked.

Session records imported from other clients are written into ~/.klaus/sessions/ (the engine's session store directory), not under projects/. An import that does not specify a project also gets a workspace directory created at sessions/<session-id>/.

Deleting ~/.klaus resets Klaus to a fresh install: sign-in, settings, sessions and memory all disappear.