# Desktop CC GUI: one Tauri client for Claude Code, Codex, Gemini and OpenCode

> Desktop CC GUI (ccgui) puts ten command-line AI coding runtimes behind a single graphical interface. The README documents the adapters, the plugin SDK and the LAN bridge; it does not document the licence or a rollback path.

**zhukunpenglinyutong/desktop-cc-gui** — Multi-engine AI coding desktop client (Tauri). Claude Code, Codex, Gemini, OpenCode, DeepSeek Harness and more in one GUI.

- Repository: https://github.com/zhukunpenglinyutong/desktop-cc-gui
- Website: https://www.mossx.ai/download
- Stars: 4,416 · Forks: 402
- Language: TypeScript
- License: not declared
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/zhukunpenglinyutong-desktop-cc-gui

## The problem Desktop CC GUI solves for multi-engine users

Anyone who works across several AI coding runtimes ends up with the same setup: one terminal tab running Claude Code, another running Codex CLI, a third for OpenCode, each with its own session history, its own config file and its own way of showing a diff. The README describes the target user plainly: people who do not want to stare at a black terminal while switching between engines.

The project is a desktop client, not a model or a proxy. It does not host inference and it does not add a credential store of its own. What it adds is a graphical layer over runtimes that already exist on your machine, so the engines keep their own authentication and their own session files. That design choice matters: the README states that provider channels are written to each CLI's native config files, with no parallel credential store. If you have already configured a CLI by hand, ccgui reads and writes the same files rather than asking you to re-enter keys somewhere else.

The scope is wide on purpose. The README lists Claude Code, Codex CLI, Kimi CLI, Grok CLI, Pi CLI, OMP CLI, DeepSeek Harness, Antigravity, OpenCode and Qoder, with global and CN distributions for the last one. Ten engines in one composer is the product.

## How the Rust backend adapts each CLI engine

The README is unusually explicit about the mechanism: every engine is wired in through a dedicated protocol adapter in the Rust backend, and the text stresses that streaming events, session history and provider channels are handled natively rather than scraped off a terminal screen. That distinction is the architectural claim of the project. A terminal scraper has to guess where a tool call begins and ends; a protocol adapter receives structured events.

On the frontend side, the app is Tauri 2 with React 18 and TypeScript, and package.json confirms the stack: @tauri-apps/api, @xterm/xterm with the WebGL addon, CodeMirror packages, react-markdown with rehype plugins, and Zustand for state. Streaming replies are revealed per animation frame with cached syntax highlighting, which the README frames as a way to keep long outputs smooth instead of re-parsing markdown on every token. Thinking traces merge with the reply text, auto-fold when they settle, and expand on demand.

Session history survives restarts. The README says the history scanner reads each CLI's native session files and keeps titles in sync, so the app is a reader of files the CLIs already write. A Run Status Strip mirrors live engine progress, including todo snapshots, and tool calls appear as expandable rows with beautified Git Diff and Bash viewers.

## Installing ccgui and running a first session

The repository does not document an install command for end users. The homepage listed for the project is https://www.mossx.ai/download, and the README points there for builds. The badges in the README list macOS, Windows and Linux as supported platforms, so the download page is the place to look for a package for your system. There is no Homebrew formula, npm package or apt repository described in the README, so do not expect one.

If you want to build from source instead, package.json shows the toolchain: pnpm as the package manager, and a Tauri dev script. The scripts block defines dev as "tauri dev" and build as a TypeScript check followed by a Vite build.

```bash
pnpm install
pnpm dev
```

The first command installs workspace dependencies, including the local @ccgui/plugin-sdk package, which package.json references as workspace:*. The second starts the Tauri development shell. The README says the app runs on macOS, Windows and Linux, so a Rust toolchain and the platform's Tauri prerequisites are implied by the tauri dev script rather than spelled out in the README.

A first real use, based on the README's description: open the app, pick a project directory, then choose an engine from the composer. The README states that the engine is selected per session, and that per-tab model and effort overrides let different tabs in the same window run different models or thinking levels. Before the first prompt, the CLI you selected has to be installed and authenticated on your machine, because ccgui writes provider channels into that CLI's own config files. The README also notes that Claude, Codex and Grok channels can be imported from CC Switch.

## What the README does not tell you before you commit

The licence is the first gap. The repository metadata carries no licence identifier, and nothing in the README states terms of use. For a desktop application that writes to config files outside its own directory, that silence is a real adoption blocker for companies with licence review processes. Treat it as unknown until the repository states otherwise.

The second gap is rollback. The README does not document how to undo a provider-channel change, and since ccgui writes into each CLI's native config files, an overwritten channel is a change to files other tools depend on. Nothing in the README describes a backup step or a restore path. If you manage several CLIs by hand, snapshot those config files before letting the app touch them.

The third is the engine count itself. Ten adapters mean ten upstream CLIs whose flags, session formats and authentication flows can change independently. The README does not describe a compatibility matrix or a minimum supported version for any engine, and the release notes are not included in the README. A single-engine user pays the maintenance cost of that surface without using it.

