You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A coding agent can be silent because it's working, finished, or waiting for permission. It can also print a lot while waiting. Watching for terminal output alone doesn't tell you when to intervene.
I'm Saggar's developer. A question in the original HN discussion asked how it detects those moments when an agent doesn't provide hooks. This is how the current implementation works, including where it can get things wrong.
A waiting prompt, surfaced in the attention card.
Combine explicit signals with terminal evidence
Saggar receives several kinds of evidence: shell command markers and exit codes, agent lifecycle hooks where available, terminal output, bells, and explicit calls through its CLI. An agent can use saggar attention to report that it's blocked.
These signals have different meanings. A running shell command is useful evidence that a build is working, even if it hasn't printed anything recently. For an interactive coding agent, that same marker can remain active for the entire session, including while the agent waits for your next message.
The classifier therefore checks evidence in order:
A recorded shell exit takes precedence over prompt text left on screen.
A live, unacknowledged attention signal marks the session as needing you.
A running non-agent shell command counts as working, even when silent.
An agent end-of-turn signal can settle the session immediately.
Otherwise, recent output counts as working, subject to filters for typing and focus repaints. The current output window is ten seconds.
Without those signals, the session is idle.
Idle is an observation about activity. It doesn't establish that the task succeeded.
Recognize a prompt, not just a question
When explicit events aren't available, Saggar examines the last twenty nonempty terminal lines. It normalizes whitespace and terminal padding before looking for permission menus and other input cues.
Distinctive options such as “No, and tell Codex” or [y/n] are useful clues. A conversational phrase such as “Would you like to” is much weaker: it might be part of the agent's explanation. Those phrases require a live menu shape before they count as a prompt. Menu detection looks for multiple options and a cursor, rather than treating any question mark as a request for input.
This remains inference. A CLI can change its wording or rendering. Quoted examples can resemble real prompts, and unfamiliar interfaces can go undetected. Explicit lifecycle events give better evidence where the agent exposes them.
Let each signal expire for the right reason
A prompt shouldn't keep demanding attention after you've answered it. But output alone doesn't always mean a blocker has gone away: a process might keep printing logs while it waits for a decision elsewhere.
Saggar gives signals different lifetimes. A bell can be cleared by subsequent input or later output. An explicit blocked call from an agent survives later output, but clears on subsequent input or expiry. These attention signals currently have a two-minute expiry.
Acknowledgment is separate from answering. Saggar records the normalized prompt fingerprint you've seen. The same unchanged prompt can settle after acknowledgment, while a different prompt or a new attention event can raise the session again.
Two other cases need filtering. Clicking a terminal can make an interactive application repaint, and typing a draft produces terminal output. Neither should make a waiting agent appear to have resumed work. Saggar accounts for recent focus reports and input when interpreting fresh output.
Turn status into a queue
The point is to help you decide where to look next. The ⌘J triage queue orders blocked sessions first, then failures, completed work with changes to review, and clean completions. Within each group, older items come first.
The same attention card in the full project view.
The classifier also records the rule and evidence that won. saggar explain uses that same decision, so a surprising badge can be investigated without inventing a separate explanation after the fact.
The existing test suite covers cases such as stale prompt text after an exit, a quiet interactive agent, focus repaints, typing a draft, and a new prompt after acknowledgment. Those cases check known behavior; they aren't a measured accuracy score across every CLI.
Try it on one real task
If you're trying a coding agent this weekend, leave one real task running beside your usual work. Check whether Saggar surfaces a waiting session you would otherwise have missed. Reports of missed prompts and false alarms are useful, especially with the agent name and what was visible at the time. Remove secrets before sharing terminal output.
Saggar is a native Mac terminal. The full Mac app is free, with no account needed. It requires Apple silicon and macOS 26 Tahoe or later. Model access comes from your existing agent account; optional remote control is paid separately.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
How Saggar tells whether a coding agent needs you
A coding agent can be silent because it's working, finished, or waiting for permission. It can also print a lot while waiting. Watching for terminal output alone doesn't tell you when to intervene.
I'm Saggar's developer. A question in the original HN discussion asked how it detects those moments when an agent doesn't provide hooks. This is how the current implementation works, including where it can get things wrong.
A waiting prompt, surfaced in the attention card.
Combine explicit signals with terminal evidence
Saggar receives several kinds of evidence: shell command markers and exit codes, agent lifecycle hooks where available, terminal output, bells, and explicit calls through its CLI. An agent can use
saggar attentionto report that it's blocked.These signals have different meanings. A running shell command is useful evidence that a build is working, even if it hasn't printed anything recently. For an interactive coding agent, that same marker can remain active for the entire session, including while the agent waits for your next message.
The classifier therefore checks evidence in order:
Idle is an observation about activity. It doesn't establish that the task succeeded.
Recognize a prompt, not just a question
When explicit events aren't available, Saggar examines the last twenty nonempty terminal lines. It normalizes whitespace and terminal padding before looking for permission menus and other input cues.
Distinctive options such as “No, and tell Codex” or
[y/n]are useful clues. A conversational phrase such as “Would you like to” is much weaker: it might be part of the agent's explanation. Those phrases require a live menu shape before they count as a prompt. Menu detection looks for multiple options and a cursor, rather than treating any question mark as a request for input.This remains inference. A CLI can change its wording or rendering. Quoted examples can resemble real prompts, and unfamiliar interfaces can go undetected. Explicit lifecycle events give better evidence where the agent exposes them.
Let each signal expire for the right reason
A prompt shouldn't keep demanding attention after you've answered it. But output alone doesn't always mean a blocker has gone away: a process might keep printing logs while it waits for a decision elsewhere.
Saggar gives signals different lifetimes. A bell can be cleared by subsequent input or later output. An explicit blocked call from an agent survives later output, but clears on subsequent input or expiry. These attention signals currently have a two-minute expiry.
Acknowledgment is separate from answering. Saggar records the normalized prompt fingerprint you've seen. The same unchanged prompt can settle after acknowledgment, while a different prompt or a new attention event can raise the session again.
Two other cases need filtering. Clicking a terminal can make an interactive application repaint, and typing a draft produces terminal output. Neither should make a waiting agent appear to have resumed work. Saggar accounts for recent focus reports and input when interpreting fresh output.
Turn status into a queue
The point is to help you decide where to look next. The
⌘Jtriage queue orders blocked sessions first, then failures, completed work with changes to review, and clean completions. Within each group, older items come first.The same attention card in the full project view.
The classifier also records the rule and evidence that won.
saggar explainuses that same decision, so a surprising badge can be investigated without inventing a separate explanation after the fact.The existing test suite covers cases such as stale prompt text after an exit, a quiet interactive agent, focus repaints, typing a draft, and a new prompt after acknowledgment. Those cases check known behavior; they aren't a measured accuracy score across every CLI.
Try it on one real task
If you're trying a coding agent this weekend, leave one real task running beside your usual work. Check whether Saggar surfaces a waiting session you would otherwise have missed. Reports of missed prompts and false alarms are useful, especially with the agent name and what was visible at the time. Remove secrets before sharing terminal output.
Saggar is a native Mac terminal. The full Mac app is free, with no account needed. It requires Apple silicon and macOS 26 Tahoe or later. Model access comes from your existing agent account; optional remote control is paid separately.
Watch the product demo · Getting started
Prepared with AI assistance and checked against Saggar's current implementation and existing test cases.
All reactions