An open-source Sentry alternative built for AI-written code
Sentry is built around what the code threw, with a User Feedback widget and replay alongside. Mushi starts from what the user reported, ingests Sentry’s errors too, explains each one in plain English, and hands your agent a fix prompt to start from. One queue, with or without Sentry. If your app was largely written by Cursor, Claude Code, or another agent, that’s the answer you actually need — you didn’t write the code, so a raw stack trace costs you an afternoon of archaeology.
Mushi is open source (MIT SDKs, AGPLv3 server), works standalone, and turns a user’s bug report — or a Sentry error alert — into a plain-English diagnosis with a fix you can paste into your editor.
Instead of Sentry, or alongside it — your call
Run Mushi instead of Sentry if user-felt friction is what you care about: broken buttons, dead flows, confusing states, plus the thrown errors the SDK captures along the way. Run Mushi alongside Sentry to keep crash-level telemetry, performance tracing, and release health where they are — and point a Sentry issue-alert webhook at Mushi so every error still lands in the one queue, deduped and diagnosed, with the fix resolving the Sentry issue when it merges (3-step setup). Both paths are first-class; neither asks you to rip anything out.
Side by side
| Question | Sentry alone | Mushi |
|---|---|---|
| What it sees | Errors and performance, plus Session Replay and a User Feedback widget | User reports from the widget with a screenshot, plus the errors Sentry catches, in one queue |
| What lands in your queue | A stack trace (the technical record of where the code failed) | A short user note plus the screenshot they were looking at |
| Repeat bugs | Repeat events of the same error group into one issue | Repeat user reports of the same broken button collapse to one row, even when nothing threw |
| What you learn from fixes | A resolved issue reopens as a regression if it recurs; there is no lessons file for your editor | Past fixes become rules your editor sees on the next PR (.mushi/lessons.json) |
| Closing the loop | Resolve by hand, from a commit that references the issue, or in a release; Seer, the paid AI debugging add-on, is on Team and above | A draft PR from your agent; merging it resolves the linked Linear issue, and the linked Sentry issue once the Sentry plugin is on (Indie and above, or self-hosted) |
| Reporter attribution | The user you set with setUser, or the name and email on a feedback submission; no credit when it is fixed | "Fixed by Kenji" in the changelog and an SDK toast, once Releases is enabled |
| From your IDE | Sentry's MCP server lets Cursor or Claude Code read issues and ask Seer | Cursor reads the report and the relevant lessons, then proposes the code change |
| Where it runs | Their cloud, or yours with getsentry/self-hosted (no Seer) | Yours, ours, or both |
What “diagnosis” means here
When a report lands, Mushi reads the report, the screenshot, and your repo, then writes what broke and why in the language you’d use to explain it to a teammate — plus a fix prompt scoped to the files involved. Twenty reports about the same broken checkout button collapse into one row, and past fixes become lessons your editor sees on the next PR.
Try it on your app
One command detects your framework, installs the SDK, and writes your env vars:
npx mushi-mushiThe free tier includes 50 diagnoses a month with no card, and you can self-host the whole stack with one command if you’d rather keep everything on your own infrastructure.
Next: Run the incident-loop quickstart or connect your editor over MCP.