Hosted Dashboard

This page covers the hosted dashboard at dashboard.omnodex.com, part of the Hosted tier and above. Connected hosts encrypt their events before upload and your browser decrypts them, so you can open it from any device and see every connected machine together. For the dashboard you run on your own machine, see Local Dashboard.

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 stream secret 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 stream secret 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 secret is stored encrypted in your account and future sessions can decrypt your events automatically. Streams and Stream Controls explains the stream secret and the connection token in more detail.

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

If your account has streams that were revoked, or that you removed from your account, the page where you enter the code also offers to re-authorize one of them instead of creating a new stream. See Authorizing a machine again.

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 checks and stores the token, and generates a claim link that transfers the stream secret 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_STREAM_SECRET="your-stream-secret"

The API token (connection token) is shown to the stream’s owner in Settings. The stream secret is the encryption secret; reveal it from the stream’s card in Settings.

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 stream secret and initiates a device code authorization flow
2. You enter the displayed code on the dashboard, which transfers the stream secret via end-to-end encryption (the decryption key is in the URL fragment, which never reaches the server)
3. The dashboard wraps the stream secret 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 stream secret
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 stream secret is encrypted client-side before it reaches the server. Omnodex servers store only ciphertext and cannot read your events or your stream secret.

Cloud streaming

