I'm building aissh, an early terminal workspace for working with remote machines over SSH.
An AI coding assistant can already run shell commands. The part aissh focuses on is the surrounding investigation: maintaining an interactive SSH session, keeping server state visible, reviewing proposed commands, and returning to earlier conversations about the same machine.
A familiar connection, with context alongside it
aissh uses the existing OpenSSH workflow, including SSH configuration, keys, and jump hosts. It does not require a resident agent on the target server. Monitoring depends on the tools and permissions already available there.
After building the CLI, connect using a server alias:
bin/aissh my-test-server
At the SSH prompt, enter an AI request:
/ai Help me inspect the status of nginx on this machine.
The assistant can propose checks, receive their output, and continue the investigation. The question above is an example, not a claim about a measured diagnostic result.
To keep server metrics beside the conversation, open the monitoring sidebar in a terminal at least 92 columns wide:
/sidebar show
Conversation history is stored locally and associated with the SSH target, so an investigation can be reopened later.
What runs automatically?
AI-proposed remote shell commands require approval by default. Built-in read-only monitoring collectors run automatically. Custom collectors require approval before their first run and when their configuration changes; that approval covers recurring collection at the displayed interval.
There is also an opt-in automatic-approval mode. It is separate from the default workflow described here. Command review and AI risk labels should not be treated as a guarantee that every proposed command is appropriate.
Where does the AI run?
You configure the backend. Supported options include Codex, Claude Code, DeepSeek, an OpenAI-compatible API, and an HTTP agent endpoint.
Local coding-agent backends can work with local source-code context. Direct model backends use supplied SSH context and do not read the local workspace. Local workspace access is read-only by default, and local code is not automatically deployed to the server.
AI requests may contain questions, relevant terminal output, and command results; local coding-agent backends can also use code context. Requests go to the configured backend. Local storage of conversation history does not mean that all processing happens offline.
Trying the current version
The project is early. The documented setup currently requires building from source with Go 1.25+, an OpenSSH client, and a separately configured AI backend. Provider fees and limits depend on the backend you use.
The repository contains the setup instructions and an English product tour. The tour records the actual CLI over local SSH, using sample server data and scripted AI responses to show the workflow. It is not a live incident recording or a benchmark.
I'd especially like feedback from people maintaining their own applications: what evidence do you repeatedly collect before an AI assistant can help with a server issue? If you try aissh, the first confusing setup step is useful feedback too.
Writing disclosure: this article was drafted by an AI assistant from the project's documentation.
Top comments (0)