Crash Reporting and Feedback
Automatic crash reporting
Section titled “Automatic crash reporting”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.
Default-on behavior
Section titled “Default-on behavior”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.
Global-only config
Section titled “Global-only 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 = falseTo review or change this setting interactively, open the Configurator and select the Data tab.
First-start privacy notice
Section titled “First-start privacy notice”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.
Installation ID
Section titled “Installation ID”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.
Data region
Section titled “Data region”Submitted event data, including crash reports and feedback, is stored in the United States.
Sending feedback with /feedback
Section titled “Sending feedback with /feedback”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.
Diagnostic artifacts
Section titled “Diagnostic artifacts”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.
Submission outcomes
Section titled “Submission outcomes”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.
Installation tag
Section titled “Installation tag”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.