tui: durable event logging multiplies global events across every client #36446

Summary

Every TUI logs every durable event from the process-global event stream at INFO level. Because all clients write to the same log, event-heavy activity is multiplied by the number of connected TUIs, producing hundreds of duplicate log lines per second and rapid log growth.

Environment

• opencode version: 0.0.0-next-15330
• OS: macOS 25.5.0 / Darwin 25.5.0 arm64
• Terminal: WarpTerminal v0.2026.07.01.09.21.stable_01
• Shell: /bin/zsh
• Install/channel: next
• Active plugins: ~/.config/opencode/plugins/share-with-team.ts, the local debug workspace plugin, and @warp-dot-dev/opencode-warp

Reproduction

1. Start several TUI clients against the same managed v2 daemon.
2. Run one tool-heavy session that emits reasoning, text, and tool lifecycle events.
3. Inspect ~/.local/share/opencode/log/opencode.log and group durable event lines by client run ID.

Expected Behavior

Normal INFO logging remains bounded and useful regardless of the number of connected TUI clients. Connection lifecycle events may remain at INFO, but dense per-event diagnostics should not be duplicated into the shared log by every client.

Actual Behavior

packages/tui/src/context/sdk.tsx logs every durable event with:

log.info("event", {
  type: event.value.type,
  aggregateID: event.value.durable.aggregateID,
  seq: event.value.durable.seq,
})

Each TUI consumes the process-global /api/event stream, so one server event is written once per connected client.

With ten concurrent TUIs:

• The shared log reached 628.6 MB.
• It grew at approximately 206 lines per second during observation.
• The last 5,000 lines repeated the same event classes across ten client run IDs.
• That sample included 667 session.tool.input.started, 652 session.tool.input.ended, 652 session.reasoning.ended, 651 session.tool.called, and 632 session.reasoning.started lines.

Additional Context

The live daemon had one expected SSE connection per TUI. This is client-side log multiplication, not duplicate subscriptions within one TUI.

Potential fixes include moving durable per-event logs to DEBUG, sampling them, or emitting event diagnostics once at the server. Connection and reconnection lifecycle logs should remain at INFO.