Waku Coding Agent Desktop

Manage local projects and multiple coding-agent sessions from one native desktop app.

Source repo
egoist/waku
Stars
★ 1.6k
Last updated
16d ago
License
GPL-3.0
Primary language
Rust

At a glance

How it runs
Desktop appCLI
Works with
Universal · cross-platformCodex · Claude Code
Cost
Free software; you pay for model usage
Setup effort
Medium · a few setup steps
You'll need
At least one installed and authenticated supported agent CLIRust 1.96 or newer and Bun for developmentMSVC toolchain for Windows developmentShell / CLINetwork accessLocal filesystem
Typical use
A developer who uses Claude Code, Codex CLI, or several other supported CLIs and wants to manage their projects and separate sessions in one interface.
Not a fit if
  • Users who need an agent out of the box: Waku ships none and requires a separately installed, authenticated CLI.
  • Linux and Windows users who need the embedded browser or Computer Use: both are macOS-only today.
  • Teams wanting zero-config browser access: exposing it requires manual fixed-port, exact-origin, and token setup.
Source review
69/100 · Some gaps

What does this agent do, and when should you use it?

Waku is a native Rust and GPUI desktop application that provides one interface for locally installed coding-agent CLIs. It supports Amp, Claude Code, Codex CLI, Cursor CLI, Fx, Grok Build, Kimi Code, OpenCode, and Pi, preserving each provider's structured protocol and session continuity. The desktop is an RPC client for the standalone waku-daemon; provider sessions run in waku-core behind the authenticated, versioned WebSocket contract defined by waku-protocol. The daemon owns task SQLite data, attachments, provider-native session forks, and workspace filesystem and Git operations, while the desktop retains presentation state and a disposable preview cache. Projects, sessions, transcripts, and application state remain local without requiring a Waku account or remote Waku service, and an apps/web browser client is also included. Core functionality runs on macOS, Linux, and Windows, although the embedded browser and experimental Computer Use integration are currently macOS-only.

Waku detects installed supported agent CLIs and creates or resumes sessions through each provider's native structured protocol. Users organize projects and independent sessions, choose models, reasoning effort, and access modes, and queue or steer follow-up messages while work is in progress. waku-daemon runs provider sessions through waku-core, stores task SQLite records and uploaded attachments, and performs workspace operations involving files, diffs, editing, Git, skills, usage, and task state. For Git-backed tasks, it can create conversation-aware checkpoints and rewind work. The desktop communicates through waku-client over the authenticated, versioned WebSocket RPC contract; apps/web uses the generated browser transport in packages/waku-client, whose checked-in types come from the Rust protocol.

  1. A developer who uses Claude Code, Codex CLI, or several other supported CLIs and wants to manage their projects and separate sessions in one interface.
  2. An engineer who needs to queue another request or redirect an agent before its current operation has finished.
  3. A developer working in Git repositories who wants conversation-aware checkpoints for rewinding task changes.
  4. An individual or team that wants project data, task records, attachments, and transcripts kept on its own machine without creating a Waku account.
  5. A user who wants a desktop or browser client connected to a standalone daemon while filesystem and Git operations remain on the daemon host.
  6. A Linux or Windows developer who needs native sessions, file editing, diffs, terminal access, and usage reporting without relying on the macOS-only Computer Use integration.

How do you install or deploy this agent?

First install and authenticate at least one supported agent CLI. On macOS, download the signed .dmg from https://waku.sh; the application updates itself. On Linux, run curl -fsSL https://waku.sh/install.sh | sh; it installs under ~/.local without root access. On Windows, run Waku-<version>-<arch>-Setup.exe from the latest GitHub release for a per-user, self-updating installation, or use the portable .zip published alongside it. Source development requires Rust 1.96 or newer and Bun, plus the MSVC toolchain on Windows; then run bun install followed by bun run dev.

How do you use this agent?

