Status and desktop notifications

Status indicators tell you whether a terminal is idle, running a saved command, running manual work, or showing a failure. Desktop alerts help you return to work that finished in the background.

Status dots #

Managed commands become failure-eligible immediately. Manual commands become eligible after the blue activity threshold; a brief failed command does not necessarily produce a red dot. Stop and Ctrl+C are explicit interruptions and do not count as failures. A fresh shell resets runtime status.

Read the terminal output to understand a red state; it is an exit-status signal, not a diagnosis. The sidebar's Running and Failed filters collect these states. Some compact switchers omit idle dots.

When a supported coding agent is live, a robot replaces the ordinary dot in terminal lists, tabs, and switchers. Its base color follows the shell state above. Amber means an unvisited request for your attention; select that terminal while the main window is focused to acknowledge it. Hovering or previewing a terminal does not acknowledge the request. The robot stays while the agent is running, even between turns. See AI harnesses.

Output activity #

A ring around a running indicator reflects recent terminal output. It represents bytes arriving, not CPU load, progress percentage, or service readiness. A quiet running server can remain green without activity; a busy log stream can pulse repeatedly.

The underlying color still tells you managed versus manual work. Restored output is historical and does not make a command running again. Use the live status and current prompt together when checking a service.

Completion alerts #

Terminalis can post success or failure alerts when eligible work finishes while you are viewing another terminal or the app is not focused. Managed runs qualify immediately; manual commands qualify after they have reached the blue state. Short manual commands and explicit interruptions stay quiet.

A success alert corresponds to exit code zero; a failure alert corresponds to the red failure transition. Foreground completion stays quiet, and switching away afterward does not generate a delayed alert.

Clicking an alert in the shipped macOS app brings Terminalis forward and selects the originating terminal, so you can inspect its output. This works for completion, failure, and script notifications. System delivery and notification permission still apply.

In 3.7.0, command failures and harness alerts have no application expiry timer. Successful-command alerts and ordinary script notifications are removed five seconds after delivery, including from Notification Center history. An explicit persistent script alert also has no expiry timer. Clicking or dismissing an alert handles that notification; dismissing a harness alert does not acknowledge its amber attention indicator.

Notification permissions #

Allow Terminalis notifications when macOS requests permission. In System Settings → Notifications → Terminalis, enable alerts and choose Persistent. Persistent requests require this app-wide style; Terminalis does not change it for you. Focus modes can still suppress delivery.

Settings → AI Harnesses shows Allow when initial permission is needed, or Open settings when macOS alerts or Persistent style need attention. Return to Settings to refresh the status. An invalid signing notice requires an official signed build. The harness event toggles control agent alerts; ordinary completion/failure alerts have no separate per-terminal switch.

Test completion delivery with background work such as sleep 2, then switch to another terminal before it finishes. Ordinary alerts disappear after five seconds, so inspect them promptly.