Data Locations
sivtr is local-first. Most data it uses is already on your machine, and everything sivtr generates lives under one home directory:
SIVTR_HOMEif set (Grok-style whole-home relocation),- else
~/.sivtron every platform.
~/.sivtr/ config.toml ← configuration history.db ← captured terminal output (SQLite) sets/ ← WorkSet checkpoints (@last, @name) workspaces/<key>/terminals/ ← shell session logs (session_<pid>.jsonl) cache/ ← agent session parse cache identity.key ← device identity for remote memory remote-state.db ← peers, shares, grants, invites, mounts daemon.json / daemon.lock / daemon.logUse CLI commands instead of editing these files directly.
Migrating from earlier versions
Section titled “Migrating from earlier versions”Sivtr ≤ 0.4 scattered its data across the platform config, state, and data directories. sivtr doctor reports anything still there, and sivtr doctor --fix moves it into the single home. Migration merges directories and never overwrites an existing destination; conflicting items are reported and left in place.
Config file
Section titled “Config file”<SIVTR_HOME or ~/.sivtr>/config.tomlShell session logs
Section titled “Shell session logs”Shell integration writes per-process structured session logs under <home>/workspaces/<key>/terminals/session_<pid>.jsonl.
These logs power:
sivtr import;sivtr copycommand-block workflows;sivtr diff;- command-block navigation in the browser.
History database
Section titled “History database”Captured terminal output is stored in a local SQLite history database when [history].auto_save = true:
<home>/history.dbUse CLI commands instead of editing the database directly:
sivtr history listsivtr history search "panic"sivtr history show 42Retention is controlled by:
[history]max_entries = 00 means unlimited.
Agent provider data
Section titled “Agent provider data”sivtr reads provider-owned local data. It does not upload transcripts.
| Provider | Data source |
|---|---|
| Codex | ~/.codex/sessions rollout JSONL files |
| Claude Code | Current transcript/session environment and local Claude transcripts |
| Hermes | Primary: $HERMES_HOME/state.db (Windows default %LOCALAPPDATA%\hermes, else ~/.hermes). Residual: sessions/*.jsonl under the same home. |
| OpenCode | OpenCode local database |
| Cursor | ~/.cursor/projects/**/agent-transcripts/**/*.jsonl (override home with CURSOR_HOME) |
| OpenClaw | ~/.openclaw/agents/<id>/agent/openclaw-agent.sqlite (legacy JSONL under sessions/) |
| Grok | ~/.grok/sessions/** (summary.json + chat_history.jsonl; override home with GROK_HOME) |
| Pi | Pi agent session JSONL files |
Provider formats differ; sivtr normalizes them into sessions and dialogue units for copy, picker, search, and show workflows.
Codex exported mirrors
Section titled “Codex exported mirrors”codex export writes a copy of local Codex session files into a destination you choose:
sivtr codex export --dest /srv/sivtr/root-codexThe destination receives a sessions/ tree. Another account can read it by adding:
[codex]session_dirs = ["/srv/sivtr/root-codex/sessions"]Use read-only permissions for shared mirrors when possible.
Generated launchers
Section titled “Generated launchers”Linux shortcut generation writes:
~/.local/bin/sivtr-pick-codex;~/.local/share/applications/sivtr-pick-codex.desktop.
macOS shortcut generation writes:
~/.local/bin/sivtr-pick-codex;~/Library/LaunchAgents/dev.sivtr.pick-codex.plist.
Windows hotkey state is stored under the single home and is managed by:
sivtr hotkey statussivtr hotkey stopRemote daemon state
Section titled “Remote daemon state”Cross-device remote memory uses a device-scoped daemon. State lives under the single home:
| File | Purpose |
|---|---|
identity.key |
Stable device identity for iroh |
remote-state.db |
SQLite peers, shares, grants, invites, mounts, audit |
daemon.json |
Running daemon control info (port, token, node id) |
daemon.lock |
Single-instance lock |
daemon.log |
Daemon log file (sivtr serve logs) |
sivtr serve statussivtr serve logssivtr share listsivtr remote listsivtr peer listsivtr ws listRemote access is opt-in. Nothing is shared until sivtr share (or share add) runs. Mounts are workspace-local aliases registered with sivtr remote add. Feature guide: Remote Access.