Solo uses in-app toasts for lightweight confirmations and longer-lived alerts that should stay visible inside the app.
When toasts appear
Common toast-triggering events include:
- Process crashes
- Terminal or script notifications
solo.ymlsync-needed warnings- Auto-restart paused warnings
- Server announcements
- Settings confirmations and other success/error feedback
When Solo is in the background, focus-aware process notifications use the native desktop notification path instead of an in-app toast. Server announcements are still shown as persistent in-app toasts. See notification troubleshooting.
Two toast behaviors
Solo has two kinds of toasts:
- Auto-dismiss toasts for brief success or info feedback. They disappear on their own after a short delay.
- Persistent toasts for alerts that should remain visible until you act on them. These are common for crashes,
solo.ymlchanges, auto-restart pause events, and server announcements.
Terminal/script notification toasts are transient by default. They can still clear unread attention when dismissed.
Dismissing toasts
- Auto-dismiss toasts disappear on their own.
- Click the
Xto dismiss an ordinary toast immediately. For an unread-linked process toast, Solo removes the toast after its unread acknowledgement succeeds; if acknowledgement fails, the toast remains visible. - Click a process-linked crash, auto-restart, or terminal notification toast to jump to that process. Click a solo.yml changed toast to open the project that needs syncing. Solo routes either target to its owning workspace and window. Same-window process selection starts the matching persistent toast's dismiss countdown. If process navigation lands in another window, the source window dismisses its linked toast when shared unread attention clears.
Hovering over a toast pauses its countdown timer. When you move away, the countdown restarts from the full duration.
Multiple toasts
When several events happen close together, Solo stacks their toasts in the top-right corner, with newer toasts first. An event with the same type, title, and body as one shown less than one second earlier is deduplicated. A new persistent toast for a process replaces that process's current non-exiting persistent toast instead of adding another card.
Toast vs. native notification
| Toast | Native notification | |
|---|---|---|
| Where | Inside Solo | System notification center |
| Typical use | In-app status and follow-up actions | Background alerts while you're elsewhere |
| Permission required | No | Yes |
| Can select the source context | Yes, for process-linked notification toasts and solo.yml changed project toasts | Process context selects the process; project-only context selects the project |
Related settings
The Settings > Notifications controls focus on native-notification permission, test notifications, and bell sound. Terminal alerts are authoritatively gated by the effective project/process level and require All. Important-alert delivery uses the current frontend project and process level snapshots: a missing project snapshot falls back to Important, and a missing process snapshot falls back to All. There isn't a separate per-category toast routing UI today.