Remote servers
Your whole setup lives on a Linux box? Run the agents there — from AIOAT. Anything ssh reaches becomes a first-class place to work.
Add a host
Servers → + Add server: a name, user@host (or an alias from your ~/.ssh/config), and optionally a port, jump host, default remote directory, and a private key file for this host. AIOAT probes each host over SSH: online status, OS, load, whether tmux is available, and which agent CLIs are installed remotely.
Log in once, not once per agent
Every remote session is its own ssh, so without key auth you'd be typing a password or passphrase for each one. A host that answers but wants a login shows as 🔑 reachable, needs login (as opposed to plain offline), with a one-click Passwordless setup that fixes it for good:
- Finds the key for that host — the one you configured, or your default
id_ed25519, generating one only if you have none. - Adds it to the Windows ssh-agent, so a passphrase-protected key is unlocked once and cached for every later session.
- Verifies a promptless login. If the key isn't installed on the server yet, it offers to append it to
~/.ssh/authorized_keys(one password prompt, if the server allows passwords at all).
Publickey-only servers — password logins disabled — are supported directly: point the server entry at your key (used with -o IdentitiesOnly=yes, so exactly that key is offered), and if the key still isn't accepted the setup prints the public-key line for you to paste into authorized_keys yourself. It runs in a visible terminal tab; nothing happens off-screen.
If ssh-agent is disabled on your machine, the setup tells you the one-time admin command to enable it (Set-Service ssh-agent -StartupType Automatic).
Launching from the New Agent dialog
Registered servers appear in the launch dialog's Location picker under Remote servers. Pick one and the dialog adapts: it probes the host, pre-fills its default directory as an editable Remote directory, and offers tmux persistence and context sharing. Worktree, branch, profile, and issue fields disappear — those are local ceremony. If the agent CLI you chose isn't on the server's PATH, an Install on server… button appears right there.
Give the remote agent your team
Provision team files (on by default for remote agent launches) writes two things into the remote working directory before the agent starts:
.claude/agents/*.md— your whole specialist roster, built-ins plus any subagents you've imported, in Claude Code's native subagent format. The remote Claude picks them up from its working directory and can delegate to them itself — a coordinator on the server, without AIOAT needing to reach in..claude/aioat-context.md— the workspace context digest as a file, so it survives/clearand stays available all session.
It runs visibly as the session's first step, and the file contents travel base64-encoded so nothing can be mangled by quoting. The Foreman itself stays local (it needs AIOAT's own tool server) — provisioning is how you get the same effect remotely.
Remote sessions
- ▶ Shell — a login shell on the host, as a normal AIOAT terminal tab.
- ▶ Run remotely — an agent command (
claude,codex…) in a chosen remote directory. The session appears as a normal card: state dot, approvals, notifications — everything local sessions get. - tmux checkbox — when the host has tmux, the session runs inside
tmux new-session -A: lose the connection (or close AIOAT) and the remote work keeps going; launching again with the same session reattaches where it left off. - share context checkbox — the remote agent starts with your local workspace's shared context digest as its opening prompt, exactly like local launches. The digest is sent in-memory over the SSH command (base64 on the wire) and is never written to the server's disk. Untick it for a clean-slate remote session.
- team files checkbox — provisions the specialist roster and a persistent context file into the remote working directory (above).
Port forwarding
⇄ Forward port… opens an ssh -L tunnel (e.g. 5173:5173) as a killable session — the remote dev server then shows up on http://localhost:5173, where AIOAT's preview pane can open it.
Installing agents remotely
If the probe finds a CLI missing, a one-click ⬇ install runs the official installer over SSH in a visible terminal tab — login prompts and progress stay in view, nothing happens silently.
Current limits (v1)
- Remote sessions don't get the local git features — worktree ceremony, diff review, and checkpoints apply to local repos. (Remote repo browsing is on the roadmap.)
- Context sharing is one-way (local → remote, at launch). What a remote agent learns doesn't flow back automatically — publish it from the session's output (Approvals → publish) like any other session.
- The remote host is assumed to be POSIX-ish (Linux/macOS — commands run via
sh -lc).