Monitor OpenCode agents

OpenCode can export its native OpenTelemetry traces and logs directly to Blop. The Blop launcher owns the collector endpoint for each OpenCode process, so the setup works in regular shells, tmux sessions, and agent worktrees without changing shell or Home Manager configuration.

Set up OpenCode

Install the CLI globally, then run the one-time setup command:

$ npm install --global @blopai/cli
$ blop setup opencode

The command performs four safe, repeatable actions:

1. Finds OpenCode on PATH or in its standard user install directories.
2. Enables experimental.openTelemetry in the OpenCode JSONC config while preserving comments and unrelated settings.
3. Reuses a healthy Blop collector or starts an identity-verified background collector.
4. Saves the selected executable, endpoint, config path, and namespace for the launcher.

If port 27686 belongs to another service, setup leaves that process alone and selects the next free local port. Pass --port 27690 to require a specific port. Setup fails rather than overwriting invalid JSONC or stopping an unrelated process.

Note

OpenCode’s telemetry setting is experimental and can change upstream. Blop validates the installed executable during every launch, keeping a future OpenCode change visible instead of hiding it in a shell profile.

Launch monitored agents

Start OpenCode through Blop after setup:

$ blop opencode

Everything after blop opencode is passed to OpenCode unchanged. This works for interactive sessions and non-interactive agent runs:

$ blop opencode run \
    --model openai/gpt-5.6-luna \
    --title "checkout investigation" \
    "Find the source of the checkout timeout"

The launcher injects the selected OTEL_EXPORTER_OTLP_ENDPOINT only into the OpenCode child process. It also adds service.namespace=opencode-agents unless you already supplied a namespace. It does not edit .zshenv, .bashrc, Home Manager, tmux, or system-wide environment settings.

Identify teams and environments

Add standard OpenTelemetry resource attributes before launching an agent. Blop preserves them and only fills in a missing service namespace:

$ OTEL_RESOURCE_ATTRIBUTES="service.namespace=platform,blop.team=payments,deployment.environment.name=production" \
    blop opencode

Use stable, low-cardinality values for team and environment names. Avoid putting secrets, prompts, customer data, or issue descriptions in resource attributes because they are stored with every matching span and log.

Verify the connection

Run a real OpenCode agent turn, then query the collector:

$ blop status
$ blop services --since 15m
$ blop traces --service opencode --since 15m
$ blop logs --service opencode --since 15m

Commands such as opencode --version only validate the launcher; they do not create agent telemetry. A model-backed turn is the end-to-end verification.

Agents should use JSON output when they investigate themselves:

$ blop traces --service opencode --status error --since 15m --json
$ blop audit --service opencode --fail-on regression --json

Use an existing collector

Set BLOP_MONITOR_URL before setup to require a specific healthy Blop collector. Blop validates the service before saving it:

$ BLOP_MONITOR_URL=http://127.0.0.1:27690 blop setup opencode

The local setup record defaults to ~/.config/blop/opencode.json on Linux. BLOP_OPENCODE_SETUP_PATH, BLOP_OPENCODE_BIN, OPENCODE_CONFIG, and the XDG directory variables can override discovery for managed environments.

Remove the integration

Stop the managed collector with blop monitor stop. To disable future export, set experimental.openTelemetry to false in the OpenCode config and stop launching OpenCode through blop opencode. Blop never removes or rewrites other OpenCode settings during cleanup.