Privacy model

What gets recorded, what never does, and the layered defenses behind Tadoru's safe-by-default design.

Tadoru deals with one of the most sensitive datasets on your machine: what you do all day. That’s why its principle is not “can be used safely” but “safe with the defaults untouched.”

The five guarantees

1. No egress. The binary has no feature that sends data anywhere — not disabled, but nonexistent. Everything stays in a local SQLite file.
2. No screen recording. No screenshots or screen-capture APIs. Tadoru reads OS accessibility and event metadata only.
3. No keystroke content by default. Typing is recorded as “typing happened in this kind of field” — never what you typed, unless you explicitly opt in.
4. Capture-time filtering. Excluded apps and sites are discarded before they reach the store. There is nothing to leak later, because nothing was written.
5. Read-only exposure. The MCP server is a read-only view. Agents can read your timeline but can never change what gets recorded or weaken your filters.

What is recorded with the default configuration

Capturing content is opt-in

Setting capture.text_content = true in the configuration enables recording of field values and typed content (ui.value, input.key, clipboard contents). This is off by default and Tadoru never suggests enabling it. If you do:

• Password fields remain excluded regardless — secure fields are dropped at capture time.
• Redactors still scrub recognizable secrets from captured values.

Automatic exclusions (no setup required)

• Password fields — anything macOS marks as a secure text field is dropped at the source.
• Chrome Incognito — Chromium exposes the window mode deterministically via AppleScript, so Incognito windows are always excluded. There is no configuration knob because none is needed.
• Built-in app exclusions — password managers and credential stores (e.g. 1Password, Keychain Access) are excluded by a hard-coded layer that is always applied and cannot be lifted, not even with include_only_apps. It is a separate layer from the editable exclude_apps defaults in config.toml.

Redaction as a second line of defense

Even for values that are captured, pluggable redactors scrub recognizable sensitive content — emails, credit-card numbers, tokens (redactors = ["email", "credit_card", "token"]). Every event carries a redaction field recording whether rules were applied, so downstream consumers can tell.

Honest limitations

No privacy design is complete without stating what it does not cover:

• Window titles from non-Chrome browsers. Safari and Firefox don’t offer a reliable way to detect private windows, so Tadoru doesn’t capture URLs from them at all — but their window titles are still recorded like any other app’s, and a private window’s page title can end up in a title. To avoid this entirely, exclude the browser itself: tadoru filter exclude-app.
• Window titles from Chrome Incognito windows. Incognito detection lives in the URL-capture path, so Incognito windows never produce browser.navigate events — but their window titles can still be recorded as window.title events via Accessibility, like any other app’s. To avoid this entirely, exclude the browser itself: tadoru filter exclude-app.
• What happens after an agent reads your data. The MCP server and CLI never send anything anywhere, but an agent that reads your timeline will typically send it to its LLM provider. That handoff is governed by the agent, not Tadoru. The shipped skill files instruct agents to narrow the time range before sending.

Consent and intended use

Tadoru records your own activity on your own machine, with your knowledge. It is not built for monitoring others, and using it that way may be illegal in your jurisdiction. If you use it on an employer-managed device, follow your organization’s policies.