# AISH: an AI shell that keeps the PTY and grades command risk

> AISH is a Rust rewrite of the terminal that runs interactive programs under a full PTY, adds a semicolon prefix that turns a natural language request into a command, and grades AI-generated commands as low, medium or high risk before running them. It is written for operations work rather than for editing code, and the model layer is pluggable through LiteLLM.

**AI-Shell-Team/aish** — Empower the Shell to think. Evolve Operations. 

- Repository: https://github.com/AI-Shell-Team/aish
- Website: https://www.aishell.ai
- Stars: 566 · Forks: 130
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/ai-shell-team-aish

## A terminal with a language model bolted onto the front

AISH describes itself with a short motto about giving the shell the ability to think and letting operations evolve, and the positioning is more specific than the motto suggests. The README frames the project as a real AI shell with complete PTY plus configurable security and risk control, and the feature list leads with true interactive shell support: full PTY, running interactive programs like vim, ssh or top. That single capability separates it from most command-line assistants, which pipe a request to a model and print text, and never hand the process a terminal.

The second capability is the AI native integration: describe tasks in natural language, and the shell generates, explains and executes commands. The trigger is a character rather than a subcommand, and the README says starting with a semicolon or the full-width semicolon enters AI mode. So aish> ls -la is a plain shell command, while aish>;find files larger than 100M in current directory and sort by size is a request.

The third is the risk grading, and that is the feature that decides whether this is usable on a production host. AI commands carry a risk grade and a confirmation flow, with an optional sandbox pre-run for change assessment. The fourth is the skills plugin system with hot loading and priority override. The fifth, and the reason migration is cheap, is that it is compatible with regular commands and workflows with everything in the terminal by default.

The project is written in Rust with a workspace of nineteen crates, licensed Apache-2.0, requiring Rust 1.89 or newer, with the latest release v0.3.15 from 2026-10-14 and the last push to the repository on 2026-10-22.

## The AI prefix, and how the shell stays a shell

The interaction model has four input types, and they are worth separating because the design keeps the model out of the common path. Shell commands execute directly. AI requests are the ones prefixed with a semicolon or its full-width equivalent. Built-in commands are the shell's own control words, listed as help, clear, exit and quit. Model switching is a slash command, with /model gpt-4 to view or switch the model.

Because a normal command is not routed through the model, an interactive session behaves like a normal session. The README shows the sequence a reader would recognise.

```bash
aish> ls -la
aish> cd /etc
aish> vim hosts
```

The PTY compatibility section makes the same point with programs that need a real terminal rather than a pipe.

```bash
aish> ssh user@host
aish> top
aish> vim /etc/hosts
```

A note on how requests reach a model is also in the README, since the point of the project is that the model can be swapped. The tool calling compatibility check exists to confirm the selected model and channel support tool calling, and the check is a subcommand of its own.

```bash
aish check-tool-support --model openai/deepseek-chat --api-base https://openrouter.ai/api/v1 --api-key your_api_key
```

That check matters more than it looks. A shell agent that cannot call tools cannot inspect the machine or execute anything, so a model without tool calling turns AISH into a chat window that prints suggestions. The project separates the model name, the API base and the API key as three distinct fields, which is what makes any OpenAI-compatible endpoint usable.

## Installing the bundle, and running it from source

There are two routes, and the release bundle is the one most people will take. The one-line installer resolves the latest stable version, downloads the matching bundle for the architecture, and installs three binaries, aish, aish-sandbox and aish-uninstall, into /usr/local/bin.

```bash
curl -fsSL https://www.aishell.ai/repo/install.sh | bash
```

The manual route is a tarball from the official release directory, named by version and architecture, unpacked and installed with the bundled script.

```bash
tar -xzf aish-<version>-linux-<arch>.tar.gz
cd aish-<version>-linux-<arch>
sudo ./install.sh
```

Afterwards the shell is launched with aish, and the README notes that aish without subcommands is equivalent to aish run.

For development the project is a plain Cargo workspace, and the Makefile gives the full command set. The build target is the musl static binary, x86_64-unknown-linux-musl by default, and the shared install prefix is /usr with a data directory of /usr/share/aish and systemd units going to /etc/systemd/system. The targets are named in the usual Rust fashion: `make build` for the release binary, `make build-bundle` for the archive, `make install` for placing the artefacts under DESTDIR and PREFIX, `make test` for the test run, `make lint` for clippy, `make format` and `make format-check` for the formatting, and `make ci-check` which runs format-check, lint and test together as the local equivalent of the CI gates.

```bash
cargo run --bin aish
```



One detail in the test target is worth noting for anyone reproducing a build: the Rust test run is followed by two shell smoke tests, one for the release scripts and one for seeding skills ownership, both run with python3.

## Configuration, precedence and where the keys live

The configuration file sits at ~/.config/aish/config.yaml, or at $XDG_CONFIG_HOME/aish/config.yaml when that variable is set. The precedence order is short and conventional: command-line arguments first, then environment variables, then the configuration file.

The minimal configuration example in the README is three keys.

