Local control
Wenlan Local Data and Privacy
Where Wenlan stores local AI work memory, what stays on your machine, and when connected model providers may see prompts.
At a glance
01
Quick answer: Wenlan's daemon, database, pages, sessions, and readable artifacts live locally by default.
02
Connected AI clients may still send prompts to their model providers; Wenlan keeps its own memory store local, inspectable, and removable.
03
The public wenlan.app website uses separate privacy-limited analytics; installed Wenlan still has no cloud sync or product telemetry by default.
01
Quick answer: what stays local
Wenlan's durable memory store, daemon database, Markdown pages, session handoffs, and project status files live on your machine by default.
There is no Wenlan cloud sync or telemetry path by default. Connected AI clients may still send prompts to their own providers, so treat memory content as sensitive project data.
02
Public website analytics
The public wenlan.app website is separate from the installed Wenlan runtime. It uses Vercel Web Analytics for aggregate website visits and a configured Umami tracker for bounded GitHub, Get Started, Learn article, setup-path, and successful waitlist-signup events.
The Umami tracker is restricted to wenlan.app, excludes URL search parameters, and respects the browser's Do Not Track setting. Custom event properties are limited to placement, locale, content context, and a fixed destination category. They never include memory content, code, commands, user paths, search terms, names, email addresses, or stable account identifiers.
The release-update form sends the submitted email to Resend. When bounded acquisition properties are enabled, Resend also stores the signup locale, landing path, referrer host, and UTM source, medium, and campaign with that contact. Those fields are not sent to Umami, and GitHub's cumulative release download counters are reported separately rather than joined to an individual contact.
This website measurement does not add cloud sync or telemetry to installed Wenlan.
03
Where data lives
Wenlan exposes human-facing artifacts under ~/.wenlan. The daemon database lives under the operating system's application data directory and is linked from ~/.wenlan/db for convenience.
The important files are readable without a special app: pages are Markdown, session logs are Markdown, and project status is stored beside the session records.
- ~/.wenlan/pages/: distilled wiki pages.
- ~/.wenlan/sessions/: session handoff logs.
- ~/.wenlan/sessions/_status/: current project status records.
- ~/.wenlan/bin/: installed Wenlan CLI, daemon, and MCP connector binaries.
- ~/.wenlan/db/: link to the daemon's local database store.
- macOS: ~/Library/Application Support/wenlan/.
- Linux: ~/.local/share/wenlan/ or $XDG_DATA_HOME/wenlan/.
- Windows: %LOCALAPPDATA%\origin\ (current runtime legacy directory).
04
Readable artifacts and retrieval
Raw captures and recall live in the daemon-owned store. Pages, session logs, and project status are readable Markdown projections under ~/.wenlan.
This keeps search fast and structured while giving people inspectable artifacts for pages, handoffs, and status without pretending every memory is a Markdown file.
05
Local memory setup
Wenlan stores, embeds, deduplicates, and serves hybrid search without requiring a local model download or Anthropic API key.
ANTHROPIC_API_KEY is only used when you explicitly opt into daemon-side Anthropic work with the key setup path. Optional model and API paths can add heavier language features, but they are not required for the basic memory loop.
06
Correction and deletion
If a memory is wrong, capture the correction with why it supersedes the old fact. If a memory should be removed entirely, use /forget with the memory ID.
Delete and forget operations are separate from service uninstall. For distilled pages, inspect the Markdown directly. User-edited pages are treated carefully so automated distillation does not overwrite human work casually.
Next
Backup and Migration
Back up Wenlan's readable artifacts and daemon data together, then verify the restored runtime before trusting recall.
Read next