Privacy model

DevRecall is on-device by design. This page is the precise version of that claim — what data lives where, who can see it, and what the optional cloud component actually does.

Where your data lives

Data	Location	Encryption
Activities (commits, messages, meetings)	~/.devrecall/devrecall.db (SQLite)	Filesystem (optional SQLCipher)
OAuth tokens	~/.devrecall/tokens/<source>.json	0600 permissions
API keys (OpenAI, etc.)	OS keychain	OS keychain encryption
Embeddings	Same SQLite DB	Same
Periodic summaries	Same SQLite DB	Same
Conversation history (chat)	Memory only (not persisted)	—

Nothing on this list is uploaded to a DevRecall server.

What leaves your machine

There are exactly four cases where DevRecall makes a network request that touches a non-vendor server:

1. OAuth callback (Slack, Google, Jira, Linear)

Slack and most providers don’t accept localhost as an OAuth redirect. The flow:

1. CLI opens your browser at the vendor’s consent page
2. After you approve, the vendor redirects to relay.devrecall.dev/oauth/<vendor>/callback?code=…
3. The relay exchanges the code for tokens using a client secret stored on the relay (not on your machine)
4. The relay hands the tokens to your local agent and deletes its copy within 60 seconds

The relay never sees activity content. It sees a short-lived OAuth code and the resulting access token in flight, then drops both. The relay’s source code is open in the main repo (relay/).

2. LLM calls (BYOK or Ollama)

When you use BYOK (OpenAI / Anthropic), DevRecall sends prompt + retrieved context directly from your machine to the provider’s API — your key, your account, no DevRecall proxy.

When you use local Ollama, the LLM call goes to localhost:11434. Nothing leaves your machine.

DevRecall never proxies LLM traffic. This is deliberate — proxying would make the privacy promise untrue.

3. Vendor API calls (Git, GitHub, Slack, etc.)

Each collector talks directly to its vendor:

• GitHub → api.github.com
• Slack → slack.com/api/*
• Google → googleapis.com/calendar/*
• etc.

These are the only network calls vendor APIs see, and they happen under the OAuth scopes you granted. Read-only in every case.

4. Update check (optional)

The CLI checks GitHub Releases for a newer version (cached for 24h). A separate relay.devrecall.dev/v1/version endpoint exists as a security kill switch — if a critical vulnerability ships, the relay can refuse-to-run a known-bad version until you update. The mandatory check fires at most once per hour and respects offline state.

You can disable the passive check by setting updates.check: false in config.json. The mandatory kill-switch check cannot be disabled — it’s the security backstop.

Telemetry

DevRecall collects zero telemetry. There is no opt-in toggle, no analytics payload, no usage counters. The only DevRecall-server traffic is the OAuth relay (above) and the version kill-switch check (below).

Slack and DM handling

By default, DevRecall does not request the im:history scope — your DMs are not collected. If you opt in, DMs default to “metadata only” storage (channel, time, no text).

Other people’s messages are stored only when they appear in a thread you participated in — and per-channel storage modes (full, summary, metadata) let you tune that further.

Source code transparency

DevRecall is MIT-licensed. The relay’s full source is in the main repo’s relay/ directory. You can audit, build, and self-host it.

The CLI binary you install via Homebrew or .deb is built from the same source by GitHub Actions; release artifacts include a checksums.sha256 you can verify.