```yaml
# ~/.config/aish/config.yaml
model: openai/deepseek-chat
api_base: https://openrouter.ai/api/v1
api_key: your_api_key
```

For secrets, the README recommends the environment variable route instead, and the variables are prefixed with the tool name.

```bash
export AISH_MODEL="openai/deepseek-chat"
export AISH_API_BASE="https://openrouter.ai/api/v1"
export AISH_API_KEY="your_api_key"
```

The model layer is LiteLLM, and the README notes that LiteLLM also supports reading vendor specific environment variables such as the OpenAI and Anthropic key variables, which is how a user with an existing key can avoid duplicating it. An interactive configuration path is also available through aish setup, and there is a separate check-tool-support command for verifying that a chosen channel can call tools.

Uninstallation is documented in three layers, which is unusual care for a tool of this kind. The first keeps configuration files, the second removes system level security policies as well, and the third is a manual removal of the user level configuration directory, which the README says will clear the model and API keys.

```bash
sudo aish-uninstall
```

```bash
sudo aish-uninstall --purge-config
```

```bash
rm -rf ~/.config/aish
```

The order of that list is the point. The middle command exists because the security policy file and the config file are treated as separate things with different lifetimes.

## Risk grading applies only to generated commands

The security model has one rule that is easy to miss and worth stating first: the assessment runs only on AI-generated and ready-to-execute commands. Commands you type yourself are not graded, which is the right scope, since the risk being managed is that the model proposes something you did not intend.

Three levels are defined. LOW is allowed by default. MEDIUM requires a confirmation before execution. HIGH is blocked by default. The policy file that decides the rules is resolved at ~/.config/aish/security_policy.yaml, at user level, and a template is auto-generated if the file does not exist. The README section is cut off after the first entry of that resolution order, so how user level and system level policy files combine is not something a reader can determine from the text available here.

The optional part is a sandbox pre-run, and the README marks it as recommended for production. The default policy has it disabled, and it is turned on in the policy file.

```yaml
global:
  enable_sandbox: true
```

With the flag on, the sandbox needs a privileged service, started through systemd.

```bash
sudo systemctl enable --now aish-sandbox.socket
```

The socket is at /run/aish/sandbox.sock. When the sandbox is unavailable, the behaviour falls back according to a setting named sandbox_off_action, and the README's text stops mid-word while listing the allowed values, which begin with BLOCK and a second value that the truncated text does not finish. That is the single most important unresolved detail in the security documentation, because it decides what happens on a host where the sandbox service failed to start.

## The Rust workspace, and what the crates reveal

The Cargo.toml is a workspace of nineteen member crates, and the names describe the architecture more honestly than a feature list would. There is aish-core, aish-config, aish-security, aish-pty, aish-llm, aish-mcp, aish-session, aish-context, aish-skills, aish-memory, aish-ui, aish-tools, aish-scripts, aish-shell, aish-cli, aish-prompts, aish-hosts, aish-i18n and aish-md-table.

A few of these names carry weight. aish-pty is the terminal handling, and aish-shell is the interactive loop, which is why the project can run vim. aish-mcp is the Model Context Protocol crate, which is how the shell exposes itself to external tooling. aish-session and aish-memory point at a persistence model, and the workspace dependencies list rusqlite with the bundled feature, so sessions are kept in a local SQLite database rather than in a service. aish-i18n and aish-md-table are small but telling: the README's feature comparison claims multi-language output with auto detection, and the repository carries a README in Simplified Chinese, German, Spanish, French and Japanese, so the internationalisation is real rather than aspirational.

The dependency set also fixes the shape of the runtime. tokio with the full feature is the async runtime, reqwest with rustls and no default features is the HTTP client, so there is no OpenSSL dependency to satisfy, clap with derive is the command line parser, crossterm and ratatui are the terminal and interface libraries, nix and libc cover the system calls, notify watches files, tiktoken-rs counts tokens, and sha2, base64 and rand cover hashing and secrets. rusqlite is compiled with the bundled SQLite, and the musl target with rustls removes the OpenSSL dependency, which is what makes a single static binary a realistic distribution artefact.

## Observability, and where this differs from a coding assistant

Two features set AISH apart from the assistant it compares itself against in the README's feature table, and both are about scope rather than capability. The first is positioning: the table describes AISH as an ops and system troubleshooting CLI and the comparison product as a development coding assistant, and it lists file operation tools under AISH as minimal essential support against full support on the other side. The second is observability: Langfuse is listed as optional for AISH, where the comparison column says built-in.

The Langfuse integration is a configuration flag plus three environment variables, and the README notes that aish check-langfuse runs checks when check_langfuse.py exists in the project root.

```yaml
enable_langfuse: true
```

```bash
export LANGFUSE_PUBLIC_KEY="..."
export LANGFUSE_SECRET_KEY="..."
export LANGFUSE_HOST="https://cloud.langfuse.com"
```

Traces of the model's own reasoning are useful when an agent decides to run something surprising on a server, and having the option to send them to a self-hosted Langfuse is what makes that usable where a SaaS observability product is not an option.

