Whyline

Data and privacy

What Whyline sends, stores and keeps on your machine. This page describes what the code does. It is not a legal privacy policy or terms of service.

What the CLI sends

  • Claude Code prompts: the prompt text (up to 20,000 characters), unless you turned it off, plus the session id and your git email.
  • Claude Code edits: the tool name and the path of the file changed (relative to the project when possible).
  • Commits: the commit hash, author email, the commit message (up to 5,000 characters) and the changed file paths (up to 1,000). When Claude Code edits were recorded for the commit, the prompts from that session are included too.

What is not sent, and what is not filtered

  • The hooks send file paths, never the contents of your files.
  • Prompts and commit messages are sent exactly as written. Whyline does not scan or redact them, so anything in them, including source code, secrets or personal data you pasted, is sent and stored. The only control is turning prompt text off, below.
  • Author emails and file paths are sent whether or not prompt text is on.

Keeping prompts private

whyline login --url https://whyline.wrklyst.com --key wl_... --no-prompts
# or: export WHYLINE_NO_PROMPTS=1

A prompt event is still recorded, without its text, and the text is not remembered locally, so commits will not carry it either. File paths, commit messages and author emails are still sent. This setting is enforced by the CLI on your machine; the API itself stores whatever a client sends. Logging in again keeps it until you pass --prompts. WHYLINE_NO_PROMPTS turns it on with 1, true, yes or on; an opt-out in either place wins.

What the server stores

  • Workspaces: the name, a SHA-256 hash of the API key (never the key), a SHA-256 hash of the IP address that created it (used only for the hourly signup limit), and the creation time. The IP hash is unsalted, so treat it as pseudonymous, not anonymous.
  • Events: the fields listed in the API reference, tied to one workspace.

The hosted instance at whyline.wrklyst.com is the Vercel and Supabase deployment described in the repository README. Its tables have row-level security on with no policies, so only the server's service role key can read them. A server you run yourself stores the same data in SQLite.

What stays on your machine

In ~/.config/whyline (or WHYLINE_HOME):

  • config.json: server URL and API key in plain text.
  • queue.jsonl: complete events waiting to be sent while offline, including prompt text if prompts are on. Removed as they are sent.
  • edits.jsonl: recent Claude Code prompts and edited file paths, used to link prompts to commits. Records older than a day are removed, but only when a commit is recorded.

The directory is created with mode 0700 and these files with mode 0600, so only you can read them, whatever your umask. Files left by older versions with wider permissions are tightened the next time Whyline runs. On Windows they rely on your user profile's permissions.

The dashboard keeps the API key in this browser's local storage, so it opens your workspace directly next time. Switch workspace removes it, and a key the server rejects is removed automatically. The key is never put in a URL.

Who can read a workspace

Anyone holding the workspace API key can read and write all of its events. There are no user accounts or per-person permissions. Treat the key like a password and share it deliberately. If it leaks, whyline rotate-key replaces it; the old key stops working at once. Signing up is open on any server: anyone who can reach the server can create a workspace (see self-hosting for how the limit works).

Deleting data

whyline delete-workspace --yes (or DELETE /api/workspaces) deletes a workspace and all of its events, for everyone who uses its key. It cannot be undone. The CLI also forgets the key and clears its local queue, so nothing from that workspace is sent again. Single events cannot be deleted; whoever runs the server can remove rows directly in the database. For what is worth keeping, and for how long, see what an audit trail for AI-written code should record.