Save Your SSH Connections,
Run AI Agents on the Remote Box

Yes. AgentsRoom works as an SSH connection manager : save a profile per remote server with its host, port, user and auth method, name them, and pick the one you need. Your VPS, staging box and shared dev server all live in the same list.

Both. A connection can authenticate with an SSH key by pointing at your private key file, or with a password. AgentsRoom acts as a standard SSH client, so whichever method your server accepts is what you use.

Yes. That is the point of the feature. Open a saved SSH connection, then launch Claude Code, Codex, Antigravity CLI or another agent in the remote terminal. The agent runs on the remote machine and works on the files that live there, not on your laptop.

The name, host, port and user of each connection are saved to your account, so they appear on all your computers. Your SSH keys stay on the machine, and passwords and key passphrases stay encrypted in the keychain of the machine where you typed them. With synced passwords on (Settings > Account, off by default), passwords and passphrases follow your account too, end-to-end encrypted with a key only your computers hold: AgentsRoom stores them without being able to read them, and you can still keep any password on one machine only. Nothing is ever written into the project repo, so connecting to a server does not add config files or secrets to anything a teammate might clone.

No. AgentsRoom includes a built-in terminal over SSH, so your connection manager, your terminal and your AI agents are in one app. You can keep your usual SSH tools if you like, but you do not need a second client open just to reach the server.

Yes, through AgentsRoom MCP. Agents call ssh_list to see the servers saved for the current project (plus your global ones), then ssh_connect to open one as a terminal tab. It is the supported way for an AI agent to get SSH access: no hand-written ssh command, no credential pasted into a prompt.

Never. The MCP tools only expose connection metadata (name, host, port, user, auth type). The password or key passphrase stays encrypted in your machine keychain and is injected into the terminal by AgentsRoom itself, after the agent has asked for the connection by its id.

Yes. AgentsRoom reads the host blocks in ~/.ssh/config and turns them into saved connections, keeping the identity file each block declares. Anything OpenSSH resolves on its own keeps working, a ProxyJump through a bastion included, because AgentsRoom connects through the alias and lets OpenSSH apply the block rather than trying to reimplement it.

Yes, with an AWS SSM connection. AgentsRoom opens the session with aws ssm start-session, authorized by the AWS profile already configured on your machine. There is no password and no key to store in the app, and the instance can stay closed to inbound SSH.

Yes, and by default it can even save it on its own. ssh_connection_save writes the connection outright, with no form, and the credential never appears in a conversation: the agent names a secret from your vault and AgentsRoom copies it. Prefer ssh_connection_new when you would rather review first: it opens the creation form pre-filled with the host, port and user the agent found in your deploy script or your documentation, and nothing is stored until you review it, type the credential and save. Turn off "Agents can manage connections" in Settings and only the reviewed path remains, because a connection an agent could register without you seeing it would be a backdoor. When the host already exists in your ~/.ssh/config, importing it is the better route : it keeps the alias, so your bastions and your keys keep working.

Yes, two ways. Windows Server has shipped OpenSSH since 2019, so a Windows machine is saved like any other SSH connection, and a remote shell option on the connection makes the terminal land on a PowerShell prompt (Windows PowerShell or PowerShell 7) instead of cmd.exe. For a host that only speaks WinRM, or for the PowerShell endpoint of an on-prem Exchange server, save a WinRM connection instead: NTLM or Kerberos, or CredSSP when the session must reach a second server, with the domain controller and the server IP entered by hand when your workstation is not joined to the domain. Both work whether you run AgentsRoom on macOS, Windows or Linux; the WinRM path installs one small Python package once, in a private folder AgentsRoom owns.

Yes. The New project dialog asks where the project lives: This computer, or Remote server (SSH). Pick a saved connection and the path of the repository on the host, and the project opens from there: its agents start on the server, in that directory, on the files that live there, and nothing is copied to your laptop. The card of every saved connection also carries an Open a project on this server button that opens the same dialog with the connection preselected, and a project of your account that has no folder on this machine can be opened on a server the same way. Role, persona, system prompt, permission mode, skills, status tracking and the Codex account chosen for the agent travel with the agent (the account is copied to the host before the launch, a per-connection setting you can turn off); the AgentsRoom MCP tools (backlog, project memory, skills, dev commands, agent mail) travel too, installed on the host before each launch and wired back to this computer through a reverse SSH tunnel, a per-connection setting on by default that needs Node on the host; a missing CLI on the host is installed on the host, over SSH, from the banner of the agent terminal; and a team run works on a project opened on a server. A ticket marked Code in a separate worktree gets its worktree on the server too, under .worktrees/ of the remote checkout: the agent starts in it; the only thing that still asks for a local checkout is the Own checkout option of a team step. The embedded browser follows the agent as well when the agent has browser access. Environment variables and the other providers' account profiles stay wired to this computer, and the agent form says so while the project is on a server. One requirement: the host must answer with a Linux or macOS shell. A Windows server reached over SSH gives you the terminal and PowerShell, but not a remote project yet; set WSL as the default shell of its OpenSSH service and it behaves like a Linux host.

Not if you ask them to keep going. In the settings of an SSH connection, turn on Keep agents running on this host when AgentsRoom closes: agents launched there run inside a tmux session on the server (tmux 3.0 or later), so quitting the app, putting the laptop to sleep or losing the network no longer stops them, and the next launch of that agent, from this computer, another one of your account or the phone, attaches to it. The agents use the CLIs installed on the server, including those in your user folders, so nothing has to be installed on your laptop; if a CLI is missing there, the terminal offers to install it on the server.