Application Views
This page tours every view in Cosmonic Desktop. Desktop opens to Workloads. The sidebar organizes the views into Explore (Academy and Launchpad), Fleet (Workloads and everything they use—Capabilities, Logs, Secrets), and Inventory (Local Registry and Inspect). The Builder is not a sidebar view: it's a drawer you open from the header, covered below.
The header carries global search (⌘K), notifications, and Settings; once you have more than one local host, a host-tabs row appears below it. The status bar (bottom) indicates the host state (running/starting/stopped), connection status (live, stale, or disconnected—see Troubleshooting), daemon resource usage, a theme toggle, and the daemon version.
Workloads
The view Desktop opens to, and the organizational unit of everything else: each workload bundles the components it runs and the services they consume, deployed onto a host. The table shows each workload's capabilities, invocation rate, and status; the row tools inspect, edit, or delete it, and expanding a row reveals the components inside—with versions, pinned digests, per-component ingress links, and deployment history. Start workload (top right) opens the run flow.
Academy
Cosmonic's learning hub provides a self-paced set of missions to get you acquainted with Cosmonic Desktop and the WebAssembly ecosystem. (Content is served by the app itself and is available offline.)
Launchpad
A curated catalog of templates, applications, and samples you can run on your local host with one click.
Browse or search entries by name and tag; each card shows its capabilities, tags, and source, and Launch takes the entry through the same review-and-apply flow as any workload you deploy by hand—digest-pinned, signature-checked, and sandboxed with deny-by-default egress.
Entries from Cosmonic's own source are marked as official.
Builder (header drawer)
Desktop's prompt-to-production launcher, opened from the Builder button in the header. It slides in as a drawer beside your current view rather than a separate screen, so you can start a build without leaving Workloads. Describe the app you want; Builder creates a new project repo from a starter template (rust-http, go-http, ts-http—or Auto, which picks one from your prompt) in your projects directory, then launches your LLM harness in the shell of your choice: pick any detected coding agent (Claude Code, OpenAI Codex, Gemini CLI, Google Antigravity, Hermes—shown when its cosmonic-sandbox skill is installed and its binary is on your PATH) and your own terminal app (Ghostty, iTerm2, Terminal, …—Desktop detects what's installed). The agent opens as an independent process working in the new repo, with your prompt carried over.
Each agent offers its own model and start-mode choices—from plan-first through guarded modes (where a classifier reviews each action) to fully unattended—and the command preview at the bottom of the prompt box shows exactly what will run before you hit launch. From there the agent drives Desktop over MCP: it builds, deploys, and iterates locally, and the result appears in your Workloads view, sandboxed like anything you deploy by hand. Your existing projects are listed below the prompt with live build/run status, so you can jump back into any of them.
Capabilities
Every capability in use across your workloads. Expand a row to see the importing components and jump to inspection.
Logs
Structured logs from the active host: the daemon, its workloads, and the components they run. Sort or filter any column, or turn on live tail. This is the first place to look when something fails: the reconciler fails fast, so the first Failed event for a workload usually carries the real cause.
Secrets & config
Secret references and reusable named configs. References resolve from your OS keychain or the environment at workload start (1Password and AWS Secrets Manager backends are enabled under Settings → Labs); values never appear in YAML, the API, or this UI. Named configs are key/value maps you can attach to multiple workloads.
Local Registry
The daemon's content-addressed OCI cache, browsed as a registry → repository → version tree. Each version shows its digest, size, cosign signature status, and whether it's in use by a running workload, with tools to inspect, jump to where it's running, pull, prune, and import or export air-gap bundles (see the daemon's oci commands).
Inspect
A component's imports and exports, graphed. Pick any local component, service, or workload and see its declared interfaces as a color-coded connection diagram, with a structured summary, security and provenance details, and hyperlinked WIT. It's the same information the run flow's review step summarizes before you deploy.
Settings
App and daemon configuration by section: General (appearance, host port), Privacy (the two telemetry consents), Security (signature policy—advisory by default, strict signing global or per registry), Registries (credentials and mirrors), Built-in plugins and Messaging (host capabilities), MCP Server (agent access), Agent skills (the cosmonic-sandbox skill), Project folders, Logging, Launchpad and Academy (the content sources for those hubs), Updates, and Labs (experimental features).
The menu-bar tray
The tray icon is a lightweight native companion (not the app itself) that reflects daemon state at a glance and handles the essentials without opening the app: Open Control Panel (launches the full app), Start/Stop daemon, Start on login, and Uninstall Cosmonic.
Closing the app window doesn't stop your workloads. The daemon and tray keep running; quitting the tray leaves the daemon service itself untouched. The Cosmonic Tray covers the tray in full.
GNOME needs the AppIndicator extension to show tray icons—see Troubleshooting.