ChatClaw: a Go desktop agent that puts your knowledge base behind WeChat, Slack and Telegram

The gap ChatClaw is aiming at: an agent that lives where your messages already are

Most local AI assistant projects stop at a chat window. You install them, upload a few PDFs, ask questions, and then close the window and go back to WeChat or Slack where the actual work conversation happens. ChatClaw's premise is that the assistant should be reachable from those applications instead. The README lists WhatsApp, Telegram, Slack, Discord, Gmail, DingTalk, WeChat Work, QQ and Feishu as supported channels, and describes the flow as sending an instruction in a chat window to remotely drive the agent, with results pushed back to a chosen channel rather than polled. That is a different product shape from a document Q&A tool. It is closer to a personal automation daemon with a chat front end.

The target user is not a platform engineer. The README is explicit that no programming is required and that deployment is one click to a local machine, and the description puts the installer at roughly 30MB with a one-minute install. The bundled pieces (knowledge base, memory, skill market, scheduled tasks, MCP) are the feature set you would otherwise assemble from four or five separate tools. Whether the bundling is a strength or a liability depends on how much you trust a single binary to do all of it, which is the question the rest of this piece tries to answer.

What actually runs: Wails v3 shell, Go backend, SQLite with sqlite-vec

The technology table in the README is unusually specific, and it explains most of the product's behaviour. The desktop shell is Wails v3, which pairs a Go backend with the operating system's WebView rather than shipping a Chromium runtime. That is the reason a 30MB installer is plausible at all. The backend is Go 1.26, the frontend is Vue 3 with TypeScript, shadcn-vue and Tailwind CSS v4, and state lives in Pinia. The agent framework is Eino, ByteDance's CloudWeGo project, and model providers listed include OpenAI, Claude, Gemini, Ollama, DeepSeek, Doubao, Qwen, Zhipu and Grok.

The storage choice is the most consequential detail. ChatClaw uses SQLite plus sqlite-vec for vector retrieval. There is no separate vector database to install, no Postgres with pgvector, no external embedding service implied by the stack table. Documents are parsed, split and converted into embeddings that go into a local store, and the README states the knowledge base supports folder and document classification. For a single-user desktop agent this is the right call: one file, no daemon, trivial backup. It also sets a ceiling. sqlite-vec is a SQLite extension, so retrieval performance and index type are bounded by what that extension offers, and the README does not describe index configuration, embedding model choice, chunk size or re-embedding behaviour when you change models. Those are the parameters that determine whether RAG quality is usable or frustrating, and they are not documented in the material available.

The frontend layout shows the multi-window design rather than describing it: index.html for the main window, floatingball.html for the desktop orb, selection.html for the text-selection popup, and winsnap.html for the sidebar that docks beside other application windows. Four separate webview entry points in one binary is a real architectural commitment, and it is why the app can offer select-text-to-ask and a persistent sidebar without those being separate processes.

Getting it running: server mode, Docker and the two environment variables that matter

The README documents a server mode that skips the desktop GUI entirely and serves the interface over HTTP. Two binaries are listed for direct execution, ChatClaw-server-linux-amd64 and ChatClaw-server-linux-arm64, and the sequence is to make the file executable and run it:

chmod +x ChatClaw-server-linux-amd64 ./ChatClaw-server-linux-amd64

The service listens on 0.0.0.0:8080 by default, and the README shows two environment variables for changing that: WAILS_SERVER_HOST and WAILS_SERVER_PORT. The documented example binds to loopback on port 3000:

WAILS_SERVER_HOST=127.0.0.1 WAILS_SERVER_PORT=3000 ./ChatClaw-server-linux-amd64

Note the default. Binding to 0.0.0.0 means the interface is reachable from the network unless you override it, and the README does not describe authentication in the server-mode section. If you deploy this on anything with a routable address, setting WAILS_SERVER_HOST=127.0.0.1 or putting it behind a reverse proxy that terminates auth is the first thing to do, not an afterthought.

The container path is straightforward. The image is published to a regional registry rather than Docker Hub:

docker run -d --name chatclaw-server -p 8080:8080 -v chatclaw-data:/root/.config/chatclaw registry.cn-hangzhou.aliyuncs.com/chatwiki/chatclaw:latest

The volume mount points at /root/.config/chatclaw, which is where the application state and presumably the SQLite database live, so that path is the one to back up. A Compose file is also given, with the same image, the same port mapping, restart: unless-stopped and a named volume chatclaw-data. The README notes that data persists in that volume and that docker compose down stops the service. For anyone evaluating this in a lab, the container route is the fastest way to see the interface without touching a desktop.

The ChatWiki dependency and the free-model path

One feature deserves separate treatment because it shapes the adoption decision. The README describes a free model trial that works by authorising ChatWiki in one click and syncing ChatWiki account credits, alongside support for custom models including Ollama and Google Gemini. That is a vendor-hosted path sitting inside an otherwise local application. It is convenient, and it is also the part of the product most likely to change terms, rate-limit, or disappear, because it depends on a service outside the repository.

