Using the Dashboard

The Omnodex dashboard provides a real-time view of all traced agent activity and risk findings.

Starting the Dashboard

omnodex dashboard

This starts a local web server at http://localhost:7890. The dashboard automatically:

• Replays existing events from the log
• Runs detection on any unanalyzed events
• Opens a live SSE connection for real-time updates

Multi-Source Aggregation

If you run multiple agent surfaces simultaneously (e.g. Cowork on Windows, Claude Code in WSL, Codex in a terminal), each one writes to its own event log under its own ~/.omnodex directory. The dashboard can tail all of them at once, merging events into a single unified timeline.

Option 1: Config file (persistent)

Add additional roots to ~/.omnodex/config.json:

{
  "dashboard": {
    "roots": [
      "\\\\wsl$\\Ubuntu\\home\\you\\.omnodex",
      "/mnt/c/Users/you/.omnodex"
    ]
  }
}

The default root (~/.omnodex or $OMNODEX_HOME) is always included automatically, so list only the additional roots. The first example is the form a dashboard on native Windows uses to read a WSL home; the second is the form a dashboard in WSL uses to read the Windows home. See Windows and WSL.

Option 2: CLI flag (ad-hoc)

Pass extra roots at launch time:

omnodex dashboard --roots /path/to/other/.omnodex

Multiple paths can be space-separated: --roots /path/a /path/b.

How it works

Each root keeps its own event log (append-only JSONL files). The dashboard creates an EventLog reader per root, polls each independently for new sessions, and merges all events into a single SQLite read model ordered by timestamp. Each session is tagged with its source_root for filtering.

This is fully local with no network calls: it reads from multiple directories on the same machine.

Dashboard Sections

Event Timeline

The main view shows a chronological list of all traced events. Each entry shows:

• Timestamp
• Event type (tool call, file access, network request, etc.)
• Summary of what happened
• Risk indicators if any rules fired

Click any event to expand its full context: the complete parameters, response, and any associated findings.

Risk Findings

Filtered view showing only events where detection rules fired. Sorted by severity (critical first). Each finding includes:

• The rule that triggered
• Why it triggered (which part of the event matched)
• The full event context
• Risk level

Connection Graph

A map of what the agent connected to: one node per MCP server (and builtin for the agent’s own tools), showing how many distinct tools were used on each server and how many calls were made.

Credential Ledger

Credentials found in tool call parameters, such as bearer tokens, API keys, access tokens, and passwords. Each entry shows the credential type, a masked value, and the tool and server it was passed to. The ledger reads parameters, so it is empty for servers where redact_parameters is on.

Session Overview

High-level view of traced sessions:

• Which agent or interceptor produced it (Claude Code, Codex, Cowork via the MCP proxy, Antigravity)
• Session duration
• Number of tool calls
• Number of findings by severity

Live Updates

The dashboard uses server-sent events (SSE) to update in real time. When an agent session is active:

• New events appear as they happen
• Risk findings surface immediately when detected
• A LIVE/OFFLINE indicator shows connection status

No page refresh is needed. The dashboard streams updates as they occur.

Hosted Dashboard (Cloud)

If you have an Omnodex Cloud account (Hosted tier or above), you can access a cloud-hosted dashboard at dashboard.omnodex.com from any device.

Creating an account

Sign up at dashboard.omnodex.com with your email and a password. During registration, the dashboard generates a recovery key, a one-time code you must save somewhere safe. If you forget your password, the recovery key is the only way to regain access to your encrypted data.

You can also sign in with a magic link (passwordless email link) if you prefer.

Connecting the CLI

The fastest way to link the CLI to your dashboard account is the connect command:

omnodex connect

This starts an RFC 8628 device code authorization flow:

1. The CLI generates a sync passphrase automatically (if you don’t already have one)
2. It displays a short code (e.g. ABCD-1234) and a verification URL
3. You open the URL, sign in to your dashboard, and enter the code
4. The CLI detects the authorization and stores your API token automatically

The passphrase is transferred end-to-end encrypted: it is encrypted under a one-time key embedded in the URL fragment (never sent to the server). After you authorize the device code, the passphrase is stored encrypted in your account and future sessions can decrypt your events automatically.

The device code expires after 15 minutes. If it expires, run omnodex connect again to start a new flow (it reuses the same passphrase).

Using a token directly: If you already have an API token (e.g. generated from the dashboard), skip the device code flow:

omnodex connect --token omx_your_token_here

This stores the token and generates a claim link for passphrase transfer instead.

Using plugins: If you use Omnodex through a plugin (Cowork, Codex, or Antigravity), you can also connect via the plugin’s built-in tools. In Cowork, type /omnodex connect. The plugin calls the same device code flow without needing the CLI on your PATH.

Manual setup (advanced)

If you prefer to set credentials manually instead of using omnodex connect, you need two environment variables:

export OMNODEX_API_TOKEN="omx_..."
export OMNODEX_SYNC_PASSPHRASE="your-passphrase"

The API token is provided when you register your account or create a data stream. The passphrase is the encryption secret you choose.

Once both are set, run omnodex sync to push your local event data to the cloud:

omnodex sync

This encrypts the local read model and uploads it. You rarely need to run it by hand: a connected host syncs on its own (see Automatic sync below). The dashboard command also streams events to the cloud in real time when these variables are set (see Cloud streaming below).

