The OpenCode Desktop App — native, signed, CLI-backed.

What the OpenCode Desktop App is for.

The OpenCode Desktop App is a reviewer-oriented surface around the OpenCode CLI. It is aimed at developers who prefer a GUI, team leads who manage an approval queue, and auditors who want an always-visible session transcript.

Under the hood, the OpenCode Desktop App does not re-implement the agent. It spawns the same opencode binary that the CLI install put on your PATH and streams structured events over the documented wire protocol. Every plan, every tool call, every diff is generated by the CLI process; the desktop surface only renders them. That architecture is what lets a platform team approve the CLI once and have the approval cover every downstream client automatically.

When to pick the desktop app.

Pick the OpenCode Desktop App when you want a persistent window, an approval queue, or a tray-pinned transcript. The CLI remains the right pick for scripted work and SSH sessions.

Reviewers especially benefit from the desktop surface: a queue of proposed patches sits in the left rail, a diff view sits in the middle, and the tray log shows the agent output in real time. Team leads who triage incoming agent PRs find the queued layout faster than reading raw terminal output. Developers who pair the OpenCode Desktop App with a terminal get the best of both — terminal for dense work, desktop for review and approval.

System requirements for the OpenCode Desktop App.

The OpenCode Desktop App runs on every mainstream developer workstation. Hardware requirements are modest because the heavy work — model inference — happens outside the app.

macOS 12 or newer is required for the Sparkle-signed auto-updater. Windows 10 1809 and newer, x64 and ARM64, are supported on the same cadence; the MSI integrates with Group Policy, and Smart App Control accepts the Authenticode signature without prompting. Linux is supported on any glibc 2.28 or newer distribution via a signed AppImage, a .deb package, and a .rpm package; a Wayland session is recommended on distributions where it is the default.

Memory and disk footprint.

The OpenCode Desktop App is sized to run alongside a full IDE without thrash. A typical workstation budget for the app is well under a gigabyte of RAM at idle.

Installed size is 84 MB on disk, which includes the CLI binary, the native UI shell, and the bundled shader cache. Runtime memory hovers around 180 MB with a moderate diff backlog in the approval queue. Background CPU use is zero when idle; the app drops all polling when the window is hidden and wakes on an OS-level signal rather than a busy loop. These numbers are comparable to a note-taking app, which is intentional.

Auto-update, tray integration, and native menus.

The OpenCode Desktop App auto-updates through the native mechanism on each OS, using the same pinned signing key that the CLI uses. Endpoint management teams can disable or pin the updater from a single config flag.

On macOS the updater is Sparkle-signed with an EdDSA key rotated on the published schedule. On Windows the MSI registers a Squirrel-based updater and respects Group Policy — setting OpenCode_DisableAutoUpdate pins the version. On Linux the AppImage ships an embedded update server and the .deb package follows the apt repository. All three paths report the new version to the tray log and ask for confirmation before replacing a running binary.

Native menus and keybindings.

The OpenCode Desktop App uses native menus on each OS — Cmd on macOS, File/Edit on Windows, standard GTK menus on Linux. Keybindings are editable.

The keybinding editor lets a developer remap every app-level shortcut: approve, reject, revert, reroll, toggle tray, open CLI in attached terminal. Keybinding JSON is written to a single config file you can check into a dotfiles repo, which matters for teams that share a configuration. The desktop app also honors the global shortcut set by the OS — Cmd+Opt+O on macOS, Ctrl+Alt+O on Windows and Linux — so a developer can summon the approval queue from any application.

Security posture of the OpenCode Desktop App.

Because the OpenCode Desktop App spawns the CLI, the security model is the CLI security model. Tool calls run under the same sandbox, the same allowlist, and the same approval flow.

Native-window-specific surfaces — clipboard, drag-and-drop, screen recording — are disabled by default and gated behind an explicit opt-in with a visible badge in the window chrome. The app is signed with Authenticode on Windows, notarized on macOS, and delivered with a detached Sigstore signature on Linux. Crash dumps are stripped of source paths and content before upload, and telemetry is off unless an admin opts in per-workstation. Procurement packets on the trust and safety page align to the NIST supply chain risk management guidance that regulated teams already follow.

Group Policy and Intune.

Windows-fleet administrators can manage the OpenCode Desktop App via Group Policy or Intune using the MSI. The ADMX template is published alongside each stable release.

Policies cover auto-update pinning, disable telemetry, fix the provider endpoint to an internal gateway, and block the global keyboard shortcut for fleets that reserve those shortcuts for other software. A similar mechanism on macOS is a config profile (.mobileconfig) with the same key names; on Linux, a system-wide /etc/opencode/policy.toml is read at app start. These controls are the minimum most regulated teams need to deploy a developer tool, and they are how our procurement-fit posture is audited.