FAQ

Wenlan includes memory, but the product goal is broader than generic memory. It is a local memory layer for AI work so agents can carry decisions, context, handoffs, and source-backed pages 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 /init, /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 a separate repository.

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 uninstall 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 /init 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, Wenlan is connected to the local memory layer.