desktop-cc-gui puts eleven AI coding CLIs behind one Tauri window

Ten CLIs driven through dedicated Rust protocol adapters

Most AI coding assistants still ship as a terminal program that prints text, asks permission questions inline and holds session state in files you cannot see. ccgui is a Tauri 2 desktop client whose stated job is to put a window around those programs for people who write code all day but do not want to read raw console output.

The claim worth checking is how it talks to them. The README says each engine is wired in through a dedicated protocol adapter in the Rust backend, so streaming events, session history and provider channels are handled natively instead of being scraped off a terminal screen. That distinction decides a lot. A screen scraper has to guess where a prompt ends and a model reply begins, and it inherits whatever ANSI noise the CLI decides to print. A protocol adapter consumes structured events, which is what makes per token streaming, interrupt and a message queue possible on the same window.

The supported list is Claude Code, Codex CLI, Kimi CLI, Grok CLI, Pi CLI, OMP CLI, DeepSeek Harness, Antigravity, OpenCode, Qoder in both global and CN distributions, and MiniMax Code. You pick the engine per session from the composer rather than restarting an app. Settings and state persist locally, and the stack is Tauri 2 with React 18, TypeScript and Rust, shipping for macOS, Windows and Linux.

One detail sits oddly next to the eleven-engine headline. The repository declares a workspace plugin package, `@ccgui/plugin-sdk`, alongside `patches/`, `deploy/` and `packages/` directories, so extension work is a stated part of the layout. The compatibility matrix marks the native `/plugins` command as supported only for OMP.

Provider channels go into each CLI's own config, not a ccgui credential store

Switching an AI coding engine usually means editing a JSON or TOML file by hand, which is why people end up with five accounts and no memory of which key belongs to which tool. ccgui's answer is that provider channels are written into each CLI's own native config files, with no parallel credential store alongside them.

That is a real architectural commitment and it has a real cost. Because ccgui edits the config of a tool it does not own, it inherits whatever version of that config the CLI expects. Presets are offered for GLM, Kimi, DeepSeek, MiniMax, MiMo, Bailian, LongCat, OpenCode Go, OpenRouter and Requesty, and Claude, Codex and Grok channels can be imported from CC Switch. The importer covers three engines. For Kimi, Pi, OMP, DSH, Antigravity, OpenCode, Qoder and MiniMax Code, the matrix row for CC Switch import is a cross, so those users write their own channel configuration.

The privacy line in the README is narrower than it first looks: content sent to an AI provider follows the boundary of the channel you configured for that CLI. The boundary is the channel, not the app. Whatever provider you pointed the CLI at receives what you send it, and ccgui's role ends at writing that configuration correctly.

Running from source with pnpm dev and the macOS build scripts

The README points to the project homepage at mossx.ai/download for packaged builds. For source work, the repository is a pnpm workspace pinned to pnpm 10.29.3, and every entry point lives in the root package.json scripts.

Start the desktop client in development mode. The dev script runs the Vite frontend and the Tauri shell together:

tauri dev

You need the Rust toolchain and the platform prerequisites Tauri expects on your machine. Two mac specific scripts exist for producing a signed build, and the second sets SKIP_NOTARIZE to 1, which is the one to use while iterating locally:

./scripts/build-signed-macos.sh

SKIP_NOTARIZE=1 ./scripts/build-signed-macos.sh

The production build type checks before it bundles, so a type error fails the build rather than shipping:

tsc --noEmit && vite build

The test script runs Node's built-in test runner over `tests/*.test.ts` and then vitest:

vitest run

For first use, the sequence is short. Launch the app, pick a project directory, choose an engine from the composer, and configure a provider channel in Settings before your first message. Because the app drives installed binaries, a CLI that is not on PATH will not work regardless of how the channel is set. One more constraint belongs here: the desktop client targets all three of macOS, Windows and Linux, but the two build scripts above are macOS only.

The compatibility matrix is narrower than the ten engine headline

The README carries a per feature matrix across all eleven engines, and it is the most useful page in the project. It is also where the marketing outruns the software.

