GuidesPrivacy & controlSending a diagnostic report
Beginner3 min read

Sending a diagnostic report

What a diagnostic report contains, what is deliberately stripped out of it, and when it helps support.

When something misbehaves — a dead microphone, a wake word that stops responding — a diagnostic report gives support the state of your machine without asking you to paste log files around.

SettingsAccountSend Diagnostic Report
Reports are only ever sent when you press the button. Nothing is collected or transmitted in the background.

What goes in

  • Audio device information and the state of internal services
  • System information and whether GPU inference is active
  • Recent log lines — warnings and errors only
  • Recent watchdog events and feature flags
  • The number of workspaces you have, not their contents
  • Microphone and accessibility permission status
  • Native crash events from the last 14 days, if any

What is deliberately excluded

No transcriptions, no dictated text, no file contents. This is enforced in code rather than left to a filter: the report is hard-limited to warning-level logs and above, specifically because the dictation pipeline writes verbatim speech at info level. Including info logs would leak everything you had said.

The remaining free-text log lines are passed through a sanitiser before sending. The only user-chosen strings that survive are audio device names, which are needed to diagnose the most common class of bug.

After you send

You get a support reference ID — quote it when you contact us. If the upload fails, the dialog offers to copy the report so you can attach it manually. Sending is limited to three reports per day.

The dialog can also run a live microphone test and a wake-word test. The voice test never injects text into whatever app is focused, so it is safe to run with your cursor anywhere.