On a host connected with omnodex connect (or with OMNODEX_API_TOKEN and OMNODEX_STREAM_SECRET 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.

To stop recording or uploading on a machine for a while, see Pausing Recording and Uploads. Pauses appear as events in the timeline, even if the dashboard was closed during them.

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.

Blob size limit

Each machine keeps one encrypted blob in the cloud, rebuilt on every sync, and a blob can be at most 50 MB. omnodex status shows how close the last one came, and Settings, under Connected Streams, shows the same for each machine on a stream:

[status] sync blob:   12.3 MB of 50 MB (25%)

From 80%, both warn. Past 50 MB the sync is refused, the dashboard stops updating from that machine, and omnodex status says so. The blob holds every session in the machine’s local event log, so to make room, move older session files out of ~/.omnodex/event-log/sessions/ and keep a copy elsewhere. The next sync rebuilds the blob from what is left. The live view is not affected.

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 footer shows how many of your streams are connected (for example 2/2 Streams Connected) and the time of the last event. The badge is green when every stream is live and amber when only some are. 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 no stream is available.

Filtering the dashboard

The bar at the top holds the stream filter on the left and, on the right, the time range, a pause button for the live window and a refresh button that reloads the synced data without leaving the page. The time zone is set in Settings.

Most widgets narrow the rest of the dashboard when clicked, and each active filter shows as a chip you can click to remove; Clear filters removes them all.

• Session breakdown: click a runtime, machine or stream to show only its sessions. Click it again to show all.
• Risk Summary: click a risk type to show only the calls, sessions and files behind those findings. The summary keeps listing the other types so you can switch.
• File Events: click a file event to open its details, including the tool call in that session that most likely touched the file.
• Enforcement: in shadow or guardrails mode, choose Would have blocked to show only the findings that would have stopped their call. The Would have blocked tile counts them. Both appear once a finding in the time range carries an enforcement note.
• Tool Calls: expand a tool to list its calls, each with its time and a one-line summary from its parameters (a command’s description, the file read, an MCP call’s action). Click a call for its full details.

Understanding a risk finding

Select a risk finding to open its details. The final Risk Library row, before related tool-call details, has a Learn more about this risk type link with an external-link indicator. It opens the rule explanation in a new tab. The link includes the rule ID, without the session, tool parameters, or other event data. A rule not yet covered by the library opens its rule index. Opening the explanation requires network access to the documentation site.

The Risk Library explains why the behavior may be risky, gives an example, and describes false positives, false negatives, and technical limits. A finding identifies a pattern to review in context rather than proof that harm occurred.

Investigations

On a Pro plan, advanced rules follow sensitive data across a chain of calls: credentials and secrets, database files and dumps, mail stores, and source code, from where it was read, through any archiving or encoding, to where it was sent. Findings about the same chain are read together as one investigation.

• Where they appear: at the top of the Risk Events panel for the sessions in view, most severe first, and on the Investigations page in the sidebar, which lists every investigation across your sessions with filters for time range, severity, stream, machine, session, destination and rule.
• What one shows: each call in the chain in order, with its role (where the data came from, what was done to it, where it went), what it did, and the call behind it; the destination, and whether this machine had reached it before; the credential by kind and whether it was sent as authentication or in a request, never its value; why the chain might be routine; and which interceptor saw it.
• Observed and inferred: the calls and their order are observed. That the data read is what was sent is inferred, because Omnodex sees the calls, not the bytes they moved.
• When they appear: for activity through the MCP proxy, as the last call is recorded. For activity captured by agent hooks, when the session ends or at the next background pass, within about 15 minutes, after the calls have run.

On a plan without advanced rules, these findings are held back: the dashboard shows only a line below the connection graph saying how many there are, and sessions are scored from the findings shown. An advanced finding’s details show its tier as Pro. Each rule is explained in the Risk Library.

Managing sessions

The Activity page lists your sessions so you can archive the ones you do not want on the dashboard. Archiving only hides a session: collection and sync continue, and you can unarchive it later.

• Filters: show sessions active during a time range (a session counts when its activity overlaps the range), from one surface, or that used chosen MCP servers.
• Empty sessions: sessions with no calls, prompts, files or findings are hidden here and on the dashboard. Most are MCP proxy sessions an agent app started and closed without using. Tick Show empty sessions to list them.
• Actions: Open shows the session on the dashboard; Archive and Unarchive apply to one session. To change many at once, select them and use the buttons above the table.
• Pages: choose 25, 50 or 100 rows per page, or all of them. This browser remembers the choice.

Connection graph

The connection graph shows each stream, the surfaces in it, the MCP servers they reached and each server’s busiest tools. Servers a session had configured but never called are grouped under not called.

• Panning and zooming: drag to pan, and pinch, Ctrl+scroll or the + and - buttons to zoom. The graph stays where you leave it while new events arrive. Press the fit button to bring the whole tree back into view.
• Hide inactive: hides the not called groups and any surface or stream with no calls in the selected time range. The badge still counts every server, so it shows what is hidden. This browser remembers the setting.
• Selecting a node narrows the rest of the dashboard to it. Select it again, or click an empty part of the graph, to clear it.

Where each session came from

Every session is labelled by the runtime it came from and, for sessions the MCP proxy captured, the connector that captured it. The same labels appear in the session list, the source filter, the session breakdown, the connection graph, the Activity page and session details, and they match the local dashboard.

Label	Meaning
Claude Code, Codex, Antigravity	Captured by that agent’s hooks
Cowork Cloud	A Cowork task that ran in the cloud, captured by its container hooks
Cowork via MCP Proxy (and other runtimes)	Captured by the MCP proxy for a known runtime: Cowork Desktop, Codex (including ChatGPT Desktop’s Codex mode), Antigravity or Claude Code. The runtime comes from the MCP client’s own name when it identifies one (Claude Code, Codex, Antigravity), and otherwise from the Omnodex plugin that started the proxy, as for Cowork in the Claude desktop app.
Client name via MCP Proxy	Captured by the MCP proxy for another MCP client, labelled with the name the client gave itself
MCP Proxy	Captured by the MCP proxy with no client name, or uploaded by a CLI version from before it kept one

The source filter treats each label as its own source, so Cowork and Codex sessions captured by the proxy can be viewed separately.

Session names

The session list, the Activity page and the session picker name a session by its title when it has one, with the project folder as secondary text, and by its project folder otherwise. Session details show the title as its own field. A rename reaches the dashboard after the next prompt in that session.

Calls routed through the MCP proxy

When an agent reaches an MCP server through the Omnodex proxy, the call is recorded by the agent’s hook and by the proxy. Every sync pairs the two before it encrypts, and the dashboard shows one call, in the agent’s session, with both sources named. A finding both raised on that call is counted once. Between syncs, the live view can show a routed call twice until the next upload from that host.

Multiple machines

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 stream secret. Both must be set as environment variables (or passed via --token and --secret flags):

# On Machine A
export OMNODEX_API_TOKEN="your-token"
export OMNODEX_STREAM_SECRET="your-stream-secret"
omnodex sync

# On Machine B (same credentials)
export OMNODEX_API_TOKEN="your-token"
export OMNODEX_STREAM_SECRET="your-stream-secret"
omnodex sync

If you manage multiple data streams from your dashboard account, each stream has its own API token and stream secret. 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. See Several Omnodex homes in one view.
• 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

• Streams and Stream Controls: what each action in Settings does
• Pausing Recording and Uploads: stop capture or uploads on a machine
• CLI Commands: connect, sync and status
• Configuration: stream settings and machine labels
• Local Dashboard: the dashboard on your own machine