Suggest only vs Confirm before run vs Auto run: picking an AI execution policy in AI-SSH-Pro

An AI that can type into your SSH session is useful. An AI that can type into your production SSH session without asking is a different story.

AI-SSH-Pro is an open-source SSH desktop client with an AI ops assistant docked next to the terminal. The assistant proposes commands with risk labels; you choose how much autonomy it gets. That choice is the AI execution policy: three levels that stay consistent across Settings, each host's Safety card, and the current tab.

Screenshots use the English UI and the built-in demo host where applicable. Some sample AI replies in the demo may be in Chinese.

Risk labels ( low / medium / high ) sit on every suggested command block next to Copy / Run. The policy does not invent risk; it decides whether a labelled command is allowed to execute without you.

You can set policy in three places. The client computes one effective policy for the tab so you are never guessing which layer won.

When a host is Read-only, the Safety card can show something like "In effect: Suggest only (limited by read-only guard)" — the UI matches what the main process will actually allow.

On a throwaway VM or the built-in demo host, friction gets in the way of learning. Auto run (or Confirm with a light hand) lets you ask "show me listening ports" and see ss output without clicking every time.

The demo host is simulated, so you can click Run freely while you learn the policy UI.

Staging is where most teams want Confirm before run. Diagnostics ( systemctl status, tail on logs, ss, journalctl ) stay low-friction. Restarts and config edits wait for a click.

That split is the point of Confirm: speed on investigation, a hard stop before mutation.

Mark the host Production on the Safety card. You get:

Auto run on a production host is almost never worth the minutes you save. One mistaken restart at peak traffic costs more than a confirm click.

Some accounts should never receive writes from AI: auditors, shared jump users, or "view-only" break-glass profiles. Mark the host Read-only.

The important part: the block is enforced in Electron's main process, not only in the renderer. Even if someone clicks approve on a write, the AI path cannot inject mutating input into that terminal. Suggest only / Confirm / Auto run cannot override that guard — the effective policy is capped.

That is the difference between a preference and a control.

Need Auto run for five minutes of noisy log grepping on staging? Raise the tab policy from the input-row menu. Disconnect (or close the tab), and it falls back to the host / global default. No "I left production on Auto run last Tuesday" landmine.

Conversation context stays per tab / per host, so the policy you see matches the machine you are talking about. AI-initiated commands and dangerous ops also land in the audit log for later review or export.

The assistant talks to any OpenAI-compatible provider (OpenAI, DeepSeek, Qwen, and others). API keys stay in the OS secure store on your machine — they are not uploaded to a product cloud. Policy is local to the client either way: changing model does not change how Confirm / Suggest / Auto behave.

Start global at Confirm, then tighten hosts that matter. Loosen only where you can afford mistakes.

More on the project site. AI-SSH-Pro is MIT-licensed; stars, feedback, and issues are welcome.

Which policy do you default to on production boxes — Confirm, Suggest only, or something else entirely?