Skip to main content
Vibex is local-first: the authoritative runtime stores projects, workspaces, sessions, timelines, provider profiles, terminal metadata, browser profiles, computer-use audit data, routing ledgers, and remote device records. Remote connections receive only authorized projections.

​
Where data lives

Relay rooms and connections are transient. Relay logs should contain routing, counts, and timing metadata only.

​
What survives a restart

After a restart, the runtime reloads workspaces, sessions, and configuration from durable records: Kept (SQLite or runtime home):
  • Projects, workspaces, and workspace modes
  • Sessions, timeline events, messages, goals, delegation relationships, and archive state
  • Provider profiles, shared Providers, route groups, MCP servers, Skills, and Prompts
  • Terminal metadata (tab names, bindings)
  • Unsent composer drafts and scheduled sends
  • Browser profile and imported login state
  • Remote device grants and SSH/WSL connection profiles
  • Workbench background, themes, and TUI preferences
Not kept (memory only):
  • Running Agent processes
  • Terminal contents and scrollback
  • Open browser tabs and live frames
  • Active connections and live event subscriptions
  • An in-progress computer-use session
running in the database is only the last observed state, not proof that a process is alive. After a restart, verify the process before retrying.
A lost terminal is marked stale. Use the new terminal snapshot; do not replay commands from the old one.

​
Device revocation

Revoking a device in the authority’s device list immediately closes its active connection with device_revoked.
  • Reuse requires pairing again.
  • Old QR codes, connection strings, grants, and tickets are invalid.
  • Revocation is written to the device audit record.
  • An SSH/WSL runtime is reachable only through the desktop tunnel; phones cannot pair with it directly.

​
Diagnostic data

Settings → Data & Diagnostics can clear diagnostic data. The current release has no user-facing diagnostic export page; if you export a bundle through developer tooling, check the redaction first: Must be removed:
  • Tokens, private keys, pairing codes, and connection strings
  • Full prompts and file contents
  • Git diffs and raw terminal bytes
  • Browser cookies, localStorage, and login state
  • Computer-use typed text, clipboard contents, and screenshots
Safe to keep:
  • Version, channel, and platform
  • Structured error codes
  • Redacted timestamps
  • Non-sensitive resource ids
Diagnostic export is one-way: once posted publicly it cannot be recalled. Read it yourself before uploading.

​
Backup

Vibex does not currently provide a one-click backup button. The reliable approach is to back up the entire runtime home:
  1. Stop the runtime using that home (desktop, TUI, or headless server).
  2. Copy the whole home, including vibex.db, vibex.db-wal, vibex.db-shm, identity keys, Agent installs, browser profile, and credential references.
  3. To restore, place the backup in an empty directory and point the runtime at it.
  4. After restoring, check workspace paths, device grants, and provider credential references.
Copying only vibex.db without WAL/SHM can produce an inconsistent database. Do not copy the database while the runtime is writing to it.
A headless runtime stores data under /data by default; mount it as a persistent volume or sessions disappear when the container is recreated. An SSH/WSL runtime stores data under ~/.local/share/vibex/server in the remote home.

​
Cleanup

Settings → Data & Diagnostics offers per-category cleanup: sessions and attachments, terminal data, and diagnostic data. These actions cannot be rolled back. Browser data can be cleared separately under Settings → Browser → Clear browser data. Computer-use records and the gateway ledger stay with the runtime data unless you clean the corresponding database.
Resetting settings only affects preferences. Deleting the database, data directory, or workspace directory is a different, destructive operation. Confirm you no longer need the data first.

​
External service boundary

Agents, MCP servers, shared Providers, and browser pages may send the context you explicitly provide to a provider or external service. Read the service’s privacy policy, and limit data with the smallest scope, permission approvals, and minimal attachments. Pairing with a remote authoritative runtime means that runtime’s administrator can see your session data. When you self-host, that administrator is you; confirm this before connecting to someone else’s runtime.