Skip to content

Logs and diagnostics

The /logs view (System health in the application) aggregates logs from container environments and host services into a single real-time stream. It includes a system health status bar and provides tools to package diagnostics for bug reports.

If you already know the cause of an issue, consult the Troubleshooting guide. Use this view when you need raw log data or a diagnostic bundle.

  1. Open /logs. The status bar displays overall health (healthy or degraded) alongside indicators for vm, containers, ide_bridge, and mcp_os.
  2. Click the overall status indicator to expand detailed metrics: individual container names, operating states, and detected IDE instances with their bound ports.
  3. If Speedwave detects an IDE instance that has not yet been connected, the ide_bridge section displays a connect → link to the Integrations panel. See IDE Bridge for functional details.
  4. Click refresh to force an immediate status update without waiting for the automatic 5-second polling interval.
  1. Below the status bar, the log view displays a live merged stream of events (showing the last 500 lines by default). The stream refreshes every 5 seconds and automatically auto-scrolls to the newest entries.
  2. Use the log level filters (all, debug, info, warn, error) to refine the visible output.
  3. Use the source selector to isolate entries from a specific component (each listed with its line count).
  4. Hover over any timestamp to inspect its raw value; displayed times reflect your local system timezone.

Speedwave records events at trace level by default without toggle requirements, ensuring diagnostic exports always contain comprehensive technical context without needing to reproduce issues with increased verbosity. A small number of verbose third-party libraries are limited to warn level to keep the log stream readable.

On desktop systems, logs are written to disk at ~/Library/Logs/pl.speedwave.desktop on macOS and %LOCALAPPDATA%/pl.speedwave.desktop/logs on Windows. Log files rotate upon reaching 50 MB, retaining the 10 most recent segments.

PII tokenization maintains independent per-project audit logs on disk: ~/.speedwave/audit/<project>/audit-proxy.jsonl records matches detected in outbound requests sent to the model provider, while audit-hub.jsonl logs detections from integration responses. Entries record matched rules and counters without storing original data values. See Tokenization for detection mechanics.

When ANTHROPIC_LOG=debug is configured, raw Claude Code SDK network traffic is captured. Rather than printing multi-line payloads, Speedwave condenses requests and responses into structured one- or two-line summaries tagged with a [log_ID]:

-> POST /v1/messages (model=claude-opus-4, max_tokens=4096, stream=true, messages=12) [a1b2c3]
<- 200 /v1/messages (content-type=text/event-stream, from api.anthropic.com, in 842ms) [a1b2c3]

The SDK emits responses in three distinct chunks; Speedwave combines these into a single consolidated entry. Unrecognized data passes through untouched.

The export diagnostics action packages application logs, container logs, and system metadata into a sanitized ZIP archive, stripping all secrets and authentication tokens. This action is disabled during archive generation and when no project is currently open.

  1. In the /logs view, click export diagnostics. The button displays “exporting…” while the archive is generated.
  2. Upon completion, a Diagnostics archive saved dialog appears showing the destination file path.
  3. Click copy path to copy the archive path to your clipboard, then click close.
  4. Share the archive with support or attach it to your bug report. Archives are never uploaded automatically.

The ZIP archive is saved in your Downloads directory (falling back to your home directory) with the naming format speedwave-diagnostics-<unix-timestamp>.zip.

  • Directoryspeedwave-diagnostics-<timestamp>.zip
    • Directorylogs/
      • *.log application log files
    • Directorycontainers/
      • compose.log container and Docker Compose logs
      • compose.yml project compose definition
    • Directorymcp-os/
      • mcp-os.log host OS service logs (if present)
    • Directoryclaude/
      • claude-session.log Claude Code session logs (if present)
    • Directorylima/
      • serial.log Lima serial console logs (macOS only)
    • system-info.txt OS, CPU architecture, app version, and claude_pinned version

Single-file sources (such as OS service logs, Claude session logs, and Lima serial.log macOS only) are included only when present on the system.

Before creating the ZIP archive, Speedwave’s log sanitizer replaces all sensitive credentials with ***REDACTED***:

CategoryDetection patterns
API keysAnthropic (sk-ant-...), Google (AIza...), generic sk-*
Git tokensGitHub (ghp_, ghs_, gho_, ghu_, github_pat_), GitLab (glpat-), Atlassian Cloud
Messaging tokensSlack (xoxb, xoxp, xoxa, xoxr, xoxs, xoxe)
Auth headersAuthorization/Bearer headers, Set-Cookie/Cookie, JWT tokens, URL userinfo parameters
Other sensitive valuesPrivate PEM keys, local username paths, parameters named password/secret/api_key/token, X-Redmine-API-Key, OTEL exporter headers

Crash payloads that cannot be safely parsed as plain text are replaced with unknown panic payload to prevent potential credential leakage. The token directory is never included in the archive. The sole exception is system-info.txt, which contains unredacted operating system, architecture, application version, and pinned Claude Code version information.

If you encounter version mismatches, verify the claude_pinned entry in system-info.txt. Speedwave relies on pinned versions, so discrepancies typically indicate that the claude container requires rebuilding. See Troubleshooting for resolution steps.