OpenCode has been terminal-first from day one, but the newly released OpenCode Desktop pushes the project into a more mainstream workflow with a full desktop GUI that still uses the same underlying agent/server architecture as the CLI/TUI. The new client is officially listed as a Beta, so expect some rough edges, and it’s available for macOS, Windows, and Linux.

What’s New in the GUI Release

A real desktop app (not just “terminal in a window”)

Under the hood, the repo’s release assets clearly show dedicated desktop builds (e.g., opencode-desktop-*.dmg, Windows, Linux packages), separate from the terminal binaries.

Desktop polish work is landing fast

Even in today’s releases you can see desktop-specific work landing (Tauri-related changes like a macOS app menu and ensuring the “sidecar” process is properly killed during updater relaunch). That’s the kind of “this is becoming a real desktop product” plumbing that usually appears once an app is past the prototype stage.

Same “Core OpenCode” capabilities, but in a GUI Shell

OpenCode’s own positioning emphasizes capabilities that carry across interfaces, including:

• LSP-enabled behavior (auto-loading the right LSPs)
• Multi-session work (multiple agents in parallel)
• Share links to sessions
• Broad provider/model support (“any model” via many providers)
• “Any editor” positioning (terminal + desktop + IDE)

What it’s lacking (because it’s Beta)

The most useful way to understand “what’s missing” is to look at the rough edges users are reporting and the feature requests that exist specifically because the Desktop UI isn’t fully rounded yet.

Stability / “first run” issues

A brand-new, high-visibility bug report: some users can launch the macOS desktop app and only see a blank (but resizable) window, with no UI rendering.
That’s a classic beta symptom: packaging and runtime differences across OS versions/GPUs/windowing stacks still being ironed out.

Project/workspace model isn’t fully mature yet

Desktop users have already hit a worktree collision problem: opening two git worktrees from the same repo causes one project to overwrite the other because the project ID is derived from the repo root commit hash (same for both worktrees).
That’s the kind of edge case terminal power-users find quickly—good that it’s identified, but it’s also very “beta-y.”

Windows + WSL workflows aren’t first-class (yet)

A feature request calls out that the Desktop app currently spawns a native Windows sidecar, which doesn’t work well for developers who keep their projects/tooling inside WSL. The proposed fix is a settings UI toggle to choose a WSL backend command.
This also hints at another gap: the issue explicitly mentions enabling a “currently disabled Settings button,” suggesting preferences/config UX in Desktop is still emerging.

Packaging gaps on Linux

Desktop is distributed as .deb / .rpm, but at least one request is already asking for Flatpak, because the current approach blocks some distros.

Small quality-of-life gaps still being requested

Even the terminal/TUI experience has open requests like “copy output to clipboard” because copying long snippets can be painful. In a desktop GUI, users will expect this sort of interaction to be frictionless—so requests like this are a signal of what still needs smoothing.

How it compares to the CLI and TUI

A helpful mental model: OpenCode is a client/server system, and the UI layer is increasingly “just a client.” A technical deep dive notes that running opencode typically launches the backend server plus a terminal UI process, and other clients can talk to the backend over HTTP.

Desktop GUI vs TUI

Desktop GUI advantages

• Lower barrier to entry: easier onboarding for folks who don’t live in the terminal.
• Better fit for windowed workflows: multiple sessions and navigation can feel more natural in a GUI.
• Desktop app UX can evolve faster (menus, settings panels, clickable sharing, etc.).

TUI advantages

• Mature “keyboard-native” ergonomics for terminal power-users.
• Often more resilient in dev environments (SSH, tmux, remote boxes, minimal UI stack).
• Typically easier to script around and debug with logs (and troubleshooting docs lean terminal-first, e.g. --print-logs).

Desktop GUI vs CLI (automation-first usage)

If you think of “CLI” as the automation layer:

• CLI is where you expect scripting, piping, reproducible runs, and headless usage.
• Desktop is where you expect discoverability, UX affordances, and fewer sharp edges—but in beta it may temporarily have more sharp edges (packaging, blank windows, OS integration quirks).

Who should use what right now?

• Use Desktop (Beta) if you want OpenCode in a familiar app shape and you’re OK with occasional beta issues (especially if you’re on a well-supported OS version and don’t rely heavily on WSL/worktree edge cases).
• Stick with TUI/CLI if you care most about reliability, remote/terminal workflows, and tight keyboard-driven iteration—plus you’ll generally have the smoothest troubleshooting path there.

So what are you waiting for? Check out the downloads page and give it a go!