# Osewa Is Open Source: Replace SSH + tmux for AI Agent Sessions > Source: > Published: 2026-11-04 21:08:48+00:00 Your coding agent has been running for three hours on a remote server when your laptop falls asleep on the train. SSH drops. tmux keeps the process alive — but when you reconnect, you are scrolling through logs blind, hoping nothing needed approval. That is the best-case scenario. [Osewa](https://osewa.dev/) launched today as an open-source project that treats this exact failure as a first-class problem instead of a configuration footnote. ## What Osewa Actually Does Osewa is a remote terminal protocol designed for the age of coding agents. The session lives on the host — not inside the SSH connection — and reconnects automatically when networks change. It runs over [QUIC](https://en.wikipedia.org/wiki/QUIC) with a TLS WebSocket fallback for environments where UDP is blocked (hotel networks, corporate firewalls). QUIC gets a 300ms head start on every connect; if UDP loses, the WebSocket wins transparently. No manual fallback configuration required. The key difference from Mosh: Osewa is agent-aware. It surfaces agent status — running, waiting for approval, idle — through the protocol itself. This is not a dumb PTY forwarded over a pipe. It is a session layer that knows your agent is waiting on a file delete and tells you so when you reconnect from your phone at a conference. ## Why SSH + tmux Is Not a Real Solution The current state of the art is SSH plus tmux or screen. It works, until it does not. Claude Code Remote terminates if the SSH connection drops for more than ten minutes — this is a [documented pain point](https://github.com/anthropics/claude-code/issues/49790) in the Claude Code GitHub repository, with an open feature request for session reconnect. Projects like `remote-ssh-mcp` and `ssh-agent-workspace` exist specifically to wrap tmux in ways that make it slightly less fragile. Osewa’s argument is straightforward: wrapping SSH is not a protocol fix. SSH was designed for interactive commands over a stable connection, not to babysit an agent running for hours while you change networks. tmux solves process survival; it solves nothing about visibility or reconnection. ## Architecture Worth Trusting Osewa is built on [libghostty-vt](https://lib.rs/crates/libghostty-vt), the Rust crate extracted from Mitchell Hashimoto’s Ghostty terminal emulator, now powering JetBrains IDEs 2026.3+ and over 130 other projects. Using a battle-tested VT engine matters: terminal emulation bugs are notoriously hard to find and ugly when they surface mid-agent-run. Transport security uses TLS 1.3 and Ed25519 keys on both ends. SSH is used only to bootstrap the initial key exchange; after that, it is out of the loop. ## Getting Started The setup is three commands: ``` # Start server on the remote host osewa server start # First connection (uses SSH to establish keys) osewa ssh user@host # All subsequent connections (direct, no SSH) osewa connect user@host ``` The SSH bootstrap runs once to exchange Ed25519 keys. After that, Osewa connects directly over QUIC or WebSocket. Your agent session persists across reconnects regardless of network changes. ## Osewa vs SSH vs Mosh | Feature | SSH | Mosh | Osewa | |---|---|---|---| | Session survival | tmux needed | Yes | Yes | | Roaming (IP change) | No | Yes (UDP) | Yes (QUIC/WS) | | Blocked UDP fallback | N/A | Breaks | WebSocket | | Agent status | No | No | Yes | | Maturity | Decades | 10+ years | v0 (today) | | Local echo | No | Yes | No | [Mosh](https://mosh.org/) solved the roaming problem a decade ago and is still worth using on high-latency connections where local echo matters. Osewa does not have local echo yet. Where Osewa wins is the combination of WebSocket fallback — Mosh breaks when UDP is blocked — and the agent-status awareness that neither SSH nor Mosh provides. ## The Caveats This is a v0 protocol launched today by a solo developer. The wire protocol is not finalized. There is no independent security audit. SSH is still required for initial setup. For hobby projects and agent workflows running non-sensitive code, Osewa is worth trying now. For production systems handling credentials or sensitive data, wait for a security review — the TLS 1.3 + Ed25519 baseline is solid, but that is not the same as audited. The [source is on GitHub](https://github.com/rjyo/osewa) under an open license. The developer behind it also built Moshi, so there is relevant prior art in the terminal protocol space. That matters more than the star count on day one. ## The Bottom Line Osewa is early but it is the right idea at the right time. If your workflow involves running agents on remote servers — and in 2026, whose does not — the SSH + tmux pattern was always a workaround. Osewa is the first project that treats the agent session as the first-class object instead of a process you are trying not to kill. Watch this one.