anomalyco / anomalyco/opencode

Feature: centralized Error Viewer / diagnostics — startup error sounds are not discoverable in the UI

Open
#41,194 4 comments 1 reaction 1 assignee View on GitHub

@Hona is already working on this.

Since Aug 8, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Problem

On the Windows desktop app, every app launch plays multiple "error" sounds (e.g. 3 beeps shortly after opening the window) with no corresponding visual indication — no error toast, no red banner, no bell notification. The user cannot find out what failed. We had to dig through raw log files manually to find the underlying errors.

The error sound is currently only triggered by the session.error event (see packages/app/src/context/notification.tsxhandleSessionError), which requires an active session. But these sounds occur right at startup, before any session is started, which suggests errors from the startup phase (MCP server connection failures, plugin load failures, updater failures, etc.) are being surfaced only as sound or not surfaced at all.

Evidence from logs (Windows)

App: Desktop 1.18.15 (packaged), logs under %APPDATA%\ai.opencode.desktop\logs\<timestamp>\ and %USERPROFILE%\.local\share\opencode\log\opencode.log.

Startup phases we observed that produce errors with no visible UI:

  1. MCP server connection failuresopencode.log:

    level=WARN message="server unavailable" key=github type=remote status=failed
    level=WARN message="server unavailable" key=cloudflare type=remote status=failed
    

    These appear as a batch at startup. There is no error panel / notification in the UI that shows which MCP server failed and why (other than digging into the Servers settings tab).

  2. Plugin load failuresopencode.log:

    level=ERROR message="failed to load plugin" path=... error=ENOENT ...
    level=ERROR message="failed to load plugin" path=harness-memory error="Class constructor ActivationEngine cannot be invoked without 'new'"
    

    Only visible in logs. The plugin list in the UI does not show load failures.

  3. Model/provider API errors (stream error, connect timeouts) only play a sound via session.error; the bell icon shows a red dot only if you know to look.

When the user hears error sounds at startup with zero UI hints, the only way to diagnose is manual log reading — this is a major UX gap.

Feature request

Add a centralized Error / Diagnostics viewer to the desktop app (and TUI), e.g. an "Errors" or "Diagnostics" panel/page that aggregates, in real time:

  • MCP server connection failures (which server, error, timestamp, retry status)
  • Plugin load / init failures (plugin path, error, timestamp)
  • Model / provider API errors (stream error, timeouts, HTTP errors)
  • Updater errors
  • Startup-time errors (server boot, sidecar, renderer)

Requirements:

  • Errors should be visible in the UI (list + details), not just a sound.
  • Each error should be timestamped and linkable to the relevant log lines.
  • Optionally, when an error sound is played, always pair it with a visible toast/notification so users can find the cause.
  • Log viewer integration (read recent opencode.log entries with level filter) would be a nice extra.

Why this matters

Right now "an error happened" is communicated by sound alone in several startup scenarios, making it impossible to self-diagnose. A first-class error center would let users (and support) identify MCP/plugin/model failures in seconds instead of manually grepping logs.

Environment

  • Windows (desktop app, packaged build 1.18.15)
  • Many global MCP servers (github, cloudflare suite, mysql, sqlite, memory, context7, ...) + several plugins (wakatime, power-pack, goal, harness-memory, ...)
  • Startups with any slow/failing MCP or plugin reproduce the sound-only behavior

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.