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.
- Website: https://guoshuaipeng.github.io/ai-ssh-pro/
- Download: https://github.com/guoshuaipeng/ai-ssh-pro/releases
Screenshots use the English UI and the built-in demo host where applicable. Some sample AI replies in the demo may be in Chinese.
The three policies at a glance
| Policy | Read-only / low risk | Medium risk (writes, restarts) | High risk |
|---|---|---|---|
| Suggest only | May run | Shown as suggestion only — you copy or type yourself | Suggestion only |
| Confirm before run (default) | May run | Needs your confirmation | Needs confirmation (stricter for dangerous ops) |
| Auto run | Runs automatically | Runs automatically | Still asks |
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.
Where you set it
You can set policy in three places. The client computes one effective policy for the tab so you are never guessing which layer won.
- Settings → AI — global default for new sessions.
- Host Safety card — per-host default (and protection level: Normal / Production / Read-only).
- Tab policy menu (input row) — temporary override for this connection only. It lives in memory and resets on disconnect.
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.
Scenario 1: laptop / jump box / learning
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.
Still useful habits even here:
- Keep high-risk behind a prompt (Auto run already does that).
- Prefer attaching terminal output to a question when you already have a log open, instead of retyping context.
The demo host is simulated, so you can click Run freely while you learn the policy UI.
Scenario 2: staging
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.
A typical flow:
- You describe the symptom (or attach terminal output).
- The assistant returns read-only commands labelled Risk: low — they may run under Confirm.
- It proposes
sudo systemctl restart …labelled medium/high — you get a confirm card, then decide.
That split is the point of Confirm: speed on investigation, a hard stop before mutation.
Scenario 3: production
Mark the host Production on the Safety card. You get:
- A red production banner on the terminal tab so the context is always visible.
- Stricter confirmation for dangerous commands (including typing the host name where required).
- Prefer Confirm before run, or even Suggest only if you want the AI as a second pair of eyes only.
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.
Scenario 4: read-only hosts (and why UI alone is not enough)
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.
Per-tab overrides without permanent foot-guns
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.
Bring your own model
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.
A practical default matrix
| Host type | Protection | Suggested AI policy |
|---|---|---|
| Demo / local VM | Normal | Auto run or Confirm |
| Staging | Normal | Confirm before run |
| Production | Production | Confirm (or Suggest only) |
| Audit / view-only | Read-only | Effective Suggest only (main-process guard) |
Start global at Confirm, then tighten hosts that matter. Loosen only where you can afford mistakes.
Try it
- Install from GitHub Releases (Windows, macOS, Linux).
- Open the demo host and flip Settings → AI between the three policies; watch which commands ask and which run.
- Add a real host, set Production or Read-only on the Safety card, and confirm the banner / effective policy text.
- Point Settings → AI at your OpenAI-compatible provider when you are ready for live triage.
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?
Top comments (0)