FAQ

Wenlan includes a local memory substrate, but that is not the product headline. The product is a source-backed LLM wiki where decisions, context, handoffs, and pages remain useful across sessions and tools.

That distinction matters because Wenlan is designed around the work loop: brief, capture, recall, handoff, distill, inspect, and keep going.

Use the Claude Code plugin if Claude Code is your main work surface. It gives you /setup, /brief, /capture, /handoff, /distill, and the plugin-level workflow.

Use npx -y wenlan setup when you want Wenlan from Codex, Cursor, Claude Desktop, Gemini CLI, VS Code, or another MCP client.

No. The daemon, CLI, and MCP connector are the product path. The desktop app is optional and lives in the main repository's AGPL-3.0-only app/ crate.

If you only want agents to use Wenlan, install the plugin or runtime setup and verify the MCP route. You do not need a GUI.

Wenlan keeps the daemon database in the operating system's application data directory and keeps readable artifacts under ~/.wenlan.

The core loop is local-first. Optional model or API-key choices can add more language features, but they are explicit configuration decisions.

No. Wenlan uses a local database and index for retrieval, graph context, pages, and daemon state. Markdown artifacts are the human-readable projection, not the whole storage system.

This gives agents fast retrieval while still giving humans files they can inspect, version, back up, and move.

No. wenlan background off stops Wenlan and removes the per-user service registration. It does not delete ~/.wenlan or the daemon data directory.

That separation is intentional because local memory may be the only record of project decisions, handoffs, private preferences, and generated pages.

Run /setup in Claude Code or wenlan doctor from the terminal. Then capture one small durable fact and recall it from the client you plan to use.

If daemon health passes and a capture/recall round trip works, the client is connected to the same Wenlan daemon.