Install and authenticate at least one of Amp, Claude Code, Codex CLI, Cursor CLI, Fx, Grok Build, Kimi Code, OpenCode, or Pi, then start Waku. It detects available CLIs automatically. Open or add a project, create an independent agent session, and select the model, reasoning effort, and access mode from the shared interface. Queue or send steering messages while an agent runs, and use conversation-aware checkpoints to rewind Git-backed tasks. Projectless workspaces are created by the daemon under ~/.waku/projects/<date>/<slug>. For browser access, use Settings → Daemon to expose a fixed port, configure exact browser origins, and copy the stable authentication token; the daemon remains loopback-only by default.

What are this agent's strengths and limitations?

Pros
  • It explicitly supports nine coding-agent CLIs while retaining provider-native structured protocols and session continuity.
  • The local daemon owns task data, attachments, projects, and transcripts, with no Waku account or Waku-hosted service required.
  • The desktop, daemon, session core, and versioned WebSocket protocol have distinct responsibilities, and a browser client implements the same protocol semantics.
  • It supports in-progress message queuing and steering as well as conversation-aware rollback for Git-backed work.
  • Core agent, project, editing, diff, terminal, and usage features run natively across macOS, Linux, and Windows.
Limitations
  • Waku does not supply an agent by itself; adopters must separately install and authenticate at least one supported CLI.
  • The embedded browser and experimental Computer Use integration are currently unavailable on Linux and Windows.
  • When the daemon is managed outside the desktop process, the local folder picker and PTY are unavailable until daemon-host picker and terminal-stream protocol endpoints exist.
  • Building from source requires Rust 1.96 or newer and Bun, with an additional MSVC toolchain requirement on Windows.
  • Browser exposure requires manual fixed-port, exact-origin, and authentication-token configuration, while the daemon is loopback-only by default.

How does this agent compare with similar options?

Compared with operating Amp, Claude Code, Codex CLI, Cursor CLI, Fx, Grok Build, Kimi Code, OpenCode, or Pi in separate interfaces, Waku centralizes projects, sessions, model selection, reasoning effort, and access modes, but still depends on separately installed and authenticated CLIs. Its desktop uses the Rust waku-client to reach waku-daemon, while the browser client uses packages/waku-client with equivalent handshake, request-ID, subscription, sequence-deduplication, and replay-cursor behavior.

Key facts side by side with the most closely related agents.

Agent Source review Form / cost Stars Updated Language Full support on
Waku Coding Agent Desktop This agent 69 · Some gaps Desktop appFree + model costs ★ 1.6k 16d ago Rust Codex · Claude Code
zerostack 57 · Major gaps CLIFree + model costs ★ 1.7k 5d ago Rust OpenAI API · Claude API
muxel Multi-Agent Workspace 63 · Some gaps Desktop appFree + model costs ★ 34 today Rust Claude Code
Zero 59 · Major gaps CLIFree + model costs ★ 1.7k 1d ago Go OpenAI API · Claude API

How does FollowAgents rate this agent?

FollowAgents source review · FARS-2.1
Some gaps
69/ 100 5-point scale 3.5 / 5
This review covers the source as of Aug 25, 2026. The project has shipped 5 stable release(s) since, which have not been re-reviewed. The score and verdict describe the reviewed version only. Recent releases ↓
Trust 17/29
Reliability 8/14
Adaptability 15/18
Convention 14/18
Effectiveness 9/13
Verifiability 6/8
Why each dimension lost points
Trust17 / 29 · 2.9/5

