> ## Documentation Index
> Fetch the complete documentation index at: https://continuum-three-olive.vercel.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Windows & Linux

> The desktop app for Windows and Linux — the same workbench as the web app, wrapped in an Electron shell around a bundled daemon that hosts sessions locally.

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.

<Note>
  The desktop app is in **beta**. The Mac app and the iPhone app are the mature clients; Windows and Linux are newer and still moving quickly. They work, but expect the occasional rough edge.
</Note>

## What it actually is

The shell is Electron. It wraps the same single-page app the [web app](/docs/surfaces/web) 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:

| Component         | Role                                                                       |
| ----------------- | -------------------------------------------------------------------------- |
| Electron shell    | Window, tray gauges, notifications, chimes, deep links, voice, auto-update |
| Dashboard bundle  | The Code / Usage / Settings workbench                                      |
| `continuum-agent` | The daemon that actually runs your sessions on this computer               |
| `continuum`       | The [CLI](/docs/surfaces/cli), so the terminal client is on the box too         |

## Install

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

<Tabs>
  <Tab title="Windows">
    An NSIS installer, `Continuum-<version>-x64-setup.exe`. **x64 only** — there is no arm64 Windows build.

    The installer is not one-click: you can choose the installation directory.
  </Tab>

  <Tab title="Linux">
    Two package formats, each for **x64 and arm64**:

    * `Continuum-<version>-<arch>.AppImage`
    * `Continuum-<version>-<arch>.deb`

    Pick the `.deb` on Debian/Ubuntu if you want it in your package manager; the AppImage if you want a single portable file.
  </Tab>
</Tabs>

<Warning>
  The `.dmg`/`.zip` macOS artifacts produced by this same Electron build are unsigned development output, not a shipping product. On a Mac, install the native Mac app instead — it is the flagship client and has its own signing, notarization, and Sparkle updater.
</Warning>

### 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:

| Variable                    | Effect                                                                                                |
| --------------------------- | ----------------------------------------------------------------------------------------------------- |
| `CONTINUUM_UPDATE_FEED_URL` | Point the updater at a self-hosted HTTPS feed instead of GitHub releases. Non-HTTPS URLs are ignored. |
| `CONTINUUM_UPDATE_DISABLED` | Hard kill switch. Pins a packaged build in place — always wins.                                       |

## First run

The first launch is two steps.

<Steps>
  <Step title="Sign in to sync your devices">
    Sign in with your email through your browser. Sign-in syncs your account; it does not by itself expose this computer to anything.

    Underneath the button is a single checkbox: **"Allow my other signed-in devices to run sessions on this computer."** Leave it off and this machine is a workbench for you alone. Turn it on and it enrolls into your account's device mesh, which is what lets your phone, another Mac, or a browser tab start work here. You can change it later from Devices, and you can skip the whole step.
  </Step>

  <Step title="Choose providers">
    The app scans the machine for coding tools that are already installed and turns on the ones that are ready. For the rest you get an in-app setup panel per provider: install it here, sign in here, or paste an API key.

    Providers offered on this screen: **Claude, Codex, Antigravity, Cursor, OpenCode Go, OpenRouter, Z.ai Coding, and Grok.** If you are already signed in to Claude Code on the machine, Continuum detects it and offers a one-click "Use Claude Code sign-in."
  </Step>
</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.

<Note>
  The unit is deliberately *not* named `continuum-agent.service`. A box may also be running the standalone headless Go agent under that name, and the two must not collide.
</Note>

## Tabs and desktop chrome

The workbench is the standard three tabs — **Code**, **Usage**, **Settings**. See [Code](/docs/surfaces/code) and [Usage](/docs/surfaces/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](/docs/surfaces/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.

<Note>
  Internally Continuum still carries its original codename, **Clawdmeter**. You will see it in the `clawdmeter://` URL scheme and in the `CLAWDMETER_*` environment variables the daemon reads. That is expected, not a mispackaged build.
</Note>