Selectel's aish makes command approval the hard part of AI operations
Selectel released aish, its terminal AI agent for system administrators, to the open SELECTOS repository on August 31. Every SELECTOS version can now install it through apt, accept a natural-language request, and run a command after the user approves it.
The product is more interesting for what its team admits than for the install command. In an earlier account of building aish, Selectel described the central interface constraint: server commands take effect immediately. A text terminal cannot show a complete future version of the server, let the operator inspect it, and then offer Apply.
Generating a plausible command is therefore the easy half. The operator needs enough evidence about scope, failure, and rollback to make approval meaningful.
What Selectel released
The August 31 announcement says aish is available in every SELECTOS version:
sudo apt update
sudo apt install aish
aish
Selectel presents it as a tool for ambiguous diagnostics: finding why a service will not start, tracing lost disk space, and inspecting logs or configuration before proposing a fix. The user states the problem, aish gathers context, proposes actions and commands, and executes them with consent.
The earlier development account says the tool uses ratatui and Qwen3. Its basic loop is request, proposed solution and command, approval or rejection, then execution as the current user.
The model runs on Selectel's servers. The company says this helps organizations with policies that restrict sending context to foreign LLMs. That is a data-location claim, not on-host inference. The launch post does not spell out the exact context leaving the administered machine, retention, transport controls, or telemetry. A team with strict data boundaries should ask for those details instead of reading “local” as “nothing leaves this server.”
Approval has to describe consequences
An IDE can often show a file diff. A server command may change packages, services, users, permissions, firewall rules, processes, and remote systems in one step. There may be no single artifact to preview.
The approval view should disclose the exact command and effective privilege. “Restart the service” is incomplete if the action also rewrites a unit file or uses sudo. It should name the resources likely to change, including files, packages, ports, services, accounts, scheduled jobs, and network destinations. That list remains an estimate, but it gives the operator something concrete to review.
Rollback belongs beside the command. A package install, database migration, and log deletion may each start with one line, yet their recovery options differ sharply.
Consent also needs an edge. Is the user approving one command, an entire pipeline, or a plan that lets the agent keep acting after it sees the output?
These are design recommendations for AI shells, not features attributed to the current aish release.
Current behavior versus roadmap
Selectel says aish requires consent before execution. Its SELECTOS documentation describes it as a natural-language shell utility for managing the operating system.
The June article separately lists planned work: stronger destructive-command checks, secret detection and redaction before data is sent, selective rules for which commands require confirmation, skills for more deterministic behavior, and a fuller plan-build-act loop. These are roadmap items, not current safeguards.
Destructive-command detection and secret filtering are not minor interface improvements. They affect whether the agent can safely gather context and act on a production host.
Model access does not replace this layer. Connecting a similar shell to api.ish.chat or another OpenAI-compatible endpoint can simplify inference, but it does not decide which commands may execute. That decision needs deterministic policy around the model.
Ask for an approval packet
Operators evaluating aish or another terminal agent should expect more than a yes-or-no question. Before execution, the tool should show:
- The exact command, working directory, environment changes, and effective user.
- A short statement of intent.
- Expected reads, writes, network calls, service changes, and package operations.
- A risk label produced by deterministic rules, with the matching rule visible.
- A rollback command, or a clear statement that no reliable rollback is known.
- The consent boundary: one command, one pipeline, or one named plan.
- A durable record of the proposal, approval, output, and exit status.
When software supports it, the agent should prefer native dry-run modes: package-manager simulation, configuration validation, query planning, or read-only probes. Snapshots and backups can help recovery, but they are not universal undo. Remote side effects may remain irreversible.
Our least-privilege checklist for agent tools applies the same idea at the tool layer: restrict authority before depending on careful approvals. The analysis of LM Studio's environment-aware command judge adds that risk depends on the environment where a command runs, not only its text.
Test the approval, not the demo
Approval dialogs can transfer responsibility without transferring understanding. During an incident, an operator may accept a dense command because the agent sounds certain and the service is already down.
aish may lower the effort required to diagnose and execute a fix, especially for understaffed teams. The same compression shortens the distance between suggestion and consequence. Selectel's design account is useful because it acknowledges that a server has no simple preview state.
A practical pilot should use a disposable host and several deliberately awkward cases: a command that needs privilege escalation, one with a remote side effect, one with no clean rollback, and one where the observed output contradicts the proposed plan. Record whether the operator understood the scope before approval and whether the agent stopped at the agreed boundary.
That test says more about an AI shell's operational value than a fast nginx demo. The question is not only whether aish can find a fix. It is whether the person at the terminal can tell what will happen before the fix runs.
