Local Dashboard

This page covers the dashboard you run on your own machine with omnodex dashboard. It is included in every tier and does not require an account. For the dashboard at dashboard.omnodex.com, see Hosted Dashboard.

Starting and stopping

omnodex dashboard

Open http://localhost:7890 in a browser on the same machine. To use another port, pass it as the first argument: omnodex dashboard 8080.

On start, the dashboard:

1. Runs detection on any sessions that have not been analyzed (skip this with --no-detect).
2. Rebuilds its read model from the event log in every configured root.
3. Pairs calls that both a hook and the MCP proxy recorded (see Calls routed through the MCP proxy).
4. Starts tailing each root, so new events appear as they are recorded.

Press Ctrl+C to stop it. It closes the event logs and its database before it exits. If the port is already in use, the command says so and exits instead of starting.

On a host connected to the hosted dashboard, a running omnodex dashboard also encrypts new events and streams them there. See Cloud streaming.

Who can reach it

The dashboard shows everything your agents did, including tool parameters and file paths, so it only answers a browser on the same machine:

• It listens on the loopback addresses (127.0.0.1, and ::1 where IPv6 is available), so other machines on your network cannot connect to it.
• It answers only requests addressed to localhost, 127.0.0.1 or [::1], and only from its own page. Other websites open in your browser cannot read it.

There is no setting to open it to your network. To see your activity from another device, use the hosted dashboard, which encrypts your data before it leaves the machine.

Platform notes

macOS / Linux

Nothing platform-specific. The default Omnodex home is ~/.omnodex.

Native Windows

Run omnodex dashboard in PowerShell. The default Omnodex home is C:\Users\<you>\.omnodex. Ctrl+C, Ctrl+Break and closing the console window all stop it cleanly.

WSL

Run omnodex dashboard in a WSL terminal and open http://localhost:7890 in a Windows browser. WSL forwards localhost to Windows. If the page does not load from Windows, check that localhostForwarding is not set to false in your .wslconfig.

The WSL dashboard reads the WSL home (/home/<you>/.omnodex) by default. To include agents that run on Windows, such as Cowork, add the Windows home as an extra root. See Several Omnodex homes in one view and Windows and WSL.

Several Omnodex homes in one view

If you run several agent surfaces on one machine, such as Cowork on Windows, Claude Code in WSL and Codex in a terminal, each may write to its own Omnodex home. The local dashboard can read all of them at once and merge them into one view.

Extra homes are called roots. The default home (~/.omnodex, or $OMNODEX_HOME) is always included, so list only the extra ones.

To add them for every run, put them in ~/.omnodex/config.json:

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

The first entry 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.

To add them for one run, pass --roots (space-separated for several):

omnodex dashboard --roots /mnt/c/Users/you/.omnodex

Each root keeps its own event log. The dashboard reads each one, merges them into a single read model in the default home, and records which root each session came from. It only reads the other roots; it never changes their events.

What each panel shows

The session selector at the top chooses between All Sessions and a single session. Every panel below follows that choice and the filters. Sessions are listed by title, with the project folder after it, or by project folder when a session has no title. A session with no activity (no calls, file events, prompts, findings or subagents) is not listed or counted; most are MCP proxy sessions an agent app started and closed without using.

Filters

Below the session selector:

• Runtime, status and risk: show only sessions from some runtimes, with some statuses, or whose risk reaches a level.
• Time range: the last hour, day, week or month. Calls, file events and findings outside it are left out, and the stats row counts only what is shown.
• Root: appears when the dashboard reads several Omnodex homes, to show one or some of them.
• Graph selection: selecting a node in the connection graph narrows every panel to it. It shows as a chip; select it, or Clear filters, to remove it.

To hide a session you do not want to see, select it and choose Hide session. Hidden sessions stay in your data; this browser just leaves them out until you tick Show hidden or unhide them. Hiding, the theme and the time zone are remembered in this browser only.

Session overview

The session’s title, which agent runtime it ran in, its status, user, project, start and last-event times, and the MCP servers it used. Where the MCP proxy recorded how a server is reached, the server is listed with its transport, for example docs (http: docs.example.com).

The runtime label comes from the platform the capture recorded, or from the interceptor when no platform was recorded. The hosted dashboard uses the same labels:

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 recorded by a proxy version from before it kept one

Connection graph

What the agents connected to, as a tree: each runtime on the left, the servers it called on the right (Built-in tools for the agent’s own tools, such as shell commands and file edits), and each server’s busiest tools with their call counts. Servers a session had configured but never called are grouped into one idle servers node per runtime.

Select a runtime, a server or a single tool to narrow the whole page to it; select it again to clear it. The graph itself keeps showing everything, so you can move the selection.

Risk findings

Each finding with its severity, rule and description, newest first in All Sessions and in the order detected for a single session. Select one to see the call that triggered it and, in the detail panel:

• Pattern: for a rule that matches a sequence of calls, every call in the sequence, earliest first.
• Risk Library: Learn more about this risk type opens the rule explanation in a new tab, with an external-link indicator. The link is the last detail field before related tool-call details. It includes the rule ID, without the session, tool parameters, or other event data. Rules not yet covered by the library open its rule index. Opening the explanation requires network access to the documentation site.

Findings from advanced rules, which come with Omnodex Pro, are not listed here. One line below the connection graph says how many the view holds: on a Pro plan it points you to the hosted dashboard, where each one and its investigation can be read; otherwise it says they come with Pro. Sessions that held them are scored from the findings shown. omnodex detect and omnodex report print the same count.

Event timeline

Every tool call in order, with its server, status and duration. A warning sign marks calls that triggered a finding, and newly arrived calls are highlighted for a moment.

Credential ledger

Credentials found in tool call parameters, such as bearer tokens, API keys, access tokens and passwords, one row per credential with a masked value, how many calls used it, and when it was last seen. Select a row to list every call that used it, and select a call to open it in the detail panel. Values that only look like credentials, such as ${API_TOKEN}, placeholders and documentation example keys, are left out. The ledger reads parameters, so it is empty for servers where redact_parameters is on.

File events

Files the agent read and wrote, newest first, with the path and size.

Tool calls

Every call in a table you can sort by time, tool, server, status, duration or response size. Select a row to open it in the detail panel.

Event detail

The selected call or finding in full. Parameters show as fields: long text, such as a file being written or a script, keeps its line breaks in a scrollable block instead of one escaped line. Show raw JSON shows the parameters exactly as recorded.

Theme and time zone

The buttons in the header switch between the system, light and dark themes, and between your local time zone and UTC.

Calls routed through the MCP proxy

When an agent reaches an MCP server through the Omnodex proxy, the call is recorded twice: by the agent’s hook and by the proxy, each in its own session. The dashboard pairs the two records and shows one call, in the agent’s session, with Observed by in its detail panel naming both. A finding that both raised on that call is shown once.

Pairing runs when the dashboard starts and again a couple of seconds after new calls arrive, so a routed call can briefly appear twice before it is paired.

Live updates

While the dashboard runs, new calls, file events and findings appear without a page refresh. The LIVE badge in the header shows whether the page is connected; if the connection drops, it reconnects on its own.

Next steps

• CLI Commands: every dashboard option
• Configuration: dashboard roots
• Hosted Dashboard: see this activity from any device