Styx 0.4.19 lets coding agents run SSH, scp and rsync without seeing the private key

Agents get access, not the key

When an AI coding agent needs to reach a server, the two obvious setups both give away too much: either a private key sits somewhere the agent can read it, or the agent borrows your normal SSH configuration and you hope it stays on task. Nicholas Flemmer, writing on dev.to, offers a third path in Styx, a free and open-source desktop app that runs coding agents and gates their access to production systems. Version 0.4.19 adds SSH target support, and according to the developer it lets agents run ordinary ssh, scp, sftp and rsync commands while Styx handles the credentials underneath.

A target, not a credential

In Styx, an SSH target is defined as a host, a user, a port (22 by default), an optional jump host in the user@bastion:22 form, comma-separated if there are several, and an environment label of prod, staging or preview. Agents receive no special tooling: they invoke plain ssh commands and Styx fills in the target's user, port and jump host for them. If the agent specifies its own user or port, the developer says the agent's choice takes precedence.

Three ways to sign in

Styx supports three authentication modes, each with a different trust profile:

• Key file. The OS keychain stores only the key's path and passphrase, never the key itself. Each time a grant is issued, Styx re-reads the key from disk and hands the agent a forwarded SSH agent socket that stays valid for the lifetime of that grant. The agent never touches the key file.
• Password. The password lives in the keychain. On each grant Styx signs in to the server itself and the agent rides that connection, so it never sees the credential. This mode is unavailable on Windows, whose ssh implementation cannot share an already-authenticated connection; there, users fall back to key files or their own setup.
• Your own SSH setup. Nothing is stored at all. The ssh invocation uses your existing agent and ~/.ssh/config, so 1Password integration, hardware keys, certificates and pre-existing keys keep working. Whatever that setup can reach, the agent can reach.

The target form also includes a test button that authenticates exactly the way an agent would. If a server accepts only passwords while a key was selected, Styx reports the mismatch and explains how to install the key on the server, which is a failure you want at configuration time rather than in the middle of an agent's task.

Ask first, then audit

A connected target is not automatically usable. According to the post, the agent must request access and state its reason, and the user picks the scope: once, for an hour, or for the session. Because an SSH grant on a production target hands over the full credential regardless of the scope requested, Styx converts any auto-approval into an interactive prompt using Touch ID, Windows Hello or the system password, even when the request is only for reads. Every request, grant, use and revocation lands in an append-only audit log.

Where the protection ends

The developer is explicit that Styx is a guardrail, not a sandbox. Agents run as the user, on the user's machine. Interception works via a shim: an agent that calls ssh by name hits the prompt, but one that invokes the real binary by its full path goes around it entirely. In those cases Claude Code and Codex get a warning in the chat rather than a block. The guarantee Styx makes is narrower: it never hands an agent your key, and every grant it does issue is scoped, time-limited and written down.

Why it matters

Server access is a real gap in agent workflows. Teams running coding agents increasingly need them to deploy, inspect or debug remote machines, and the practical options so far have been sharing long-lived credentials or doing the SSH work by hand. Brokering access through forwarded agent sockets, with expiring grants and an audit trail, is a sensible middle path. The developer's honest accounting of the full-path bypass also matters: a name-based shim stops careless mistakes, not a deliberately adversarial agent, so anyone with a hostile-agent threat model still needs a true sandbox. The details here come from the developer's own announcement rather than independent testing, but the code is published on GitHub under NicholasFlemmer/styx-app for anyone who wants to verify the claims.