NapCatQQ Desktop puts a QQ bot console in a Rust and Tauri window
NapCatQQ&Snowluma 的 Desktop 程序
At a glance
- What is it?
- NapCatQQ Desktop is a Windows control panel for running NapCatQQ and SnowLuma bot instances, written in Rust with Tauri 2 and a React and TypeScript interface, covering local and remote deployment, chat, native screenshots, an embedded terminal and a OneBot debugging console. It suits an operator who wants to run bots without a command line, and it is Windows x64 only.
- Who is it for?
- Adopt NapCatQQ Desktop if you run NapCatQQ or SnowLuma instances and want deployment, login, chat and debugging in one window instead of a set of scripts and log files. Do not adopt it if you need Linux desktop support or a Docker bot on the local machine, since neither is in scope.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A control panel for two bot backends
NapCatQQ Desktop is the Windows desktop console for NapCatQQ and SnowLuma, and its stated purpose is to cover deploying the bot, connecting applications, and then chat, screenshots and debugging in a single window. The first feature group is the deployment and management side. It manages both protocol backends, showing run status, login status and logs, and editing the OneBot connection. It runs natively on the local Windows machine, and it manages a remote Linux host over SSH, supporting both native execution and Docker deployment there. A support table makes the coverage explicit, and the shape of it is a good summary of the project. Native Windows local and native Linux remote and Docker Linux remote are all supported for both backends, while local Docker and remote Windows are not in the current supported range, and the README says the desktop client currently targets Windows x64 while Docker deployment targets remote Linux hosts. There is also a component installation path, where the interface installs and updates the runtime and the framework, shows dependency and task progress, and lets you install a separate copy of QQ to reduce the impact on the system QQ you use daily.
Monitoring that survives the window closing
The run monitoring section is the one that changes the operational picture. You can see host CPU, memory and disk along with bot metrics, configure automatic restart and disconnection notifications, and for a remote host install a separate watcher component, ncd-watch, that keeps watch after the Desktop application itself has exited. That is the detail worth understanding. A console that supervises a remote bot is only supervising it while the console runs, so the part that actually has to stay alive is pushed into a small separate agent on the remote host, and the README notes that a release name carrying watch-v is the remote monitoring component, that you install it by choosing the remote host on the components page, and that updating the Desktop does not automatically replace the remote ncd-watch. It is a common pattern in this kind of tool and an easy one to get wrong, and the documentation is explicit about it.
Application frameworks, and a capability matrix instead of a promise
The application side manages instances of chat frameworks, and the table of frameworks is more informative than a feature list would be. Karin, NoneBot2, AstrBot, MaiBot, Kooshi, TRSS-Yunzai and NeoBot are all supported, and the desktop offers different depth of management for each. Karin gets configuration editing, plugin management and OneBot connection. NoneBot2 gets adapters, a plugin store and connection configuration. AstrBot gets model providers, persona, knowledge base, session and plugin configuration. MaiBot gets deep configuration, models, prompts, learning data and a trial chat. Koishi gets configuration forms, a plugin tree and connection management. TRSS-Yunzai gets instances, configuration and OneBot connection. And NeoBot gets model, prompt, memory, plugin, runtime and usage panels. The README is careful that the configuration and runtime panels follow each framework's capabilities, that some operations need the instance running and able to reach its web interface, and that one-shot application connection does not currently support Docker bots. Framing the depth of support per framework rather than claiming parity is the honest way to publish this kind of matrix, and it tells a user exactly what they will find when they open a given panel.
Chat, native screenshots and the embedded terminal
The everyday features are grouped into four areas. Private and group chat is per bot, with contacts and messages managed separately, friend grouping, a group message box, pinning, unread filtering and search of chat history. Message operations cover reply, at, recalling your own messages, forwarding individually or merged, retry on failure, and dragging or pasting images and files into the input box. Media and group files cover images, voice, video, Markdown and forwarded records, with group file browsing, upload and download and directory management where permissions allow. Native screenshots are bound to a modifier key combination by default, with region selection, annotation, undo and redo, copy, save and a bidirectional scrolling long capture, and a screenshot can be dropped into a chat draft or set to copy only so the chat window does not open. The embedded terminal is available for the local machine, remote hosts, bots and application instances, with tabs, split panes and a file bar, and the debug console for OneBot searches interfaces, edits parameters as a form or as JSON, shows responses and live events, and keeps a request history with favourites. Configuration backup exports and imports a zip covering bots, servers, application instances, framework configuration and interface preferences, validated and backed up before an import.
Requirements, and the data root is a separate decision
The requirements table is specific. The operating system is Windows 10 or 11 on x64, or Windows Server 2016 and later. The interface runtime is the Microsoft Edge WebView2, and the installer handles installing it when it is missing. The embedded terminal needs Windows 10 1809 or Server 2019 and later on the local machine. Remote management needs a Linux host reachable over SSH, and Docker deployment on that host also needs a Docker environment. The download is an MSI named with the version and x64, and there is also a versionless file with the same content. The program and its data are stored separately, with the default data root at %ProgramData%\NapCatQQ Desktop and the option to migrate it from the settings. The interface language and other preferences live in the settings, and the theme, sidebar style, tray, lightweight mode and in-app update are all desktop options. The screenshot in the README is a browser preview using demonstration data, and the README is explicit that the actual features depend on the protocol end version, the account permissions and the environment.
Building it, and the shape of the Rust workspace
The development stack is Rust with Tauri 2, React and TypeScript, with Tailwind CSS and Radix UI for the interface, and the local development sequence is four commands:
git clone https://github.com/NapNeko/NapCatQQ-Desktop.git
cd NapCatQQ-Desktop
pnpm.cmd install --frozen-lockfile
pnpm.cmd run tauri:devYou can also run the interface alone with the dev script, which opens on a local port, and the README warns that the browser preview uses demonstration data while a real bot, SSH, native screenshots and the terminal have to be verified inside the Tauri application. The Cargo workspace is where the structure is visible. It holds the Tauri shell, then a set of domain crates for traits, host, network, component, app framework, deployment, update, runtime, server, config, log, test support and template, and then the backend crates for SnowLuma and NapCat, the remote watcher, OneBot, a relogin helper, an MCP piece and an agent. The lints are strict in a way that reveals the project's values, with unsafe code warned, and unwrap, expect and panic warned in production paths, the comment saying error handling must use the question mark operator with context and that test code is exempted separately. Debug macros, todo, and direct stdout printing are warned too, the reasoning being that a GUI application should log rather than print.
Editorial conclusion
Adopt NapCatQQ Desktop if you run NapCatQQ or SnowLuma instances and want deployment, login, chat and debugging in one window instead of a set of scripts and log files. Do not adopt it if you need Linux desktop support or a Docker bot on the local machine, since neither is in scope. Verify first which protocol backend version you are running, since the actual features depend on the protocol end version, the account permissions and the environment, and that your Windows machine meets the WebView2 and terminal requirements before you install the MSI.
Frequently asked questions
What does NapCatQQ Desktop actually do?
It is the Windows desktop console for NapCatQQ and SnowLuma, covering deployment of the bot, connection to applications, chat, screenshots and debugging in one window. It manages local and remote instances, shows run status, login status and logs, and edits the OneBot connection.
Which platforms does NapCatQQ Desktop support?
The desktop client currently targets Windows x64. Native local Windows, native remote Linux and Docker on remote Linux are all supported for both backends, while local Docker and remote Windows are not in the current supported range. The requirements are Windows 10 or 11 x64, or Windows Server 2016 and later, plus the Edge WebView2 runtime.
Can NapCatQQ Desktop keep a remote bot alive after the console closes?
Yes, through a separate remote monitoring component, ncd-watch, which you install on the remote host from the components page and which continues watch after the Desktop application exits. Updating the Desktop does not automatically replace the remote ncd-watch, so it has to be updated on the host itself.
What does the configuration backup in NapCatQQ Desktop include?
It exports and imports a zip covering bots, servers, application instances, framework configuration and interface preferences, and the import validates and backs up the existing configuration first. The archive does not include the component programs, plugin programs, databases, chat message records or credentials stored in the system key store, so a migration to another machine still needs the runtime installed and the paths checked.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/napneko-napcatqq-desktop)Was this useful?