Skip to main content

Command overview

Beacon includes a local-only dashboard for investigating the runtime JSONL log. The dashboard binds to loopback by default, has no external network dependency during normal use, and is intended for local investigation rather than remote administration.
Command syntax

beacon endpoint dashboard

Start the local dashboard, open it in a browser, or bind it to a custom local address.

What it shows

The dashboard reads the configured runtime JSONL log and provides a read-only view of local Beacon events. It follows Beacon’s local rotation pattern, so session lists and event details can include the active file and numbered archives such as runtime.jsonl.1. In the default CLI setup, it reads the same per-user log used by Antigravity CLI, Claude Code, Cline, Cursor, Devin CLI, Devin Desktop, Factory Droid, Grok Build, Hermes Agent, OpenCode, and the other supported hook, plugin, poll, and OTLP collection paths.
  • Agent Activity Sessions: browse grouped agent sessions with risk, prompt, harness, model, repository, duration, activity counts, and last-artifact summaries. The All, Captured, Recurring, and Empty tabs are mutually exclusive views except that All contains every active session: Captured has user-visible activity, Recurring is described below, and Empty contains only lifecycle, metric, or internal events.
  • Session detail: open a session timeline with metadata, activity and severity summaries, event filters, raw JSON, and value inspectors.
  • Lenses: add tabs to a session’s page that show it from one angle: files changed with diffs, an itemized token bill, a security review, approvals, or a lens you wrote. Each lens runs in a sandboxed frame with no network access.
  • Agent Activity: review aggregate local activity, risk signals, harnesses, models, repositories, MCP servers, and runtime inventory.
  • Memory: inspect read-only counts and tables for local evaluations, review candidates, and approved project memories from memory.db.
  • Token Usage: review runtime-reported token usage and cost where sources provide it.
  • Detections: browse the active threat-rule set that Beacon would use for local scans: rules installed in the local store plus the built-in baseline rules the store does not replace by id.
  • Findings: run the active rules over the configured runtime log on demand and review matching evidence with severity and session filters.
  • Agent Inventory: inspect Inventory Local Agent Runtimes for detected harnesses, MCP servers, Agent Skills, hooks, and telemetry status.
  • Runtime-log source: see source details and warnings when a system collector may be writing OTLP events to a different log.
  • Rotated archives: open event details from active or archived runtime logs, even when older archive numbers have already been pruned.
The Detections and Findings screens mirror the same local rule resolution and scan behavior used by beacon scan. They do not fetch rule packs, mutate telemetry, or require a hosted Beacon account. The Memory screen is also read-only. Candidate approval, rejection, superseding, Jev evaluation, and Agent Skill installation stay in beacon memory.

Recurring sessions

A session is recurring when at least two sessions owned by the same user have the same prompt, agent harness, and repository within the dashboard’s selected date range. Beacon compares these values after trimming surrounding whitespace and converting them to lowercase; harness names also use Beacon’s standard harness-name normalization. Missing harness and repository values compare consistently. Sessions without a non-blank captured prompt are never recurring. Every row in a recurring group shows Recurring ×N, where N is the number of matching sessions in the selected date range and user scope. Classification and this count are calculated before result limiting, so limiting the displayed rows does not change either value. Opening a recurring row still shows that individual session’s timeline; Beacon does not merge the group.

Flags

beacon endpoint dashboard

beacon endpoint dashboard starts a local-only dashboard for inspecting Beacon runtime JSONL events.
Open the local dashboard
The dashboard binds to loopback by default and reads the configured runtime log and its local rotated archives. It is intended for local investigation, not remote administration. The command prints the address to open, including a secret for this run:
Sample output
Open that exact URL (over SSH, forward the port and open it on your machine). See Access control for why the bare address is refused.

Examples

Start the dashboard:
Start the dashboard
Open the dashboard in your browser:
Open the dashboard in your browser
Use a custom local address:
Use a custom local address
Inspect a custom runtime log:
Inspect a custom runtime log
During normal use, the dashboard has no external network dependency. It reads local Beacon logs and serves a local read-only UI from a loopback address.

Access control

Every account on a machine can reach a loopback port, so loopback binding alone would let another local account read your runtime log through a dashboard you started. Each run therefore makes a fresh 256-bit secret, keeps it only in memory, and puts it in the URL it prints (and opens with --open). It is never written to a file, a log or JSON output.
  • The first request with the secret sets an HttpOnly, SameSite=Strict cookie for that port and redirects to the same page without ?token=, so the secret leaves the address bar.
  • Every other request needs that cookie. Without it the dashboard answers 401 (403 for a wrong token) and says to open the URL the command printed. Stopping and restarting the dashboard makes a new secret, so an old link or tab stops working.
  • The dashboard still binds only to loopback addresses and refuses requests whose Host is not a loopback name, which keeps DNS-rebinding pages out.
  • Lens frames and the data the session page hands them load with the same cookie; nothing about the lens sandbox changes.
The secret protects against other accounts that do not have it. It does not protect against software that already runs as you, and while a browser is starting, the URL it was handed can be visible in the process list. A browser sends cookies for 127.0.0.1 to every port, so do not open pages served by other local accounts’ servers in the browser you use for the dashboard while it runs. beacon lenses preview uses the same scheme.

Turning the dashboard off

An administrator can turn the dashboard off for every account on a machine, root included:
Turn the dashboard off for everyone
This records "dashboard": "disabled" in the system config.json, which install, repair and package upgrades keep until --dashboard enabled turns it back on. While it is off, beacon endpoint dashboard and beacon lenses preview refuse to start for everyone, in user mode too, and say that the administrator disabled it. Accounts that cannot read a root-only system config read the switch from a world-readable marker beside it, and a config that does not parse also refuses. beacon endpoint status (and --json, as dashboard) reports the setting. Package installs take it from BEACON_DASHBOARD=enabled|disabled. When it is not set, an unattended first package install (the .deb or .rpm, the macOS .pkg or the Windows MSI, with no system config or log already on the machine, installed by a configuration manager, an MDM or a silent msiexec) turns the dashboard off. A person who installs the package on their own machine (sudo at a terminal, Installer.app, the MSI’s full interface) keeps it, and upgrades keep what the endpoint already has. To keep the dashboard on an unattended install, set BEACON_DASHBOARD=enabled, or turn it on afterwards with sudo beacon endpoint repair --system --dashboard enabled; see beacon endpoint install.

Detections

Understand the rule format, detection flow, and findings model.

beacon scan

Run the same active rules from the command line.

Inventory Local Agent Runtimes

Understand configured, detected, and observed local runtime coverage.

beacon endpoint inventory

Print endpoint inventory from the command line or as JSON.