Skip to content
OpencodeView

Overview

What OpencodeView is, what it deliberately is not, and how it relates to OpenCode.

OpencodeView is a local, read-only companion to OpenCode. It does not implement agents, does not write OpenCode's database, and does not host multi-tenant analytics. It reads the session store already on your disk, derives aggregates into a cache of its own, and serves a dashboard bound to loopback.

Canonical source ↗

What it plugs into

OpencodeView sits downstream of two projects it does not own. One is required, one is optional, and neither is affiliated with it.

  • OpenCode

    Required

    OpenCode owns the agent runtime and the on-disk database that OpencodeView reads. Schema evolution belongs to them, so the SQLite adapter here is best-effort and may lag upstream migrations. When source data looks wrong, that is where it should be investigated — flags on this side are local operator heuristics, not statements about OpenCode.

  • oh-my-openagent

    Optional

    An agent harness for OpenCode, also known as omo. When its activity log is readable, the server overlays per-session poll telemetry onto the Live lens: the suspect health state, and terminal events such as poll_timeout, max_turns, aborted_by_user and terminal_error. The omo_metadata_bug flag also originates here. Everything else works without it.

Both are third-party projects. OpencodeView is not affiliated with, endorsed by, or maintained by either.

Five invariants, enforced in code

Not a policy page. These are assertions the process makes at startup and on every request.

  • Local-first

    Default bind is loopback. The app opens no outbound socket and ships no telemetry. Your session history never leaves the machine that produced it.

    OPENCODEVIEW_HOST=127.0.0.1
  • Read-only source

    The OpenCode database is opened read-only at the engine level and pinned with a query_only pragma. OpencodeView structurally cannot write to it.

    readonly: true · PRAGMA query_only = 1
  • Separate cache

    Every derived metric lands in its own SQLite file. The cache path is checked so it can never be the same file, symlink or hardlink as the source.

    .cache/analytics.sqlite
  • Redact before leave

    Transcript and live payloads pass through server-side redaction before JSON leaves the process: secret-like keys, bearer tokens, provider prefixes, URL userinfo and absolute home paths.

    sk-… ghp-… → [REDACTED]
  • Fail closed

    Binding beyond loopback without an auth token is not a warning — the server refuses to start. Exposure is always a deliberate operator decision.

    no token + public bind → exit

Non-goals

Things this project has decided not to be.

  • Replacing OpenCode or shipping an official OpenCode UI
  • Claiming affiliation with or endorsement by the OpenCode team
  • Cloud or multi-tenant hosted analytics
  • npm and registry distribution or an installer — source-run only
  • A stable, versioned integration contract against opencode.db before 1.0.0

Known limitations

Documented up front, because you will hit them.

  • opencode.db is an internal OpenCode implementation detail — the adapter is best-effort and may lag upstream schema changes
  • cost is only comparable within the same billing regime; some auth modes report zero
  • Sessions from 2026-06 and 2026-07 have incomplete summary_additions coverage and get tagged data_quality_gap
  • Sessions that used legacy edit/write tools instead of apply_patch do not populate apply_patch counters
  • Expect breaking changes to the cache schema, API and CLI before 1.0.0