Application Views
This page tours every view in Cosmonic Desktop. Desktop opens to Workloads. The sidebar organizes the views into three groups:
- Explore: Academy, Launchpad, Build, and Inspect.
- Fleet: Workloads and everything they use: Capabilities, Logs, and Secrets.
- Inventory: Local Registry.
Right-click any sidebar item and choose Set as default screen to open Desktop on that view instead.
The header carries a terminal toggle (it shows or hides the terminal dock at the bottom of the window), Help, 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.
Build
Desktop's prompt-to-production launcher. Describe the app you want, and Build creates a new project repo from a starter template in your projects directory. The template picker is on Auto by default, which picks an HTTP, MCP server, NATS, or Kafka starter from your prompt; choose one yourself to override it. Then Build launches your native coding agent on the project: pick any detected agent (Claude Code, OpenAI Codex, Gemini CLI, Google Antigravity, Hermes, OpenClaw, NVIDIA OpenShell, and more, each shown when its cosmonic-sandbox skill is installed and its binary is on your PATH). The agent runs in the Integrated terminal dock under the page by default, or in a terminal app you choose from the Terminal menu.
The coding agent runs natively, with your user permissions, outside the sandbox; Build says so under the pickers. Each agent offers its own model and start-mode choices, from plan-first through guarded modes (where the agent's own best-effort guardrail, such as a classifier, reviews actions) to fully unattended, and the $ line at the bottom of the card shows exactly what will run before you select 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. The Previous sessions list to the right shows the coding-agent sessions already on this machine, so you can open one read-only or resume it.
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; 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, grouped into five sections:
- Setup & trust: General (appearance, host port), Privacy (the two telemetry consents), and Security (signature policy, advisory by default, with strict signing available globally or per registry).
- Learn & launch: the content sources for Academy and Launchpad.
- Runtime: Project folders, Toolchain (the build-toolchain doctor), Built-in plugins (host capabilities, including NATS messaging clusters), Registries (credentials and mirrors), Host Labels (labels a workload can target for placement), Admin Workloads (a read-only view of the platform's
cosmonic-systemworkloads), and Notifications (per-component permission for thecosmonic:notifyhost capability). - Agent workspace: Agents (install and update the cosmonic-sandbox skill for each detected coding agent) and MCP Server (agent access).
- Maintenance: Logging and Updates.
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.