Dashboard

For when you’d rather click than type, kovra ships a small administration dashboard. It is on-demand and loopback-only — it isn’t a daemon, isn’t exposed to the network, and is governed by the exact same policy as the CLI and agents.

Launch it

You bring the dashboard up two ways — both run the same loopback server. Opening it asks you to bioProve first (opening an admin surface is itself a guarded action), then binds 127.0.0.1 only and mints an ephemeral session token.

From the CLI

On macOS, kovra ui opens the dashboard in a native OS window (a WKWebView) by default. Add --browser to open it in the system browser instead — the session URL then passes through the open command line and the terminal, where other programs running as you can read it, so the page removes the session token from the address bar as soon as it reads it:

zsh

~ % kovra ui --browser
kovra ui → http://127.0.0.1:8731/#session=0bd48b80…
(loopback only; ephemeral session; auto-shutdown after 300s idle or Ctrl-C)

From the menulet (macOS)

The kovra-menulet menu-bar app has an “Open Dashboard…” item that launches the same dashboard in a native window — no terminal needed:

It shuts down on Ctrl-C or after an idle timeout (--idle, default 300s). Useful flags: --browser (the system browser), --no-open (browser mode, but just print the URL — refused on macOS, where the URL kovra prints never carries the session token: use --window), --port, and --window (force the native window the menulet uses — the window owns the session, so the loopback server stays up while it’s open and stops when you close it).

What it shows — and what it won’t

The UI visualizes your vault by sensitivity: coordinates, tiers, modes, projects, and metadata. Crucially, it never renders the plaintext of a high or inject-only secret, nor of any prod secret (even one lowered to low) — those are shown masked, with no fingerprint (—), and the only way to reveal them is a deliberate kovra show at the terminal. An ordinary, revealable value (non-high, non-inject-only, outside prod) can be shown inline, exactly as kovra show or an agent’s reveal would — the boundary is the sensitivity tier, not the surface. The same boundary that protects an agent protects the page: a browser tab is just another surface, and the policy treats it like one.

Manage secrets

The Dashboard isn’t read-only — it’s a full administration surface for the vault, governed by the same policy as the CLI:

• Create a secret, or generate a strong random value server-side (the generated value is stored, never shown).
• Update a value, or edit metadata — sensitivity, description, the revealable flag, or a reference.
• Reveal an ordinary revealable value inline; delete a secret.

Destructive and sensitive actions take an attended confirmation per action: deleting a secret, or lowering a secret’s sensitivity, pauses for an bioProve (Touch ID, or your login password on a Mac without it) before it applies. A downgrade is written only on approval — a deny or timeout leaves the record untouched. Overwriting a critical (high or inject-only) secret’s value or reference takes the same approval, and so does creating a secret in a project vault at the coordinate of a critical global one — a run in that project would deliver the new value instead. One edit can’t change both the sensitivity and the reference of a critical secret: make two edits, each with its own approval. It’s the same authoritative confirmer the CLI uses; the browser doesn’t get a weaker gate.

Fulfil agent requests

When an agent calls request_secret, the pending request appears in the dashboard — coordinate, requested sensitivity, and the requester’s note, never a value. What the request says about who asked comes from a file the agent can write, so the approval dialog shows it only as untrusted text. You fulfil it right there: type the value into the loopback page (only you can, over 127.0.0.1) and kovra seals it under the coordinate; or dismiss it. The value goes straight into the vault — it never passes back to the agent that asked (I11/I14). prod is born high (the request can’t lower it), and fulfilling a high secret is an attended action gated by the same bioProve (I16).

Keep it open — persistent mode & the lock latch

By default the UI auto-shuts-down when idle. If you’d rather leave it up across a work session, kovra ui --persistent keeps the server running until Ctrl-C — but it does not keep your vault on screen. After --idle seconds of inactivity (default 300s; --idle 0 disables it) the UI locks instead of shutting down:

kovra ui --persistent

A locked UI is a latch — it reveals nothing. The page drops to a lock screen and the server stops serving vault data until you re-authenticate with a fresh bioProve; nothing sensitive is left rendered behind it. This is the same boundary as the launch gate, applied continuously: stepping away for --idle seconds locks the tab instead of leaving your coordinates and metadata on screen. On macOS, locking your screen (⌃⌘Q) or letting the Mac sleep also trips the latch — the Dashboard locks the moment you step away, not only after the --idle timeout.