Symptom

Crash reports correlate with the auto-updater restart flow and ONNX-backed model paths (audio embedding, speaker model init, OCR fallback). Observed pattern: app restarts after an update and crashes during the next inference, or crashes mid-update if a model is actively running.

Hypothesis

Active ONNX inference sessions aren't being torn down before the updater calls process::exit / tauri::api::process::restart. The OS reaps the process mid-inference, and on the relaunch model init races against state left over from the previous run. Without structured logging at the panic site, the actual lifecycle break is unclear.

Proposed fix path

1. First: add structured panic logging at the onnxruntime boundaries that captures active model, thread state, and call stack on panic. This gives ground truth about which stage is dying.
2. Then: once we have repro data, fix the lifecycle: explicit drain of in-flight ML sessions before process::exit, clean Environment drop, no races on model re-init.

A PR for step 1 (structured logging) is in flight. Will link it here when it opens.

Ask for the community

If you've hit this crash:

1. Full crash log or ~/Library/Logs/DiagnosticReports/screenpipe-*.ips on macOS (or the Windows / Linux equivalent)
2. How the update triggered: manual "check for updates" vs. background auto-update
3. Active models at crash time: which embedding model, audio on/off, OCR backend
4. Whether the crash repros if you let screenpipe run idle for N minutes after update before triggering inference

Reproduce with the logging PR once it's merged — the new logs should point straight at the lifecycle issue.