Installation is per-user, Linux does not require root, externally managed daemon exposure is loopback-only by default, and browser origins must be configured exactly. This supports reasonable least privilege, but the daemon still owns workspace filesystem, Git, terminal, and attachment operations without evidence of per-capability isolation. The README explains local storage and the desktop/daemon/cache/token boundaries, but the release workflow contains a configurable analytics endpoint without documenting telemetry contents, activation, or opt-out, so data-flow transparency is not complete. A stable authentication token and uploaded attachments are sensitive, yet no encryption-at-rest, file-permission, retention, or deletion policy is shown. Dependencies use version constraints, one patched dependency is commit-pinned, and update artifacts use signing; points are deducted because core GPUI dependencies follow mutable Git branches and no dependency audit or vulnerability scan is evidenced. Filesystem, Git, updater, and remote-daemon effects are described, but confirmation gates for every consequential action are not shown. Git-aware rewind and referenced uninstall guidance provide partial recovery, while attachment, database-migration, and updater rollback details are absent. Repository ownership, a security email, sponsorship, and GPL provenance are stated; the publisher remains unverified by the named registry, so maintenance attribution is not treated as fully established.

Reliability8 / 14 · 2.9/5

The README, Cargo manifest, and release workflow are broadly consistent about versioning, platforms, architecture, and packaging. Protocol checks, tag/version matching, and exact artifact paths reduce release inconsistency, but the supplied evidence lacks enough runtime implementation and tests to corroborate every product claim. Rust, Bun, platform toolchains, supported agent CLIs, and Linux/Windows prerequisites are identified, and release builds pin Rust; mutable Git branches and reliance on external services reduce dependency-availability certainty. Workflows emit explicit errors for missing versions, mismatched tags, absent artifacts, and empty releases, but almost no evidence shows user-facing diagnostics for desktop, daemon, or agent-session failures, so failure messaging receives only partial credit.

Adaptability15 / 18 · 4.2/5

The product is clearly aimed at desktop users working with local coding agents and covers projects, independent sessions, follow-up steering, model/access selection, and Git rewind, though guidance is not segmented by role or complex deployment scenario. Capability boundaries are unusually concrete: supported agents, unavailable folder-picker and PTY behavior with an external daemon, macOS-only browser/computer-use features, and native Linux/Windows capabilities are all stated, justifying full credit. Automatic CLI detection, explicit daemon exposure, and exact browser-origin configuration show reasonable trigger control; the deduction is that complete rules for starting agents, executing tools, or approving high-impact operations are not provided. macOS, Linux, Windows, Wayland, X11, MSVC, multiple architectures, and a portable Windows package are explicitly addressed, providing strong environment-fit evidence.

Convention14 / 18 · 3.9/5

The README is organized into installation, supported agents, highlights, architecture, development, sponsorship, and licensing, with clear links to responsible crates, apps, and supporting documents. Installation paths cover all three desktop platforms; Linux documents rootless placement and references manual installation and removal, while Windows offers installer and portable variants. Waku, waku-daemon, waku-core, waku-client, and waku-protocol names remain consistent across documentation and manifests. The main deduction is the absence of complete end-to-end usage examples, UI examples, and an FAQ. Platform and external-daemon limitations are explicit, but migration, telemetry, recovery, and security limitations are not consolidated. GPL-3.0-only is consistent across README, Cargo metadata, and the complete LICENSE, earning full credit. Cargo versioning, tag validation, release artifacts, and CHANGELOG extraction demonstrate a formal release path, but the actual changelog was not supplied. SECURITY.md identifies a latest-release support policy, private reporting channel, and maintenance email, and RELEASING.md is referenced; however, publisher identity is unknown and no explicit maintenance team or long-term governance structure is shown.

Effectiveness9 / 13 · 3.5/5

The product centralizes multiple agents' projects, sessions, transcripts, model settings, follow-up messages, diffs, files, and Git rewind in a native interface, making the claimed output useful for ordinary workflows. The deduction is that no screenshots, complete interaction examples, or representative outputs are supplied to establish presentation quality. A shared interface, structured provider protocols, and session continuity offer clear marginal value over operating several CLIs separately, but some value remains assertion-only and the external-daemon mode lacks the folder picker and PTY. No Waku account, local-first storage, per-user installation, and GPL licensing reduce adoption cost; users must still install and authenticate separate agent CLIs, while development requires Rust, Bun, and platform toolchains, and automatic updates plus a possible analytics endpoint introduce operational and privacy tradeoffs.

Verifiability6 / 8 · 3.8/5