How it works

1. When you run omnodex connect, the CLI generates a passphrase and initiates a device code authorization flow
2. You enter the displayed code on the dashboard, which transfers the passphrase via end-to-end encryption (the decryption key is in the URL fragment, which never reaches the server)
3. The dashboard wraps the passphrase under your account credentials using zero-knowledge key wrapping
4. The CLI encrypts each event with AES-256-GCM using a key derived from the passphrase
5. Encrypted events are pushed to the Omnodex cloud relay (a per-customer Durable Object)
6. When you view the dashboard, your browser derives the decryption key and decrypts events client-side

Your passphrase is encrypted client-side before it reaches the server. Omnodex servers store only ciphertext and cannot read your events or your passphrase.

Cloud streaming

On a host connected with omnodex connect (or with OMNODEX_API_TOKEN and OMNODEX_SYNC_PASSPHRASE set), the omnodex dashboard command automatically encrypts and pushes events to the hosted dashboard in real time alongside the local view.

Automatic sync

Once a host is connected, it keeps the dashboard current without you running anything. There is nothing to enable.

Where your agent runs	What reaches the dashboard, and when
Claude Code, Codex, Antigravity	Each event is pushed to the live relay as its hook fires. The encrypted blob is refreshed when the session ends.
Cowork Desktop, ChatGPT Desktop	Each event is pushed to the live relay as the MCP proxy records it. The blob is refreshed every 15 minutes while the session runs, and once more when the agent disconnects.

The two paths carry the same events for different lifetimes. The live relay is what the LIVE badge reads, and it keeps roughly the last four hours. The encrypted blob is the durable copy, and it is what you see when you open the dashboard on a session that has finished.

Desktop sessions get a timer because they can run for hours, and a host that is force-quit closes the connection without ever reaching a clean shutdown. Hook platforms do not need one: their sessions end explicitly.

Syncing happens in a separate short-lived process, so nothing waits on the network while your agent is working. If a sync fails, the events stay in your local log and the next sync picks them up.

Checking it

omnodex status reports the last automatic sync on a connected host:

[status] auto sync:   last success 2026-09-17T23:10:35Z (14m ago)  blob 3f9c1a2e

If a sync has been failing, the error appears underneath. Background syncs never interrupt your agent, so this is the only place a persistent failure becomes visible.

Turning it off

Set auto_sync to false in stream-config.json, or OMNODEX_AUTO_SYNC=0 in the environment. omnodex sync still works by hand. See Configuration for the interval settings.

Live streaming

The hosted dashboard shows a LIVE badge when connected to the streaming endpoint. Events appear within milliseconds of capture, with a cyan flash animation highlighting new arrivals.

If the connection drops, the dashboard automatically reconnects with exponential backoff (1 second to 30 seconds max). The badge shows CONNECTING during reconnection and OFFLINE if the stream is unavailable.

Multi-Machine Sync (Cloud)

If you use Omnodex on more than one machine (e.g. a work laptop and a home desktop), the hosted dashboard automatically aggregates data from all of them.

How it works

Each machine is identified by a stable ID derived from its hostname. When you run omnodex sync on any machine, the CLI includes this ID in the push. The cloud stores one blob per machine per customer.

When you open the hosted dashboard, it detects multiple machines and fetches each blob in parallel, decrypts them client-side, and merges them into a single unified view. A machine selector dropdown appears at the top of the dashboard, letting you filter to a specific machine or view all machines together.

Setup

Run omnodex sync on each machine using the same API token and passphrase. Both must be set as environment variables (or passed via --token and --passphrase flags):

# On Machine A
export OMNODEX_API_TOKEN="your-token"
export OMNODEX_SYNC_PASSPHRASE="your-passphrase"
omnodex sync

# On Machine B (same credentials)
export OMNODEX_API_TOKEN="your-token"
export OMNODEX_SYNC_PASSPHRASE="your-passphrase"
omnodex sync

If you manage multiple data streams from your dashboard account, each stream has its own API token and passphrase. Use the credentials for the stream you want each machine to push to.

Machine labels

By default, each machine is shown by its auto-generated hex ID. To give a machine a human-readable name, add a label to its ~/.omnodex/config.json:

{
  "machine": {
    "label": "Work Laptop"
  }
}

The label is included in subsequent syncs and displayed in the dashboard’s machine selector dropdown.

What’s merged

The dashboard merges sessions, tool calls, file events, and risk events from all machines. Each session is tagged with its source machine, so you can see which machine produced which activity. The aggregate view shows a machine breakdown alongside the interceptor breakdown.

Multi-machine vs. multi-source

These are complementary features at different levels:

• Multi-source (local) aggregates multiple agent surfaces on the same machine (e.g. Cowork + Claude Code in WSL). Configured via dashboard.roots in config.json.
• Multi-machine (cloud) aggregates data across different machines. Works automatically when you omnodex sync from multiple machines with the same credentials.

Both can be active at the same time. A machine running multiple surfaces pushes all of them in a single sync blob, and the cloud dashboard merges blobs from all machines.

Next Steps

• CLI Commands - Run the dashboard with custom options
• Configuration - Dashboard roots and machine labels