Agents
Saggar is a terminal manager, so an agent is just a program running in a shell — but it is the program the whole app was built for, and knowing one is there buys better status, exact resume, and an answer button.
Recognizing one
Two independent ways, because either alone has a hole. Saggar walks the
process tree under each shell, so a claude
or codex you started by hand is recognized
exactly like one Saggar launched. When the walk can't name it — an
unfamiliar launcher, or a walk that raced the launch — the agent is
recognized by its on-screen chrome instead, so the chip lights whenever
an agent is plainly there and not only when the process tree cooperates.
Your roster
Onboarding asks which CLIs you actually use, and Settings ▸ Providers changes the answer any time. The roster fills the new-terminal menu, decides which handshakes get offered, and narrows the on-screen scan.
It deliberately does not gate recognition. A
codex you start by hand with codex turned
off still lights its chip and still gets answered, because turning a
provider off means “stop offering me this”, not “lie
to me about what's running”.
The handshake
Recognition is inference. The handshake replaces it with a contract, and
it is opt-in — an onboarding step, or Settings ▸ Providers, and
uninstalling removes only Saggar's own entries. Every shell already
carries a per-session SAGGAR_SESSION id; the
installed hooks mirror each event into a small file under
~/.saggar/presence/. Where the handshake
speaks, it outranks the heuristics.
The two contracts are not equals, and Saggar says so rather than promising a parity the CLIs can't give:
| Agent | Installs | Buys |
|---|---|---|
| Claude Code | ~/.claude/settings.json | Four hooks. Presence by contract; a permission prompt raises needs you with no transcript scan; a turn end reads idle the instant it fires; and exact resume — the session rejoins its own conversation by id, so two Claude sessions in one project don't land on each other. |
| Codex | ~/.codex/config.toml | One notify program, carrying turn completion — so a codex turn settles the moment it lands rather than seconds later. Codex takes only one notify program, so an install that finds somebody else's refuses rather than replacing it. |
The process walk and the on-screen scan stay underneath as the base layer, for other CLIs, declined installs, and setups Saggar has never seen. Restoring a project resumes either agent where it left off.
Turbo
Turbo answers a session's routine prompts for you. It is per session, chipped on the terminal, and it changes what the rest of the app does about that session: a prompt turbo already answered raises neither a banner nor a sound, because turbo's promise is that it acts so you don't have to, and being summoned to look at something that resolves itself is exactly the interruption it exists to remove.
The quiet is keyed to the prompt, not to the chip. A turbo session blocked on something turbo will never answer — an arrow-key wizard, a bell-only needs-you — still reaches you. Turning turbo on is never a way to go quiet permanently.
What it refuses
Turbo will not approve a genuinely destructive command. An
rm -rf, a
sudo, a
curl … | sh, a force push, a hard reset, a
raw write to a disk device, a fork bomb, a machine power-off, an
infrastructure teardown, a dropped table — those it hands back on screen
for a human to read rather than accepting unseen.
The list is biased toward false positives on purpose: a false positive costs you one manual approval, and a miss auto-runs something irreversible. That is not a close trade.
The same asymmetry governs remote control, where approve sends a waiting prompt's own default answer and nothing else — see the security model.