Architecture claims commonly point to named crates, configuration paths, protocol-generation commands, and release workflows, while version and license statements map directly to manifests and LICENSE. The deduction is that the supplied material omits referenced core implementation, platform guides, CONTRIBUTING, RELEASING, and CHANGELOG files, leaving several feature and security claims only partially traceable. README, Cargo.toml, SECURITY.md, and both workflows strongly corroborate platform, version, signed-update, maintenance-channel, and release-path claims, justifying full cross-source credit. Current, experimental, and unavailable capabilities are usually distinguished clearly; deductions remain because promotional claims such as “fast” are unsupported and the “no remote service required” framing does not explain the analytics endpoint visible in release configuration.

Risks and how to mitigate them
  • This is an unexecuted, independently untested static assessment limited to the supplied files; it does not establish runtime safety, correctness, or reproducibility.
  • The daemon has broad authority over workspace files, Git, terminals, and attachments; verify authorization boundaries and confirmation behavior before connecting an external daemon or increasing agent access modes.
  • The release workflow configures an analytics endpoint, but the supplied material does not explain collected fields, default state, destination, or opt-out behavior.
  • Core GPUI dependencies use mutable Git branches; inspect the lockfile, resolved commits, and vulnerability status before building or deployment.
  • The Linux curl-pipe installer, automatic updates, and externally hosted release assets execute or retrieve remote content; review the installer, signatures, and update origin in a controlled environment.
  • Publisher identity is unverified in the specified enterprise registry; this means unknown identity, not evidence of maliciousness.
Evidence confidence: Low Reviewed Aug 25, 2026 Reviewed revision cc8b2cb0ffe9 New commits since this review; the score may not cover them
See the full review method →

Recent releases

Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.

  1. v0.1.20
    Release notes excerpt
    - Support the OpenCode 2.0 release, which now installs as opencode: OpenCode runs on its shared background service, OpenCode 2 beta and OpenCode 1 tasks continue as OpenCode tasks, and OpenCode's free models work in Waku tasks - Fix rewinding or branching an OpenCode task after steering it mid-turn, which forked OpenCode's conversation at the wrong turn - Fix OpenCode tasks going silent when the OpenCode service restarts; a turn it interrupted now continues in place once the service is back …
    View on GitHub ↗
  2. v0.1.19
    Release notes excerpt
    - Render inline and block LaTeX math in Markdown, with a Copy Expression action and a setting to show the source - Fix OpenCode 2 context usage to reflect the latest request instead of cumulative session totals, and cap the meter at 100% - Clear model search when selecting a provider or Favorites tab - Make loading spinners smoother with animations at up to 60 FPS
    View on GitHub ↗
  3. v0.1.18
    Release notes excerpt
    - Fix Codex session forking - Add OpenCode 2 support, add reasoning effort option for both OpenCode and OpenCode 2 - Fix memory usage for long-running sessions
    View on GitHub ↗

FAQ

Does Waku require an account or hosted Waku service?
No Waku account or remote Waku service is required. Application state, projects, sessions, and transcripts remain local, although each chosen agent CLI may impose its own installation and authentication requirements.
Does it include models or a coding agent?
No. Waku is a unified client for supported local coding-agent CLIs. At least one listed CLI must already be installed and authenticated.
Do Linux and Windows have full macOS feature parity?
Not entirely. Sessions, projects, transcripts, skills, usage, diffs, file editing, and the terminal run natively, but the embedded browser and experimental Computer Use integration remain macOS-only.
Can a browser connect to a daemon running separately?
The settings can expose the daemon on a fixed port, allow exact browser origins, and provide a stable authentication token. It is loopback-only by default, and an externally managed daemon currently disables the local folder picker and PTY.
Where do task data and filesystem operations live?
They live on the waku-daemon host. The daemon owns task SQLite data, attachments, session forks, workspace filesystem access, and Git operations; paths it returns always refer to that host.
View on GitHub ↗ Install ↓

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents