Skip to content

Crash Reporting and Feedback

When Polytoken exits unexpectedly, it sends a crash report to the Polytoken team. The report helps diagnose and fix the problem that caused the exit.

A crash report includes the crash type, the error message, a stack trace with file paths reduced to component names, the component that crashed, the Polytoken version, the operating-system family, the CPU architecture, and your pseudonymous installation ID.

Polytoken does not automatically attach daemon logs, session records, prompts, tool or conversation data, environment variables, breadcrumbs, or files to a crash report. Even after scrubbing, crash details may contain incidental paths or user-derived fragments that the scrubbing process cannot predict.

Automatic crash reporting is on by default once your user or global config loads successfully. If your global config is missing, unreadable, or malformed, crash reporting stays off. This fail-closed design means a broken configuration never silently sends reports.

A successfully configured headless daemon (one started by the CLI with a valid config) has crash reporting on by default. The only way to turn automatic crash reporting off is data.automatic_crash_reporting = false in your global config.

The data.automatic_crash_reporting key is global-only. Project configs may not set or erase it. Polytoken rejects any attempt to write this key from a project config layer.

To turn automatic crash reporting off, add the following to your global config:

[data]
automatic_crash_reporting = false

To review or change this setting interactively, open the Configurator and select the Data tab.

On first start, when automatic crash reporting is enabled, Polytoken shows a blocking privacy notice. The notice discloses the data a crash report includes, the pseudonymous installation ID, the United States storage region, and a link to the Sentry Privacy Policy.

The notice is informational. Continuing past it records only that this version of the notice was shown. Your crash-reporting setting does not change when you continue.

The notice is versioned. When the disclosures change materially, the notice reappears so you can review the updated content.

The installation ID is a random, machine-local identifier Polytoken uses to correlate reports from the same installation. This identifier does not encode your name, email address, hostname, or account.

Submitted event data, including crash reports and feedback, is stored in the United States.

Type /feedback in the prompt to open a feedback form. The form has three focus areas: a text editor for your message, a list of optional diagnostic artifacts, and a send button.

Set POLYTOKEN_DISABLE_FEEDBACK=1 before launching Polytoken to remove /feedback from typeahead and slash-command handling. Relaunch the TUI after changing the variable.

Type your message in the editor. Before submission, Polytoken scrubs typed text for obvious secrets, replacing recognized credential patterns such as API keys, bearer tokens, and password assignments with [REDACTED]. The scrubbing does not touch diagnostic attachments: those are sent raw and unsanitized, because Polytoken cannot predict what a log file or session record may contain. You consent to sending raw attachments on the final send screen before Polytoken transmits anything.

The text editor accepts up to 16 KiB of UTF-8 text. You must type a message before you can send feedback.

When you open the feedback form, Polytoken retrieves a catalog of available diagnostic artifacts from the active daemon. You can optionally upload a daemon or session log with your feedback.

After you submit, Polytoken shows one of three outcomes:

  • Submitted: Polytoken queued the event and the local flush completed.
  • Delivery unconfirmed: Polytoken queued the event locally but could not confirm the delivery service received it. The event may or may not arrive.
  • Not sent: the submission failed before Polytoken queued anything. Nothing was transmitted. You can edit and try again.

Polytoken does not promise delivery, retention, grouping, retries, queueing, or support follow-up.

Feedback carries an optional installation tag Polytoken reads from the local telemetry state. The tag is the same pseudonymous installation ID used in crash reports. If the telemetry state is unavailable, Polytoken omits the tag.

Explicit feedback submission never repairs or attaches the installation ID if it was missing. Polytoken includes the tag only when the existing installation ID is valid.