Dashboard & Desktop

InitRunner ships with a web dashboard for browser-based management and a native desktop app that wraps the same UI in a standalone window. Both provide real-time visibility into agents, flow pipelines, teams, audit logs, and ingestion.

Web Dashboard

The dashboard is a SvelteKit frontend backed by FastAPI API routers. It uses the "Electric Charcoal" design system, a dark-only theme with OKLCH colors, Space Grotesk and IBM Plex Mono typography, and a lime accent.

Installation

pip install initrunner[dashboard]

Requires fastapi and uvicorn.

Launch

initrunner dashboard
initrunner dashboard --expose --port 9000

Security & exposure

Since v2026.6.1, the dashboard fails closed when bound off-host. Binding to a non-loopback host (--expose) without an --api-key no longer serves unauthenticated; a one-time key is generated and printed to the console at startup, and that key is the only way in. Loopback binds (the default) may still run keyless for local dev. The same fail-closed posture covers the MCP gateway and A2A server. To require a key on the API server, pass --api-key. See Security for the full authentication model.

Also since v2026.6.1, the localhost dashboard rejects any request whose Host header is not localhost or 127.0.0.1 (Starlette TrustedHostMiddleware), so a malicious page cannot drive the local dashboard through a DNS-rebinding hostname. The session cookie's Secure flag is derived from the connection scheme rather than a client-spoofable header, so it is set only over HTTPS.

Telemetry

Since v2026.6.2 the dashboard can report anonymous usage via posthog-js, and since v2026.6.3 it is opt-in. On first load the dashboard shows a one-time consent banner with Enable and No thanks; posthog-js is deferred until you accept, and nothing is sent before then. When enabled it runs with no autocapture and no session recording, and it stays inert when the browser sets Do Not Track. See Telemetry.

Pages

Key Features

Approvals queue

Since v2026.4.17, the dashboard surfaces human-in-the-loop approvals in two places:

Inline in RunPanel. When a run kicked off from the agent detail page pauses, the approval_required SSE event slots an ApprovalCardGroup into the run panel in place of the "thinking" state. Each pending call renders with a 2px left state bar (muted = unset, lime = approved, red = denied), a tool-templated argument preview (e.g. rm -rf /tmp/cache instead of raw JSON), and an Approve/Deny pair with <kbd> chip hints. Submit fires only once every card has a decision; if the model re-pauses, the group updates in place.

Queue view (/approvals). Reviewers see every paused run across the daemon, API, and other sessions, grouped by run_id. Single-call runs have inline Approve/Deny; multi-call runs open a right-side ApprovalDrawer with the originating prompt and per-call controls. A sidebar badge under Operate shows the pending count in tabular-nums, polled every 20s and bumped immediately by SSE. A ? shortcut overlay documents the keyboard grammar:

Absent-Kicker toasts. A session-local registry of run_ids you kicked off diffs against each poll; if a run you started shows up while you're on a different page, a toast links you back to /approvals/{run_id}. Runs other operators started get only the badge, so there is no noise for work you didn't trigger.

The queue is backed by a new /api/approvals/* router that calls services.execution.resume_run_sync in-process, so approvals always resume in the same daemon that hosts the paused run.

Run detail drawer

Since v2026.5.5, clicking a row in the audit table opens a per-run detail drawer backed by GET /api/audit/{run_id}. The drawer pulls one run apart into three panels.

Run record. The full record for the run, including the model, provider, prompt, output, per-run cost, and token counts. Token counts now include thinking and reasoning tokens alongside the input, output, and total counts.

Event timeline. A per-run timeline of the run's thinking deltas, tool calls, and tool results, in the order they happened. Live streaming runs record it from their stream events; other runs (the buffered path and non-streaming CLI runs) reconstruct the same entries from the final message history, so both produce a timeline whenever audit logging is on. Each entry is secret-scrubbed and free-text values are truncated. The timeline is best-effort: a run with no thinking, tool calls, or tool results (for example a plain text answer that used no tools) has nothing to show, and runs recorded before this column existed have no stored timeline. In either case the drawer omits the panel.

Judge verdicts. For runs that used the reflexion reasoning pattern with success criteria configured, the drawer lists each verification round with its overall pass or fail and the per-criterion results. Runs that did not run reflexion, or ran it without success criteria, have no verdicts and the panel is omitted.

Thinking effort

Since v2026.5.5, the agent builder exposes a thinking-effort selector that sets native extended thinking on the model. The choices come from the builder options endpoint, so they always match the valid config values: minimal, low, medium, high, and xhigh, plus an option to leave thinking unset and use the provider default.

Picking a level writes spec.model.thinking in the generated YAML:

spec:
  model:
    provider: openai
    name: gpt-5
    thinking: medium

This setting applies only to reasoning-capable OpenAI models (the o-series and the gpt-5 family, except gpt-5-chat). Setting it on any other provider or model is rejected when the role is validated. It is distinct from the reasoning patterns configured in the Cognition panel, which control InitRunner's cross-turn reasoning (spec.reasoning) rather than the model's own thinking.

Desktop App

The desktop command launches the dashboard in a native window via pywebview. No browser required.

Installation

pip install initrunner[desktop]

Adds pywebview on top of the dashboard dependencies.

Launch

initrunner desktop
initrunner desktop --port 8100 --roles-dir ./extra-roles/

How It Works

1. Starts an embedded FastAPI backend in a background thread
2. Opens a native window (1280×800, minimum 900×600)
3. Polls /api/health until the backend is ready (30-second timeout)
4. Uses GTK/WebKit on Linux, Cocoa on macOS, WebView2 on Windows

On Linux, if GTK or WebKit is missing, the command prints distro-specific install hints (Ubuntu, Fedora, Arch).

Choosing an Interface

Cloud Hosting

The web dashboard can be deployed to a cloud platform for always-on remote access. Each platform builds from the same Dockerfile and seeds example roles on first boot.

Tip: Set INITRUNNER_DASHBOARD_API_KEY to password-protect the dashboard when exposing it on a public URL.

See Cloud Deploy for step-by-step instructions for each platform.