Streaming output is marked unsupported for Kimi CLI while being supported everywhere else. Image attachments are unsupported for Antigravity. Reasoning effort, which maps directly to the thinking level controls that modern coding models expose, is unsupported for Kimi, Grok, DSH and OpenCode and only partial for Antigravity and MiniMax Code. Token usage and context window reporting is partial for OpenCode. Todo list rendering works only for Claude Code, Pi and OMP.

Two rows deserve closer reading. Provider and channel switching is partial for Pi, OMP, DSH, Antigravity, OpenCode and Qoder and unsupported for MiniMax Code, so the channel feature that ccgui is built around works fully for only 4 of the 11 engines. And team mode, multi agent orchestration, is marked unsupported for every engine in the table: 11 crosses in a single row. Sub agent display is partial for Antigravity, OpenCode and Qoder and unsupported for Grok and MiniMax Code, leaving 6 engines with full support.

Provider channel switching being partial for six engines is the row that would make me pause before switching a working setup. The feature is the app's reason for existing and it is uneven across most of the list.

WSL workspaces lose Kimi question cards and plan mode

The README describes Kimi question cards in unusual detail, which tells you they were hard to build. They run over the local Kimi CLI's ACP form channel, were verified with Kimi 2.0.2, and cover multiple questions, multiple selections, dismissal and interruption.

The same paragraph states two limits that a skim would miss. Kimi currently accepts declared options only, so the cards cannot offer a free text Other answer. And WSL workspaces keep the non interactive CLI fallback, which means they support neither Kimi question cards nor plan mode. ccgui detects a WSL workspace and degrades the interactive surface rather than failing.

That degradation is the correct call, and it comes with a rule that explains why prompt mode launches never add incompatible interactive permission flags. When the environment cannot support interactive permission prompts, ccgui launches without them instead of passing flags the target CLI will reject. The same reasoning sits behind the permission mode column, where Grok and Qoder are bypass only, DSH and Pi are auto only, and Claude Code and MiniMax Code get the widest set: auto, manual, plan and bypass.

Plan mode existing at all is notable. It is a per engine feature, not an app setting, so a capability you rely on can vanish when you switch engines for a task.

Sessions live in the CLIs' own files and are read back by a scanner

Session history and resume are marked supported for all eleven engines, which is the one row with no cross anywhere. Session rename and the native `/new` and `/clear` commands are also supported across the board.

Context compaction via `/compact` is full for 2 engines (Claude Code and OMP) and partial for the other nine.

Around this core, streaming output, thinking traces and tool calls are visible as they happen, and token usage appears when the engine reports it.

Where ccgui differs from driving the CLI in a terminal

The honest comparison is not against another GUI. It is against the terminal, because ccgui does not replace the thing it wraps.

A terminal gives you the CLI's full surface, including anything ccgui has not wired: raw flags, shell composability, piping, tmux, and features the compatibility matrix does not list. ccgui gives you structure the terminal does not: a dispatch panel for sub agents where the engine supports one, and fast mode (service tier) for Codex and OMP.

Against a single engine, this is a layer rather than a competitor. It wins on readability of long agent runs and loses on reach. That is a fair trade for most people and a bad one for anyone who pipes CLI output into their own scripts.

The repository is licensed under MIT. The root package.json sits at version 1.2.2 while the most recent tagged release is v1.2.1 dated 2026-11-02, so pin to a tag rather than tracking main.

Editorial conclusion

Adopt ccgui if you already run at least two of these CLIs daily and want one chat surface with streaming output, session history and a model picker. Skip it if your workflow depends on team mode, which the compatibility matrix marks unsupported for every engine, or on Kimi per token streaming, which is marked unsupported. Before switching, open the engine you care about on the compatibility matrix and confirm your two or three most used features are full checkmarks, then confirm the CLI itself is installed and on PATH, since ccgui drives the binaries rather than replacing them.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. zhukunpenglinyutong/desktop-cc-gui on GitHub