Remote sessions over SSH
A remote thread runs Claude on another machine over SSH. The remote host owns the claude install, the sign-in, and the working tree. Cone is the cockpit: transcript, permission prompts, file tree, diffs, and terminal all render locally while everything executes remotely.
Remote sessions are currently Claude only.
Setting up a host
Section titled “Setting up a host”Add a host in Settings using any user@host or ~/.ssh/config alias. Cone runs a preflight that checks the SSH connection, the remote claude presence and version, git, and the working directory, and tells you what is missing before you start a thread. Key-based authentication does the heavy lifting. If a host needs interactive auth or a host-key confirmation, the built-in terminal opens so you can connect once, and every later connection reuses that trust.
How it connects
Section titled “How it connects”Cone opens one multiplexed SSH connection per host and runs everything over it: turns, git operations, file reads, slash-command discovery, and the terminal. Additional threads on the same host share the connection, so a second project on the same server costs no new handshake.
Each remote thread keeps a persistent streaming Claude process on the host. That live channel is what makes remote threads fully interactive: permission prompts appear in Cone and your answer flows back mid-turn, model and access-mode changes apply to the running turn, and stop interrupts cleanly.
Disconnects and recovery
Section titled “Disconnects and recovery”Remote work survives bad networks:
- A dead connection is detected in about 45 seconds instead of hanging on a TCP timeout.
- The thread goes offline with a visible reason and probes for the host with backoff.
- When the host is back, the next turn resumes the conversation with full context from the session state on the remote.
- Quitting Cone kills the remote process cleanly, so nothing keeps running unsupervised on the server.
If the remote claude disappears entirely (uninstalled or moved), the turn fails with the underlying error in the transcript rather than hanging, and the thread recovers as soon as the CLI is back on the host.