describe the feature

a first-party screenpipe pipe (or built-in app action) that turns any crash, quirk, or "i wish it did X" moment into a properly-formatted github issue on screenpipe/screenpipe — without the user ever leaving the app or having to remember to do it later.

concretely:

• trigger surfaces
  • "report a bug" / "suggest a feature" menu items in the tray + settings
  • auto-prompt on detected crash (parse the latest ~/Library/Logs/DiagnosticReports/screenpipe-app-*.ips and surface a "we crashed — file this?" toast)
  • keyboard shortcut + CLI: screenpipe report bug / screenpipe report feature
• respects the repo's issue templates
  • fetches .github/ISSUE_TEMPLATE/{bug_report,feature_request,documentation,question}.md from the repo (or ships them) and renders the exact sections (**describe the bug**, **to reproduce**, **expected behavior**, etc.) as a guided form
  • applies the correct labels (bug, enhancement, …) and title prefix ([bug], [feature], …) automatically
• auto-attaches the right artifacts (with explicit user consent / preview-before-send)
  • app version, OS + build, hardware model, locale, timezone
  • last N lines of screenpipe.log and the latest .ips crash report (with the faulting thread + binary images section)
  • relevant /health, /activity-summary, enabled pipes + versions, connected integrations (names only, no tokens)
  • for UI quirks: a screenshot of the active window at trigger time (already captured by screenpipe — just reuse the latest frame)
  • for "what was i doing when it broke": a 30s timeline excerpt around the crash timestamp
  • a redaction pass that strips home paths, emails, api keys, bearer tokens, sqlite paths before the preview
• dedup + lifecycle
  • before opening, searches existing open + recently-closed issues/PRs by crash signature (faulting symbol + thread name) and offers "comment on #NNNN instead" — exactly the workflow i had to do manually for [bug] Crash (SIGSEGV in onnxruntime) when auto-updater restarts app during audio-manager / speaker-model init #3557 / fix(updates): gate auto-restart on boot-ready to avoid ORT teardown SIGSEGV (#3622) #3660 today
  • on submit, stores the issue url locally + subscribes the user, so follow-ups land in the same notification surface
• submit path
  • uses the user's github oauth (already a supported connection) — no PAT juggling
  • if not connected, offers "open in browser with body pre-filled" as a fallback (the ?title=…&body=…&labels=… url scheme)

why is this needed?

right now every quirk, near-miss, or "huh that's weird" moment dies in the user's head, because:

1. filing a good issue is a 10–15 min job — grab the crash report, find the right log lines, figure out which template, write a clean repro, search for dupes. nobody does this for the small stuff.
2. when users do file, the reports are often missing the exact artifacts that would let a maintainer triage in 30s — see the .ips thread backtraces, the racing-thread context, the version string.
3. screenpipe is uniquely positioned to do this well because it already has the screen recording, the audio, the timeline, and the activity context that explain what the user was trying to do when it broke. that context is normally lost the moment the user closes the dialog.
4. concrete example from today: a SIGSEGV in onnxruntime on v2.4.288 turned out to be a known race ([bug] Crash (SIGSEGV in onnxruntime) when auto-updater restarts app during audio-manager / speaker-model init #3557, fix in fix(updates): gate auto-restart on boot-ready to avoid ORT teardown SIGSEGV (#3622) #3660). figuring that out required: parsing 100+ threads of a translated crash report by hand, two web searches, navigating to the issue, reading the linked PR, then posting a "still repros" comment. a built-in reporter would have surfaced "this matches [bug] Crash (SIGSEGV in onnxruntime) when auto-updater restarts app during audio-manager / speaker-model init #3557, fix pending in fix(updates): gate auto-restart on boot-ready to avoid ORT teardown SIGSEGV (#3622) #3660, want to add a +1?" in one click.

net effect: more signal, less effort, fewer lost bugs, faster fixes.

alternatives considered

• do nothing, rely on users to file manually — what we have now; loses the long tail of small bugs and quirks. also produces low-quality reports without crash artifacts.
• sentry / crashlytics-style auto-telemetry — better for aggregate signal but (a) privacy posture is wrong for screenpipe's "your data stays local" pitch, (b) doesn't capture feature ideas or non-crashing quirks, (c) doesn't produce the public, searchable github issues that drive community contribution.
• a "copy diagnostic bundle to clipboard" button — half-step; still requires the user to manually file the issue and assemble context. worth shipping as a fallback inside the bigger feature.
• a discord-bot / google-form intake — fragments the issue tracker; maintainers then have to re-file good reports as github issues anyway.
• external pipe from the marketplace — viable, but discoverability is bad. bug reporting is core enough that it should be on by default.

additional context

• prior art worth borrowing from: vscode's "report issue" command (pre-fills a github form with extension list, perf snapshot, system info), apple feedback assistant (attaches sysdiagnose), linear's slack-to-issue intake.
• could ship in two stages: (stage 1) menu item + auto-fill + template compliance + redaction, opens browser with pre-filled ?body= url. (stage 2) dedup search, oauth submit, crash-report auto-detection, screenshot/timeline attachment.
• this would also make dogfooding easier — internal team can wire screenpipe report feature into their own workflow.
• bonus: aggregate the locally-filed reports into a memory store entry so the user can later ask "what bugs have i filed?" and screenpipe's own context layer answers it. nicely closes the loop.