← Back to articles

Adding Grok support to Mission Control

4 min read
  • Mission Control
  • Grok
  • Observability
  • Claude Code
  • Codex
  • AI tooling

Mission Control already knew how to watch Claude Code and Codex: desktop collectors tail JSONL session files and push sessions, activities, and usage into a shared ingest API. Grok Build CLI was part of day-to-day agent work for me, including through grok-plugin-cc, but it did not show up in the dashboard at all.

That gap is closed now. Grok is a registered source, with the same filter, traffic lights, and list views as the other agentic tools. The code lives in BenBish/mission-control. For the broader product story after the OpenClaw pivot, see the earlier Mission Control write-up.

What was missing

The multi-source model only helps if each tool you actually use has a collector. Claude Code and Codex had JSONL scanners. Hermes and ComfyUI had pollers. Grok session data sat under ~/.grok/sessions/ and never crossed the ingest boundary.

Without a source entry, there was nothing useful to filter on. Without a collector tick, the dashboard could not show green/grey status for a Grok instance. Token totals and session history for Grok work were invisible next to Claude Code and Codex.

Collector shape

The Grok collector mirrors the Claude Code / Codex desktop pattern:

  1. Glob session update files under ~/.grok/sessions/*/*/updates.jsonl.
  2. Scan with an offset cursor (scanJsonlFile) so restarts do not re-emit the whole history.
  3. Parse ACP-shaped session/update records for tools and conversation, plus _x.ai/session/update usage counters.
  4. Merge a per-session snapshot from summary.json / signals.json when present.
  5. Batch POST sessions and activities to the hub ingest endpoint.

Source id is grok. The seeded desktop instance is grok@arch-desktop with collector kind jsonl-push. If no session files exist, the tick reports off with a clear detail string instead of inventing empty success.

Pricing is deliberately conservative. Known model ids like grok-4.5 are registered in the static table so the UI can recognize them, but fallback rates are zero until official token prices are verified. Prefer usage counters from the logs over fabricated dollars.

What it looks like running

On a live hub, Source Health and the source picker treat Grok like every other instance. Green means the collector has checked in recently. Grey means off or not seen.

Mission Control source filter open, with Grok selected and green status alongside Claude Code, Codex, Hermes, and other sources; Source Health card shows Grok healthy without internal activity noise

Filter the dashboard to Grok and the Sessions and Activities pages become Grok-only. Sessions show duration, turns, success rate, and tokens. Activities show tool calls, messages, and usage events keyed to Grok session ids.

Sessions page filtered to the Grok source, listing only grok sessions with turns, success rate, and token totals

Activity feed filtered to Grok, with grok agent tool calls, messages, and usage events

That is the main operator win: the same presets and traffic lights you already use for Claude Code and Codex now apply to Grok Build sessions.

Implementation notes worth keeping

Parse what is on disk, not only what docs imply. Grok stores one directory per session (encoded cwd, session id) with updates.jsonl as the incremental stream. Field shapes were checked against real local session files.

Dedupe still owns redelivery. Collectors may rescan after a crash. Natural keys on the hub keep session upserts and activity inserts from double-counting.

Status is part of the product. An ok / off light for grok@… is more honest than a silent missing row. Empty Grok history should look like an idle source, not a broken UI.

UI did not need a special Grok page. Seeding the source and instance is enough for the shared source filter and list routes. Frontend special-casing would fight the multi-source design.

Status

Grok support is on Mission Control main as a first-class agentic source: collector, seed data, pricing stubs, and tests for parser and empty-path collector behavior. Docs and the desktop collector service unit mention Grok next to Claude Code and Codex.

If you run the desktop collector on a machine with Grok Build installed, session files under ~/.grok/sessions/ should start showing up on the next tick. If you do not use Grok on that box, the instance stays off until files appear. That is the intended empty state.

Takeaway

The pivot to multi-source Mission Control only stays useful if new day-to-day tools get the same boring treatment: discover the log path, scan incrementally, register a source, light a status LED, and let the existing filters do the rest. Grok was the obvious next agentic source after Claude Code and Codex. It now behaves like one.