Finally, the plugin guide is linked as docs/plugin-development-guide.zh-CN.md, a Chinese-language document. The plugin SDK is real, but an English-speaking author has to work from a guide written in another language.

## Desktop CC GUI compared with a terminal or an editor plugin

The honest alternative is the terminal you already have. Claude Code, Codex CLI and the rest are terminal programs; running them directly means no adapter layer between you and the tool, no GUI release cadence to track, and no second process holding your project directory. The cost is exactly what the README complains about: no unified session history across engines, no shared diff viewer, no per-tab model overrides, and no file tree or Git panel beside the chat.

A second alternative is an editor integration, which is what several of the related searches point at: people look for a Claude Code GUI inside VS Code or JetBrains IDEs. The difference in approach is where the interface lives. An editor plugin puts the agent inside the editor you already use for reading and editing code, and inherits its project model. ccgui is a standalone Tauri application that ships its own file tree, its own CodeMirror editor pane, its own PTY-backed terminal and its own Git panel. That is more surface area to learn, and it means the app is a second window next to your editor rather than a panel inside it.

Where ccgui is clearly different from both is the multi-engine composer. A terminal user runs one engine per tab and mentally tracks which is which. The README's claim is that engine choice is per session, with model and effort overrides per tab, and that all of it lands in one history.

## Plugins, LAN access and the maintenance bill

The plugin system is the part most likely to decide adoption for teams. The README describes a first-party SDK published as @ccgui/plugin-sdk, an in-app runtime, a manager UI and a trust boundary. Declarative plugins can add settings sections and config-driven UI without shipping frontend code, and the README states that builtin app surfaces, including the settings page itself, are registered through the same extension points. That is a stronger claim than a hook list: the app's own UI is built on the public mechanism.

Two other features carry operational weight. Proxy settings apply to both app and engine traffic, which matters when the CLI talks to a provider through a corporate network. And LAN web access serves the UI to other devices on your network over a token-authenticated WebSocket bridge, with a QR-code entry in Settings. That is a convenience feature with a security surface: a token-authenticated bridge on a local network is only as good as the token handling, and the README does not describe token rotation or revocation.

On maintenance, the repository is not archived, and the last push was on 2026-09-19. Releases v1.0.3, v1.0.4 and v1.0.5 landed on 2026-09-16, 2026-09-18 and 2026-09-19, while package.json declares version 1.0.6. The upgrade path is the Tauri updater plugin, @tauri-apps/plugin-updater, which appears in the dependency list. The README does not describe a downgrade path, so treat each release as forward-only until the repository says otherwise.

## Who should adopt Desktop CC GUI, and what to verify first

Adopt it if you already run more than one CLI coding agent and the switching cost is the thing slowing you down. The per-tab model and effort overrides and the shared session history are the features a single-engine user cannot benefit from, and they are the reason the multi-engine layer exists. Teams that want to build internal surfaces on top of the client have a documented path through @ccgui/plugin-sdk, with the caveat that the authoring guide is currently the Chinese-language document in docs/.

Do not adopt it if you use one engine, if your organisation requires a stated licence before installing desktop software, or if you need a documented rollback for changes to CLI config files. In those cases the terminal or an editor plugin is the smaller commitment.

Before installing, verify three things. First, the licence, because the repository does not state one. Second, that the specific CLI you plan to drive is installed and authenticated, since ccgui writes to that CLI's native config files rather than storing credentials itself. Third, back up those config files, because the README does not describe an undo for provider-channel changes. The download page is at https://www.mossx.ai/download.

## Conclusion

Adopt Desktop CC GUI if you already run several CLI coding agents and want one window, one session history and one set of provider channels for them; skip it if you depend on a single engine, because the multi-engine layer is the whole product. Before installing, check the licence, since the repository does not state one, and confirm that the CLI you intend to drive is installed and authenticated, because ccgui writes to each CLI's own config files rather than holding credentials itself.

## FAQ

### Do I need the GitHub Desktop app to use Desktop CC GUI?

No. Desktop CC GUI is a standalone Tauri desktop client with its own Git panel for staging, committing and inspecting diffs and history; GitHub Desktop is a separate application and is not mentioned anywhere in the project's documentation.

### What is the best interface for Claude Code?

The README does not rank interfaces. It presents Desktop CC GUI as a graphical client that brings Claude Code and nine other CLI engines into one window, with streaming output, thinking traces, tool calls and Git diffs visible as they happen.

### Is the Claude desktop app worth it?

That question is about Anthropic's own desktop application, not about Desktop CC GUI, so the project's README cannot answer it. Desktop CC GUI is a third-party client that drives the Claude Code CLI alongside other engines.

## Sources

- [Issues](https://github.com/zhukunpenglinyutong/desktop-cc-gui/issues)
- [Project website](https://www.mossx.ai/download)
- [README](https://github.com/zhukunpenglinyutong/desktop-cc-gui/blob/main/README.md)
- [Releases](https://github.com/zhukunpenglinyutong/desktop-cc-gui/releases)
- [zhukunpenglinyutong/desktop-cc-gui on GitHub](https://github.com/zhukunpenglinyutong/desktop-cc-gui)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zhukunpenglinyutong-desktop-cc-gui