Anonymous error reporting: what we see of failures, never of your projects

An application reporting failures inevitably learns something about you. We detail the six pieces of information Maestro sends when a screen breaks, what never leaves your Mac, and the two times those records helped us.

Anonymous error reporting sends failure categories, never project contents. Maestro sends the version number, broken screen, and error type, according to our August 2026 operational notes. It is enabled by default and disabled with a checkbox in settings.

What leaves when something breaks

There are two families of records and nothing else. At application launch: a randomly generated installation identifier created the first time, version number, date, and time. When a screen fails to appear: that screen's name and encountered error type. The identifier contains neither name nor address; it distinguishes three failures on one machine from failures on three machines. These records enter an online database we maintain, and none of your work follows that path.

What never leaves

Your work stays with you: approved brief, specification, agent-written code, attached documents, and conversation history with the team. Assistant access keys live in macOS Keychain and do not leave it. We receive no project names, screenshots, or message text either. We know a screen broke, not what it displayed. Details appear on our data page.

The blocked tester we saw without seeing their screen

In August, our first beta tester never reached the second screen: the application could not find the AI assistant they used daily. Reporting gave three facts only: they ran the first published version, opened it three times in under an hour, and stopped at the same place each time. A morning of reasoning found the cause, not a database row: the application searched where Finder looks, while the assistant was installed elsewhere. Anonymous reporting locates a failure; it does not diagnose it.

The day those records made us roll back

In late August, a morning release broke every project's opening, showing an apology instead of the workshop. The first incoming records named the faulty screen and error type within minutes. We restored the previous version in under a minute, fixed the issue, and published that morning. Without those records we would have waited for a tester's message, then requested reproduction, costing a day for someone who only wanted to work.

Why it starts enabled

A failure experienced by nobody does not exist to us. An invitation beta has few testers, and some encountering defects never write: they close the application and move on. The opposing argument is defensible, and several tools we respect ask permission before first transmission; that is the cleanest user choice, and we do not consider it absurd. We chose default reporting with content reduced to what cannot identify you or your work. The same reasoning led to publishing the postmortem of the key visible in code: hidden defects do not get repaired.

Disable reporting, or write

Open settings and uncheck anonymous reporting; transmission stops. The exact field list is on our data page so you can decide with it in hand. If a defect costs an evening, write rather than waiting for reporting to speak: a category tells us a screen broke somewhere, while your message tells us what you were doing, worth ten database rows.