Waku: a GPUI desktop client that wraps nine coding agent CLIs behind one daemon
⚡ A native app for all your coding agents.
At a glance
- What is it?
- Waku is a Rust desktop app that drives local coding agent CLIs through a standalone daemon and a versioned WebSocket protocol. It is a client and session manager, not an agent, and its split architecture is the most interesting and most constraining thing about it.
- Who is it for?
- Adopt Waku if you already run several agent CLIs locally and want one native window for sessions, transcripts and Git-backed checkpoints, and if you accept GPL-3.0 and a 0.1.x release cadence. Skip it if you need a browser-only workflow, if your agents live on a remote host you want to drive from a laptop, or if you cannot install a supported CLI first, because Waku detects CLIs rather than shipping them.
- 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 September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Waku is a front end for CLIs you already installed
The README is explicit that Waku does not ship an agent. It works with Amp, Claude Code, Codex CLI, Cursor CLI, Fx, Grok Build, Kimi Code, OpenCode and Pi, and it says to install and authenticate at least one supported agent CLI before starting Waku. Detection is automatic, and the app then speaks each provider's native structured protocol and session continuity rather than scraping terminal output. That distinction matters. A wrapper that parses stdout has to guess when a turn ended; a client that speaks the provider's own protocol gets structured events and can resume a session the way the provider intends. The audience is therefore narrow and specific: developers who already pay for or run one or more of these CLIs and are tired of juggling terminal tabs, session files and model flags across them. If you use exactly one agent and never switch models, the coordination layer buys you little.
The desktop is an RPC client, and the daemon owns the state
The architecture section describes a split that is unusual for a desktop app. The native desktop is an RPC client of a standalone waku-daemon process. Provider sessions run in waku-core, behind an authenticated, versioned WebSocket contract defined in waku-protocol. Waku Desktop depends on waku-client, not on the daemon implementation, which is what makes a second client possible at all. The daemon owns task SQLite data, uploaded attachments, provider-native session forks, and all workspace filesystem and Git operations. Paths returned by the daemon always refer to the daemon host. The desktop keeps only presentation state and a disposable preview cache. Two consequences follow. First, the daemon is the thing to back up and the thing to secure, because it holds the SQLite task data and the attachments. Second, the desktop is disposable in a way desktop apps usually are not. The browser client in apps/web uses the generated transport in packages/waku-client and reimplements the same handshake, request IDs, subscriptions, sequence deduplication and replay cursors as the Rust client. That is a real second implementation, not a thin shim, and it is the strongest evidence that the protocol boundary is taken seriously.
Install commands, config files and the paths that move
On macOS the README points to a signed .dmg at waku.sh that updates itself. On Linux the documented command is curl -fsSL https://waku.sh/install.sh | sh, which installs into ~/.local without root, with docs/linux.md covering requirements, manual installation and uninstalling. On Windows you run Waku-<version>-<arch>-Setup.exe from the latest release; it installs per-user, updates itself, and a portable .zip ships alongside it, with docs/windows.md listing requirements and what is not available yet. Configuration ownership is deliberately split. The Release desktop writes ~/.waku/app.json while Debug stays isolated at temp/app.json, and daemon provider and Computer Use settings live in ~/.waku/settings.json. Projectless task workspaces live on the daemon host under ~/.waku/projects/<date>/<slug>, and the daemon moves workspaces created by the older ~/.waku/<date>/<slug> layout on first load. That migration is worth knowing about before an upgrade, because it rewrites where your work sits on disk. The desktop's Settings, Daemon page can expose the child daemon on a fixed port, configure exact browser origins, and copy its stable authentication token; it stays loopback-only by default. For development, Rust 1.96 or newer and Bun are required, and the flow is bun install then bun run dev. After changing a wire type, run bun run protocol:generate, and bun run protocol:check to verify the generated files are current.
Remote daemons lose the folder picker and the PTY
The README states a limitation plainly, and it is the one to weigh hardest. When connected to a daemon managed outside the desktop process, Waku never interprets daemon paths on the client machine. The local folder picker and PTY are therefore unavailable until the protocol gains daemon-host picker and terminal-stream endpoints. Files, diffs, Git, skills, usage, task state and attachments already work over daemon RPC, so the gap is narrow but sharp: you can browse and edit through RPC, yet you cannot open a native folder dialog or a terminal tied to the daemon host. If your mental model of Waku is a laptop client for a beefy remote box, the current protocol does not fully support that model. Platform coverage is uneven in the same way. Development is supported on macOS, Linux and Windows, with Wayland and X11 on Linux and the MSVC toolchain on Windows, but the embedded browser and the experimental computer-use integration remain macOS-only. Agent sessions, projects, transcripts, skills, usage, diffs, file editing and the terminal do run natively on Linux and Windows, so the macOS-only parts are the auxiliary surfaces rather than the core loop. Still, if the embedded browser is the feature you came for, Linux and Windows are the wrong choice today.
Release bundling versus the debug daemon swap
Release apps bundle and sign waku-daemon. Development keeps the daemon at target/debug/waku-debug-daemon, which lets provider-only edits rebuild and replace the daemon without relaunching Waku Debug. That is a thoughtful split for anyone working on provider integration, because the desktop process is the slow thing to rebuild and the daemon is the part that changes when you touch an agent adapter. It also means the debug and release paths diverge in ways that can surprise you: the config files differ (temp/app.json against ~/.waku/app.json), and the daemon binary path differs. Versioning is at 0.1.19 as of the most recent release listed, with 0.1.18 and 0.1.17 landing within roughly three weeks of each other. That cadence is normal for pre-1.0 work and it is the practical reason to read release notes before upgrading rather than after, particularly because of the workspace path migration described above.
How Waku differs from a terminal multiplexer or a hosted agent IDE
The closest thing most readers already use is tmux or a terminal split running several agent CLIs side by side. The difference is in what gets shared. A multiplexer shares a screen; each pane still has its own session state, its own model flags, and no common view of which task belongs to which project. Waku's stated highlights are the opposite: keep projects and independent agent sessions in one native app, switch models, reasoning effort and access modes from a shared interface, queue or steer follow-up messages while an agent is working, and rewind Git-backed tasks with conversation-aware checkpoints. The checkpoint feature is the one with no multiplexer equivalent, because it ties a Git state to a point in a conversation rather than to a commit message. The other end of the spectrum is a hosted agent IDE, where the agent runs on someone else's machine and your code goes with it. Waku inverts that: app state is stored locally, and the README says no Waku account or remote service is required. The trade is that you supply the compute, the CLI installs and the authentication, and you inherit the maintenance of all three.
Licence and the cost of keeping up
Waku is licensed under the GNU General Public License v3.0 only, per the LICENSE file and the README. That is a copyleft licence, and it matters most if you intend to redistribute a modified build or link it into a product; the usual caveat applies that this is a description of the licence, not legal advice, and anyone with redistribution plans should read the licence text and take their own counsel. For internal use the practical effect is small. The ongoing cost is elsewhere. Waku sits between your machine and nine external CLIs, each of which changes on its own schedule, and the project's answer is the versioned protocol in waku-protocol plus generated browser types checked by bun run protocol:check. That design contains breakage to the protocol boundary, but it does not eliminate the work of tracking provider changes. Budget for periodic upgrades, read the release notes for the workspace path migration, and treat the daemon as the component whose state you would miss if it were lost.
Editorial conclusion
Adopt Waku if you already run several agent CLIs locally and want one native window for sessions, transcripts and Git-backed checkpoints, and if you accept GPL-3.0 and a 0.1.x release cadence. Skip it if you need a browser-only workflow, if your agents live on a remote host you want to drive from a laptop, or if you cannot install a supported CLI first, because Waku detects CLIs rather than shipping them. Verify three things before you commit: that your target OS is covered by the platform notes in docs/linux.md or docs/windows.md, that the agent CLI you rely on is on the supported list, and whether the daemon-host picker and terminal-stream endpoints exist yet in waku-protocol, since without them a remote daemon leaves the folder picker and PTY unavailable.
Community notes