# In-app toast notifications

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](./triggering-from-scripts.md)
- `solo.yml` [sync-needed warnings](../projects/yml-change-notifications.md)
- [Auto-restart paused warnings](./auto-restart-notifications.md)
- Server announcements
- Settings confirmations and other success/error feedback

When Solo is in the background, focus-aware process notifications use the [native desktop notification](./macos-permissions.md) path instead of an in-app toast. Server announcements are still shown as persistent in-app toasts. See [notification troubleshooting](../troubleshooting/notifications.md).

## 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.yml` changes, 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 `X` to 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](./bell-sounds.md). 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.

---

Are you a human? Read this doc on the web: https://soloterm.com/docs/notifications/in-app-toasts