The self-hosted alternative is clearly available: Ollama is listed among the model providers, and the README says custom models are supported. So the honest reading is that ChatClaw can be run without the vendor's credits, but the default onboarding experience points at them. If your reason for choosing a local agent is data residency, decide up front which path you are on and configure a local or self-managed endpoint before you upload anything sensitive into the knowledge base. The README does not spell out what, if anything, leaves the machine when the ChatWiki path is used, and that is a question to resolve from the application's own settings rather than from the README.

Skills, scheduled tasks and the sandbox claim

The README advertises 5000+ ready-to-use skills in a skill market, covering office productivity, developer tools, media creation and smart home scenarios, and says the agent can be instructed to find already-installed capabilities or install new extensions. There is also a scheduled task system with a graphical scheduler plus cron expressions, described for use cases like scraping a page on a fixed interval, comparing changes and pushing an alert through a message channel when something moves.

This is the part where the description does the most work and the documentation does the least. The word sandbox appears in the project description and the tagline, but the README does not explain the isolation model: whether skills run in a separate process, what filesystem and network access they have, whether installation involves code execution on the host, or how a skill is reviewed before it is listed. For a desktop application that can read local documents and reach out to messaging platforms, that gap matters more than any feature bullet. Treat the skill market as an extension mechanism that runs third-party code until you have verified otherwise, and treat the scheduled task feature as something to point at non-sensitive sources during evaluation.

The multi-agent feature is more self-contained and easier to reason about. The README describes creating multiple independent agents, each with its own role, memory, skills, knowledge base and reply style, switchable from the interface, with examples like a customer service specialist, a data analyst and a copywriting assistant. Because each agent carries its own knowledge base binding, this is a reasonable way to keep unrelated document sets from bleeding into each other's answers. It is also a configuration surface that grows quickly: every agent multiplies the number of model settings, channel bindings and scheduled tasks you have to keep straight.

Where ChatClaw is the wrong tool, and what to use instead

The clearest limitation is platform coverage. The desktop installers are described for macOS and Windows, with the project structure showing build directories for darwin, windows, linux, ios and android, and packaging notes for NSIS and MSIX on Windows and AppImage and nfpm on Linux. But the only Linux artifacts named in the server-mode section are the two server binaries. If your requirement is a packaged Linux desktop application, the material here does not confirm one exists, and you should check the releases page rather than assume.

A second limitation is the operating model itself. ChatClaw is a per-user application with a local SQLite store. That is a poor fit for a team that wants one shared index over a document set that changes hourly, with permissions per document and an audit trail of who asked what. There is no mention of multi-user accounts, role separation or access control in the README. Server mode makes the interface reachable over HTTP, which is not the same as making it multi-tenant.

For that shared-index case, the honest alternative is a retrieval server you operate yourself. Something like a vector database plus a thin service in front of it, or a self-hosted RAG platform, gives you central ingestion, per-document permissions and a place to put logs. The difference in approach is not a feature checklist, it is where the state lives: ChatClaw keeps the index in one user's SQLite file and reaches out to chat platforms, while a shared RAG service keeps the index on a server and expects clients to come to it. If your documents are personal or team-shared-but-small, ChatClaw's model is simpler and cheaper. If they are organisational, it is the wrong shape, and no amount of channel connectors fixes that.

Licence, upgrade cost and what to check before you commit

ChatClaw is GPL-3.0. For individual use that is a non-issue. If you plan to embed it in a product, ship a modified build, or link it into a proprietary application, the copyleft terms apply to distribution and you should read the licence text and take your own advice rather than mine. The repository is not archived, the default branch is main, and the two most recent releases listed are v0.9.7 on 2026-05-13 and v0.9.6 on 2026-04-24, roughly three weeks apart. That cadence suggests active development, and it also means the version you install today will be superseded quickly.

Upgrade cost depends on how you deployed it. The Docker path is a pull and a restart against the same chatclaw-data volume, which is cheap, provided the schema migrations between versions are handled by the application. The desktop path means reinstalling on each machine, and the server binary path means replacing a file and restarting, with the same caveat about whatever lives under /root/.config/chatclaw. Back up that directory, or the corresponding volume, before every upgrade, and pin a specific image tag rather than :latest if you care about reproducing a working state.

The version number is the last thing worth noting. At v0.9.x this is pre-1.0 software with a broad feature surface, and the README documents the deployment mechanics far better than it documents the retrieval pipeline or the skill sandbox. Check those two areas in the running application before you put anything you would not want indexed into its knowledge base.

Editorial conclusion

Adopt ChatClaw if you want a local-first assistant that reads your own documents and answers inside the chat apps your team already uses, and if GPL-3.0 is acceptable for how you plan to distribute anything built on it. Do not adopt it if you need a headless Linux service only, because the desktop application is the primary target and the Linux artifacts listed in the README are server binaries rather than a packaged GUI. Before committing, verify three things on your own machine: whether the channel you actually need (WeChat Work and DingTalk are the ones most likely to have platform-side restrictions) can be authorised at all, whether the free model path through ChatWiki is something you are willing to depend on or whether you will point it at your own OpenAI or Ollama endpoint, and whether the skill market installs code you are prepared to run, since skills are described as extensions the agent can install on request.

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. zhimaAi/ChatClaw on GitHub