Windows & Linux

The Windows and Linux desktop app is the same workbench you get in the browser, packaged as a local application with its own agent daemon inside it. It is local-first: it starts its own daemon on loopback at launch and lands you in a working “This device” workspace. Signing in and connecting other machines are things you choose afterwards, not gates you pass through first.

​

What it actually is

The shell is Electron. It wraps the same single-page app the web app runs, and supervises a bundled Go daemon (continuum-agent) as a child process. That has one useful consequence: a fix to the web workbench is a fix to the desktop workbench — there is no separate Windows/Linux UI to fall behind. What ships inside the installed app:

​

Install

Builds are published on the Continuumcodeapp/continuum-updates GitHub releases page under the -desktop tag for each version.

​

Code signing

Tagged public Windows releases are Authenticode-signed. The release pipeline fails closed without a certificate: electron-builder signs the app and the installer, an afterPack hook signs every packed sidecar executable (the daemon and CLI binaries), and the workflow then runs signtool verify /pa /all across every .exe in the build before anything is uploaded. Signing the sidecars matters in practice — Windows Smart App Control refuses to spawn an unsigned agent binary, which would leave a signed installer with a dead backend. The packaged binary also has Electron’s hardening fuses burned in: RunAsNode, NODE_OPTIONS, and --inspect are disabled, the app will only load from the ASAR archive, and cookies are encrypted at rest.

​

Updates

The desktop app updates itself quietly, on the same philosophy as Sparkle on the Mac: it checks about 8 seconds after launch and every 6 hours after that, downloads in the background, and installs on the next quit. There is no modal and no interruption. When a build is staged, the window shows a small “Update ready” affordance; Settings has a Check for updates now button. Two environment variables change that behavior:

​

First run

The first launch is two steps.

​

It is a host, not just a client

This is the part that distinguishes the desktop app from the web app and the phone. The bundled daemon means sessions run here, on your own machine, against your own checkouts. When you enroll the computer into your account mesh it registers as a first-class execution host — windowsDesktop on Windows, linuxDesktop on Linux — sitting alongside Macs, VPS boxes, and cloud runners in the host picker on every other client. Enrollment is an outbound relay dial. The app redeems a one-time, account-scoped enroll code for a device identity and a relay rendezvous, and the daemon then dials out to reach the relay. Nothing binds beyond loopback; you are not opening a port on this machine. You do not need a Mac for any of this. A Windows or Linux desktop is a complete Continuum installation on its own.

​

Keeping a Linux box online with the GUI closed

On Linux, enrolling the computer installs a systemd user service — continuum-desktop-host.service — plus loginctl linger, so the daemon stays up and its sessions stay relay-reachable when you close the window and across reboots. The GUI then attaches to that long-lived service instead of spawning its own throwaway loopback daemon. It prefers port 21731 and falls back to a free port if something else already holds it.

​

Tabs and desktop chrome

The workbench is the standard three tabs — Code, Usage, Settings. See Code and Usage for what each one does; they behave the same here as everywhere else. Each tab is also a real URL inside the shell, so a /code, /usage, or /settings/organisation deep link resolves. On top of the shared workbench, the shell adds native desktop behavior:

• Tray gauges. Every visible provider (or provider/account) gets its own system status item, mirroring the Mac’s menu-bar model. Clicking one opens the usage popover.
• Notifications, attention badge, and chimes when a session needs you.
• Deep links. The app owns the clawdmeter:// and clawdmeters:// URL schemes, so a pairing link opens it.
• Voice dictation into the composer, with the speech model managed by the app.
• Launch at login, so Continuum comes back with your session.

​

Differences from the Mac app

Worth knowing before you assume parity:

• The Mac app runs a native Swift daemon; the desktop app runs the Go agent. Both publish the same wire projections, so clients see the same data, but the implementations are separate and the Go agent is the newer of the two.
• The Mac is stable; Windows and Linux are beta.
• Apple-only surfaces have no counterpart here: no Apple Watch, no Live Activities, no widgets or complications.
• Provider availability depends on whether that provider’s CLI ships for your OS and architecture.

​

Where things live on disk

The bundled daemon keeps its state in an agent folder inside the app’s own data directory — %APPDATA%\Continuum\agent on Windows, ~/.config/Continuum/agent on Linux. That is where its bearer token (agent-token) and its mesh enrollment records sit. Point the CLI at that folder if you want continuum to drive this app’s daemon. Ordinarily the daemon binds a loopback port assigned at launch, so it can never collide with anything else on the machine. The one exception is the Linux persistent host above, which prefers 21731 because it is meant to outlive the window.