Other agents

Any terminal program runs in Saggar. A CLI outside the provider roster gets the generic terminal experience: statuses from output, bells, and prompt shapes, but no chip, no launch row, no hooks, and no exact resume.

What still works

• Status. Saggar classifies the terminal from recent output. A quiet terminal after a bell or a menu-shaped prompt reads as Needs you, and a long-running command reads as Working. saggar explain shows the rule that decided.
• Restore. A restored terminal reopens in the same folder and shows what it was last running, but starts an idle shell rather than the tool.
• The Saggar skill. An agent that reads a SKILL.md from a directory Saggar doesn't know can still be pointed at the file by hand. The saggar CLI works from any terminal Saggar opened.

Custom resume bindings

A durable tool with its own checkpoint, such as a tmux session, can attach a resume binding to its terminal:

saggar resume set --kind tmux --checkpoint build:1 --cwd /repos/api \
  --provenance "tmux integration" -- tmux attach -t build
saggar resume show
saggar resume clear

The binding is untrusted until you approve its exact command, working directory, and environment in Settings ▸ Sessions. Approval covers only that scope: a tool can't gain a new command or directory by relabeling an approved binding, and you can revoke an approval there at any time. An unapproved binding restores as an idle shell.

Environment values ride along only when they aren't secrets. Saggar rejects keys whose names contain token, password, passwd, secret, API key, access key, private key, authorization, cookie, or credential.

A native provider's session id always takes precedence over a custom binding.

Asking for a provider

If a CLI you use isn't listed, tell us through Report a problem. A provider is one entry in Saggar's catalog plus the data for each decision, so the cost of adding one is mostly learning what the CLI exposes.