The skills system is the other extension point. The README describes it as a plugin system with hot loading and priority override, and the repository has a skills/ directory at the top level, with a packaging smoke test named for seeding skills ownership. A skill that loads without a restart and can be overridden by priority is the right shape for a tool whose job is to accumulate a team's operational knowledge, and the fact that a release script smoke test covers it suggests the seeding step is part of the release process rather than a community afterthought.

The comparison table in the README claims fully open multi-model support, a ReAct diagnostic sub-agent, full PTY, local model support and a completely free open source licence, with the price line reading that AISH is an open source project against a paid service for the comparison. Those are the project's claims about itself, and the multi-model and local model points are the ones a reader can check directly from the configuration, where the model, the API base and the key are all separate fields.

## Where AISH is the wrong tool

Three cases point elsewhere. The first is a developer who wants to edit code. The README's own comparison says the file operation tools are minimal essential support, where the alternative it lists offers full support, and the project positions itself as an operations and system troubleshooting CLI. If your day is reading and rewriting source files across a repository, an assistant built for that job is the better fit, and AISH's own feature list says as much.

The second is a team that will not run a privileged helper on the host. The sandbox pre-run path needs a systemd socket started with root, and the fallback behaviour when that socket is absent is described by a setting whose allowed values the README truncates mid-list. Without knowing whether the fallback blocks or permits, an operator cannot reason about what happens when the sandbox service is down, which is exactly the moment the security layer matters most.

The third is a platform that is not Linux. The platform badge names Linux, the release bundles are named for linux architectures, the Makefile defaults to a musl target and installs a systemd unit, and the shell is a Rust binary rather than something packaged for other systems. macOS and Windows users are not served by this distribution.

The alternative worth weighing is running an agent inside an existing shell with a wrapper script, which is what many teams do when they need model help with system commands. The difference in approach is that AISH owns the terminal, so it can see interactive output, keep a session in SQLite, grade only the commands it generated, and offer skills that load without a restart, while a wrapper sees the command string and the final exit code and nothing in between.

## Conclusion

AISH fits an operations engineer who wants to describe a troubleshooting step in plain language on a machine where interactive tools matter, and who is willing to put a confirmation prompt in front of every generated command. It does not fit a developer who wants an editing assistant with full file read and write support, since the README describes the file operation tools as minimal essential support, and it does not fit a team that cannot accept a local SQLite session store and a config file holding API keys. Before you install it, run aish check-tool-support against the model you intend to use, because a model channel without tool calling will not drive the shell, and read the sandbox_off_action setting, since the default policy leaves sandbox pre-run disabled and falls back when the sandbox socket is absent.

## FAQ

### What is AISH?

It is a Rust rewrite of the shell that gives you a natural language mode alongside a normal terminal. Type a command and it runs directly, or prefix it with a semicolon and AISH asks a model to generate, explain and run it. The project describes itself as an ops and system troubleshooting CLI with full PTY support.

### How do I install AISH?

Run curl -fsSL https://www.aishell.ai/repo/install.sh | bash, which installs aish, aish-sandbox and aish-uninstall into /usr/local/bin, or download the matching aish-<version>-linux-<arch>.tar.gz bundle and run sudo ./install.sh. For development, cargo run --bin aish runs it from the workspace.

### Which model does AISH use, and can I use a local one?

The model, api_base and api_key are three separate configuration fields in ~/.config/aish/config.yaml, or in AISH_MODEL, AISH_API_BASE and AISH_API_KEY environment variables, and the README states that local model support is fully supported. The layer underneath is LiteLLM, which also reads vendor specific key variables such as OPENAI_API_KEY.

### How does AISH decide whether to run an AI-generated command?

Only AI-generated and ready-to-execute commands are assessed. The risk levels are LOW, which is allowed by default, MEDIUM, which asks for confirmation before execution, and HIGH, which is blocked by default, with the rules held in ~/.config/aish/security_policy.yaml.

### What does the sandbox pre-run do and is it on by default?

It is a pre-execution assessment of a command in a privileged sandbox, and the README says the default policy has it disabled, marking it optional and recommended for production. You enable it with enable_sandbox: true under the global key and start the service with sudo systemctl enable --now aish-sandbox.socket, and the default socket is /run/aish/sandbox.sock.

### How do I uninstall AISH?

sudo aish-uninstall removes the installation and keeps configuration files, sudo aish-uninstall --purge-config also removes system level security policies, and rm -rf ~/.config/aish clears the user level configuration, which the README says will clear the model and API keys.

## Sources

- [AI-Shell-Team/aish on GitHub](https://github.com/AI-Shell-Team/aish)
- [License: Apache-2.0](https://github.com/AI-Shell-Team/aish/blob/main/LICENSE)
- [Project website](https://www.aishell.ai)
- [README](https://github.com/AI-Shell-Team/aish/blob/main/README.md)
- [Releases](https://github.com/AI-Shell-Team/aish/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ai-shell-team-aish