Privacy Policy

The short version

Suvadu stores shell history, captured AI-agent sessions, and skills locally on your machine. Suvadu itself does not upload them: there is no account system, no telemetry, and no cloud sync. A connected AI client can retrieve that data through Suvadu's local MCP server and may send it to its model provider under that client's own settings.

What Suvadu stores

Suvadu records the following data locally, mostly in a SQLite database (history.db):

• Commands — the full command line, including its arguments. Arguments can contain file names, hostnames, or secrets; see Secrets protection below.
• Working directory, start and end timestamps, duration, and exit code of each command
• Git branch (since 0.5.1) — for a command recorded live inside a git repository, the branch checked out where it started, or the short commit hash of a detached HEAD. It is read from the repository's own files (no git runs), redacted like command text, and never stored for an excluded command. Off with Record Git Branch in suv settings or [shell] capture_git_branch = false.
• Failure output (since 0.5.1, off by default) — only if you turn on Keep Failure Output ([capture] failure_output): for a command that exited non-zero, the last 4 KB it printed, which stream it came from, and how many bytes were left out before it. It comes only from agent hooks that already carry the output (Claude Code, Cursor, Codex, OpenCode) and suv wrap; the Zsh and Bash hooks never see output. Escape codes are stripped and the text is redacted with the command's own policy before it is cut; an excluded command keeps nothing. This is the only command output Suvadu ever stores.
• Executor type and name (terminal, IDE, AI agent, CI, script)
• Shell sessions: session ID, hostname, and creation time
• Your tags, notes, bookmarks, and aliases
• Agent prompts captured by supported hooks, attached to the commands they triggered (the latest captured prompt for each agent session is also cached as a small file in a prompts folder in the data directory)
• Native agent sessions imported from Codex, Claude Code, and OpenCode: your prompts, the assistant's responses, model names, and token usage reported by the provider, plus the working directory and import checkpoints. Since 0.5.1, Cursor conversations too, from Cursor's hooks: prompts, each turn's final response, how it ended and the model (Cursor reports no token usage), with a 64-bit fingerprint of each stored event, taken after redaction, so a repeated hook run is stored once. Redaction and length limits apply; private reasoning text and unrestricted tool output are not collected.
• Agent git snapshots (since 0.5.1, on by default) — up to two per agent session, taken at its first prompt and at each turn end: when, the directory, the repository root, the commit and branch checked out, and up to 500 changed paths with their git status. Never file contents or diffs. Paths matching your exclusions are left out and counted; the rest and the branch are redacted. When the what_changed MCP tool compares two snapshots it asks the repository for the commits between them at that moment; those subjects and paths are never stored. Off with Record Agent Git Snapshots or [agent] record_git_snapshots = false.
• Saved session summaries — text written by a connected AI agent, with the agent and model it declared and the IDs of the evidence it cited (only if you enable summary saving)
• Shared skills, their metadata, and pending or archived skill proposals from agents
• Skill trust (since 0.5.1) — for each repository skill file (.suvadu/skills/*.md) you trust, its project root, its path inside the project, a sha256 of its content and when you trusted it. Hashes only, never the file's text. suv skills untrust forgets a repository's trust.
• Backups — copies of the database made by suv backup and automatically before destructive deletes, stored in a backups folder in the data directory
• Capture fallback note (last-capture-error in the data directory, since 0.5.1) — written only when recording, a transcript import or a prompt cache had to fall back because config.toml or a .suvadu.toml did not load: when, which file, and the parse error. Owner-only, reported by suv doctor, and safe to delete.
• Update-check cache (update-check.json in the data directory) — the last known release version and the times of the last check and the last notice. It contains no command history.

Files you create with suv export, and native agent files written by suv skills sync, are written where you or the agent's configuration specify, as plain text.

Where data is stored

• macOS: ~/Library/Application Support/tech.appachi.suvadu/ (database, backups, and config.toml)
• Linux: ~/.local/share/suvadu/ for the database and backups, and ~/.config/suvadu/config.toml for configuration (or the $XDG_DATA_HOME / $XDG_CONFIG_HOME equivalents)

The data directory is restricted to its owner (0700), and the database file and backups to owner read/write (0600).

Secrets protection

Suvadu automatically detects and redacts sensitive values (API keys, tokens, passwords) before writing commands, captured prompts, imported agent-session text, failure output, git branch names and snapshot paths to the database. Since 0.5.1 it recognises more forms (OpenAI project and service-account keys, credentials in any scheme://user:pass@host URL, temporary AWS keys, whole PEM private-key blocks, and others), the Cursor prompt cache is redacted before it is written, and a project's .suvadu.toml can only tighten redaction and exclusions, never turn them off. Since 0.5.3 it also recognises the forms AI agents write secrets in: values under secret names in JSON, YAML and code, credential flags, auth and API-key headers, signed URLs and SQL passwords. A new rule applies to what is recorded after it; suv redact applies the current rules to history already stored, backups included, and keeps a copy of the database first that still holds every secret until you delete it. Redaction applies known patterns and can miss unrecognized secrets, so avoid putting secrets directly in command lines or prompts, and rotate any that were recorded. Skill bodies are stored as provided; do not include credentials in shared instructions.

Network requests

The Suvadu CLI never sends your history, commands, prompts, configuration, or any identifier anywhere. It makes network requests in two cases only:

• Update notices (since 0.5.0, on by default) — at most once a day, a background request reads the latest release number from version.txt, so Suvadu can tell you when a newer version is out. It is a plain HTTPS request with nothing attached. Turn it off with Check for Updates in suv settings, [update] check = false in config.toml, or SUVADU_NO_UPDATE_CHECK=1.
• suv update — only when you run it: it reads the latest version and downloads the new release from downloads.appachi.tech, and requests that release's notes from GitHub's API (api.github.com/repos/AppachiTech/suvadu/releases/tags/…). The requested tag names the release, not anything about you. Turning update notices off stops only the automatic check; suv update still makes these requests when you run it.

As with any web request, the receiving service — the download server, or GitHub — sees connection details such as your IP address and the time of the request.

MCP server

The MCP (Model Context Protocol) server runs locally and communicates over stdio with AI agents on the same machine. It opens no network ports. Enabled tools and resources return data — commands, prompts, assistant responses, session details, summaries, and skills — to the connected client. That client controls how the data is used and may send it to its model provider under its own settings. Suvadu does not call a model provider itself.

The default tools only read. Two optional write tools are off by default and appear only if you enable them in config.toml: save_session_summary stores a summary the agent wrote, and propose_skill stores a skill proposal that stays pending until you approve it.

Skills sync

suv skills sync writes active instructions into agent configuration files for Claude Code, Cursor, and Codex. Those agents can read the generated files according to their own settings. Since 0.5.1 the next sync removes the files it generated for a skill you removed or disabled, keeping any file edited since; see the skills reference for paths and cleanup behavior.

Skills committed in a repository's .suvadu/skills/ arrive with whatever you clone, so they are untrusted: sync writes one into your agent files only after you trust it, which records a hash of its exact content, and the MCP server lists an untrusted one by name and path only, never serving its text. Suvadu never writes, moves or deletes those files.

This website

This website (suvadu.sh) is a static site hosted on Cloudflare Pages. It makes one API call to GitHub to fetch the repository star count.

We use consent-first analytics (Google Analytics 4) to understand which pages are useful and how visitors find the site. Analytics are disabled by default and only activated if you explicitly accept the cookie banner. If you decline, no analytics cookies are set and no data is collected. You can clear your preference at any time by deleting the suvadu_analytics_consent key from your browser's localStorage.

Deleting your data

To remove all Suvadu data, delete the data and configuration directories listed above, plus any exports you created. Uninstalling the binary does not remove your history database. To remove a single captured agent session, use suv agent delete-session, which also deletes its git snapshots; this does not delete the agent's own transcript files. suv gc --failure-output deletes all stored failure output and keeps the commands.

Contact

Questions? Open an issue on GitHub.