What Is Osewa? The Beginner's Guide to the Open Terminal Protocol That Keeps Agent Sessions Alive
CodexFuse Team · 2026-11-05T16:50:48.667Z · 19 min read min read
What Is Osewa? The Beginner's Guide to the Open Terminal Protocol That Keeps Agent Sessions Alive
What Is Osewa?
Osewa is an open terminal protocol that keeps a remote terminal session alive on the host when the network changes, so a long-running coding agent keeps working while you check in from a laptop or phone on any network. It runs over QUIC by default, falls back to a TLS WebSocket when UDP is blocked, and holds the live screen on the host with Ghostty's terminal engine. The project is five days old: its public repository was created on October 31, 2026, and it already has 76 stars, about 15 a day.
Osewa is built by Joel, who publishes code as rjyo on GitHub, and it is not Moshi. Moshi is Joel's separate mobile terminal app for iPhone and Android, and Osewa is the open protocol underneath it. Moshi is one client that can ride Osewa, not the protocol itself.
A SHA-256 hash generator shows the idea Osewa's authentication relies on: a short digest can prove something without sending the secret itself. Osewa proves each device with an Ed25519 key instead of a password. If your agent runs on a remote machine, VPS hosting is the usual way to keep that work separate from your laptop, and Osewa is the session that survives when the connection to that machine drops.
No independent explainer, how-to, or review of Osewa exists anywhere else as of November 5, 2026, apart from one short review on Console and one news piece on RuntimeWire. Everything below comes from the Osewa paper, the public repository, and the official pages of the tools it is compared with, all fetched on November 5, 2026.
| Osewa at a glance | Detail |
|---|---|
| What it is | An open terminal protocol that keeps remote sessions alive across network changes |
| Repository | github.com/rjyo/osewa, created October 31, 2026 (5 days old) |
| Author | Joel (GitHub rjyo), also the developer behind Moshi |
| First release | v0.1.0, October 31, 2026; a second release followed |
| License | Apache License 2.0 |
| Platforms | Linux and macOS hosts, amd64 and arm64; no Windows support |
| Transport | QUIC by default, TLS WebSocket fallback, both on port 7322 |
| Auth | Per-device Ed25519 keys over TLS 1.3; no passwords |
| Multiplexer | None yet — transport only; tabs and splits are a planned later layer |
| Cost | Open source; no pricing page exists |
Why Do Terminal Sessions Die When the Network Changes?
A normal SSH session dies when the network changes because the session is the TCP connection itself. Change Wi-Fi networks, close a laptop lid, or let a phone sleep, and the connection breaks — and the session goes with it.
That was a small annoyance when a terminal held a shell you could reopen. It is a bigger problem now that the shell holds a coding agent mid-task: the agent keeps running on the host, but you lose your window onto it, and reattaching means reconnecting, finding the session, and re-establishing context. The question is how terminal sessions survive network change without giving up the rest of what SSH does.
The usual workaround is SSH plus tmux: tmux keeps the shell alive on the host after SSH dies, and you reattach after reconnecting. That works, but you still reconnect by hand every time the network changes, and the connection itself is still fragile while you type.
Mosh fixed the fragility for interactive use by syncing screen state over UDP, so roaming works. Its screen is kept by its own small emulator with no scrollback, it has no port forwarding, and its last release, 1.4.0, dates to October 31, 2022 — four years before Osewa appeared.
How Does Osewa Keep a Session Alive?
Osewa separates the session from the connection. The session — the shell, its screen, and any input you have not yet seen acknowledged — lives in a process on the host, and connections come and go around it.
On every connect, Osewa races two carriers: QUIC over UDP and a TLS WebSocket over TCP. QUIC gets a 300-millisecond head start, and whichever wins carries the same frames. If UDP is blocked, the WebSocket wins, and nothing needs configuring.
Both carriers are TLS 1.3 on port 7322 with the same pinned device keys, so the race picks a road, never a weaker lock. A dead path is spotted by pings in about a second, and unacknowledged keystrokes are resent exactly once.
Because the host holds the real screen, reconnecting sends one screen snapshot instead of replaying bytes. That is the difference from SSH, which replays the connection, and from Mosh, which syncs state between two emulators.
| Carrier | When it wins | What it carries |
|---|---|---|
| QUIC over UDP | UDP gets through; 300 ms head start | Same frames, 1-RTT handshake, connection IDs survive address changes |
| TLS WebSocket over TCP | UDP is blocked, proxies, hostile networks | Same frames over TLS 1.3, same pinned keys |
| Result | One winner per connect | One session, either road, no configuration |
The author's own lab runs, dated October 31 and November 1, 2026, put numbers on this. During a download on a cellular link, a keystroke echoed in 138 milliseconds over Osewa against 1,714 over SSH, about 12 times faster. Resuming after sleep or an IP change took 0.4 seconds against 1.1 for Mosh and a dead session for SSH.
Connecting and running a command at 120 milliseconds of round-trip time took 388 milliseconds against 1,630 for SSH.
The same runs measured an idle host footprint of 14.3 MB against 27.4 MB for SSH, 13.1 MB less, and a real-world run from Thailand to Tokyo connected and ran a command in 311 milliseconds over QUIC against 1,337 for SSH and 1,993 for Mosh. All of these are the author's own measurements, the median of five runs on netem-shaped links — not independent results — and they are the only performance figures that exist.
Keystrokes travel first. Frames go out by priority — control, terminals, exec, then forwards — under credit-based flow control, and bulk traffic is held to the path's bandwidth-delay product plus 40 milliseconds of queue while you type. Predictive local echo, in the style of Mosh, keeps typing responsive while the network catches up.
What Is the Osewa Wire Protocol?
The Osewa terminal protocol is wire protocol v0, an open contract for frames, sessions, and channels published in docs/PROTOCOL.md in the repository. It is the part any terminal can implement, and the Osewa CLI is the first client.
A session is a long-lived object on the host: a shell, its screen, and its channels. A channel is a stream inside the session — a terminal, an exec command, or a port forward — and each forward gets its own QUIC stream, so a lost packet in a download never blocks a keystroke.
The session is the persistent object and the network path is a replaceable carrier. That is why a session can outlive a total path loss, a restart, or a period of dormancy, and re-anchor with fresh key material.
The protocol details for QUIC live in docs/QUIC.md. The paper is explicit that v0 is the shipped contract, not a finished standard: it is an open protocol from a five-day-old project, and the wire format can still change.
How Does Osewa Authenticate Your Devices?
Osewa has no passwords. Each device gets its own Ed25519 key, and both ends prove who they are with those keys on every connection, under TLS 1.3.
Enrollment happens once, over SSH: osewa login installs Osewa on the host and enrolls the device, and the server's key arrives during that enrollment. There is no trust-on-first-use prompt to click through, because the key is delivered by the SSH session you already trust.
A revoked device is locked out on its next connect. That is the whole revocation story: there is no central account, no hosted identity service, and no password reset flow, because there are no passwords to reset.
The author is candid about where SSH is still ahead. OpenSSH has decades of audits and Osewa has none yet, Osewa adds a second open port alongside SSH, and the device key is a plain file with mode 0600, not one behind a passphrase or an agent. Treat Osewa as a new protocol with a clear trust model, not as a proven replacement.
How Do You Start Using Osewa?
Starting takes five steps, and SSH is involved in only the first. After enrollment, everything — attach, forward, exec, and updates — runs over Osewa on its own port.
- Install the CLI on your machine with curl -fsSL https://osewa.dev/install.sh | sh, which places it in ~/.local/bin on Linux or macOS, amd64 or arm64.
- Enroll once over SSH with osewa login --service me@devbox, which installs Osewa on the host and enrolls your device.
- Attach to a session with osewa attach devbox, which creates the session if none exists.
- Check on your agents with osewa ls devbox, which lists sessions with their agent status.
- Keep the host current with osewa update devbox, which upgrades the host over Osewa with no SSH involved.
| Command | What it does |
|---|---|
| osewa login --service me@devbox | Installs Osewa on the host and enrolls this device, once, over SSH |
| osewa attach devbox | Attaches to a session, or creates one |
| osewa forward devbox 3000 | Forwards localhost:3000 over the same connection |
| osewa exec devbox -- make test | Runs a command with no terminal attached |
| osewa update devbox | Upgrades the host over Osewa, no SSH |
| osewa ls devbox | Lists sessions with agent status |
The macOS builds are signed with a Developer ID and notarized. Building from source needs Rust and Zig, because the terminal engine is libghostty-vt, and make libghostty pins a specific build of it into .cache/.
A second release has already followed v0.1.0, adding session tags and smaller mobile framework builds. Its version string was not visible in the fetched releases page, so this guide does not name it — check the releases page for the current tag before you install.
What Does Osewa Know About Your Agent?
Osewa is agent-aware: it reads the agent's status from OSC 7501, the sequence agents use to report working, blocked, done, or idle, with progress and a message. That status is kept per session, on the host.
osewa ls shows each session with its agent status, so one glance tells you which agent is working, which is blocked, and which has finished. Attaching shows a one-line notice when an agent is blocked or done, so you do not have to scroll back through output to find out.
That is the feature that makes Osewa a protocol for the age of agents rather than a faster SSH. A coding agent can run for an hour while you are on another network, and Osewa tells you what it did instead of making you re-derive it from a scrollback.
If you run Claude Code on a remote host, how to use Claude Code covers the agent itself, and Osewa is the session that keeps it reachable. A watcher such as what SupaYatta is shows the same idea from the other side: it watches agent sessions from the Mac notch, while Osewa keeps the sessions alive underneath.
Colour and capability queries are answered on the host from the terminal's last known colours, and kitty keyboard and graphics sequences pass through. Agent status is the only new idea here; everything else is the terminal behaving the way it already does.
Osewa vs Mosh: What Is Different?
Mosh is the closest ancestor: a replacement for interactive SSH terminals that allows roaming, supports intermittent connectivity, and provides intelligent local echo. Osewa keeps that idea and rebuilds the rest.
| Mosh | Osewa | |
|---|---|---|
| Transport | UDP only (State Synchronization Protocol); no TCP fallback | QUIC raced with TLS WebSocket; works with UDP blocked |
| Session survival | Client and server sync screen state; roams, survives sleep | Session lives in a host process; survives roaming, sleep, server restarts |
| Screen | Its own emulator, no scrollback; mismatches can garble text | libghostty-vt keeps the real screen on the host, with scrollback |
| Beyond the shell | Terminal only — no port forwarding, no exec | Port forwards and exec on the same connection |
| Auth | SSH login, then UDP ports 60000–61000 | SSH once to enroll, then Ed25519 device keys on port 7322 |
| Local echo | Yes, predictive | Yes, predictive, mosh-style epochs |
| Latest release | 1.4.0, October 31, 2022 | v0.1.0, October 31, 2026 |
The resume numbers show the gap the new transport closes. In the author's lab, resuming after sleep or an IP change took 0.4 seconds over Osewa against 1.1 seconds for Mosh, nearly three times as fast, and the Thailand-to-Tokyo run connected and ran a command in 311 milliseconds over QUIC against 1,993 for Mosh, more than six times as fast.
The honest way to read those numbers is as a lab comparison from the new project's own author, not a verdict. Mosh is a proven tool with a decade of use; Osewa is five days old with 76 stars and no audit. The comparison that matters is the model: Mosh syncs state between two emulators, Osewa holds the real screen on the host.
If UDP is blocked on your network, Mosh does not connect at all. Osewa falls back to a TLS WebSocket over TCP, which is the single most practical difference for anyone behind a strict firewall or a captive portal.
Osewa vs tmux: Why They Are Different Layers
Osewa is not a tmux replacement, and calling it one confuses two layers. tmux is a terminal multiplexer: it lets you create, access, and control several terminals from a single screen, detach, and reattach later. Osewa is a transport: it carries a session across network changes.
| tmux | Osewa | |
|---|---|---|
| What it is | Terminal multiplexer | Terminal transport protocol |
| Session survival | Session persists on the host; reattach with tmux attach after SSH dies | Session lives on the host; the connection itself survives the network change |
| Network | Does nothing about the network — you still reconnect over SSH first | QUIC with TLS WebSocket fallback; roaming is built in |
| Tabs and splits | Yes — windows, panes, sessions | Not yet — tabs, splits and workspaces are the planned M5 mux |
| Pairing | Works with SSH, Mosh, or Eternal Terminal | Replaces the SSH session after one enrollment; tmux can still run inside it |
The two are complements, not rivals. You can run tmux inside an Osewa session today, and the planned M5 mux would give Osewa tabs, splits, and workspaces held on the host, like tmux, as one client of the same protocol.
The phrase to keep is "terminal sessions survive network change" — tmux makes the session survive a dead connection, Osewa makes the connection survive the network. One keeps the shell, the other keeps the road to it.
If you already live in tmux, Osewa changes the first step of your day, not the last: you still detach and reattach, but you stop reconnecting by hand every time the network moves.
Osewa vs SSH and Eternal Terminal
SSH is the baseline everything else is measured against, and Osewa still needs it once. For interactive work after enrollment, Osewa replaces the SSH session — the paper's own answer to "does it replace ssh" is yes, for interactive work — while SSH keeps the roles Osewa does not claim, such as file transfer and the decades of audit history.
The comparison with Eternal Terminal is closer than the one with SSH. Eternal Terminal vs Mosh covers the earlier generation of this idea: a shell that reconnects without interrupting the session.
| SSH | Eternal Terminal | Osewa | |
|---|---|---|---|
| Session on network change | Dies with the TCP connection | Survives; auto-reconnects | Survives; session lives on the host |
| Transport | TCP | TCP only, port 2022 | QUIC + TLS WebSocket, port 7322 |
| Screen on the host | None; bytes are replayed | None; forwards the PTY byte stream | libghostty-vt keeps the real screen, with scrollback |
| Port forwarding / exec | Yes | Yes, plus jumphosts and tmux control mode | Yes, on the same connection |
| Local echo | No | No | Yes, predictive |
| Agent status | No | No | Yes, OSC 7501 per session |
| First auth | SSH itself | SSH for initial auth, then its own protocol | SSH once to enroll, then device keys |
Eternal Terminal is the closest cousin: it also uses SSH once, then runs its own resumable protocol, and it also does forwarding. The differences are the transport — TCP only, with no QUIC path — and the screen: Eternal Terminal forwards the PTY byte stream, while Osewa keeps a parsed screen on the host.
As an Osewa ssh alternative, the honest summary is narrow: it is an alternative for interactive terminal work on Linux and macOS hosts, with no Windows support and no audit yet. It is not an alternative for everything SSH does.
What Is Osewa Built On?
Osewa is written in Rust, and its host-side screen is kept by libghostty-vt, Ghostty's terminal engine as a library. That is the osewa ghostty connection in one sentence: the host parses everything the program writes with the same engine a Ghostty window uses to draw it.
The choice matters because of a 2012 problem. No terminal emulator came as a library then, so Mosh wrote its own small emulator — the reason its screen can differ from your terminal's and the reason it has no scrollback. libghostty-vt exists now, so Osewa keeps the exact, modern screen your terminal app draws, including scrollback and reflow on resize.
The library itself is still in development and its API is not yet stable, with breaking changes expected. Osewa pins a specific build, so a future libghostty-vt change does not silently change what Osewa renders.
Moshi enters here as a client, not as the protocol. Osewa is available as an experimental transport inside Moshi on iOS and Android, beside Mosh, and the host needs both Osewa and moshi-hook for it. Moshi is the phone app you drive agents from; Osewa is the open wire protocol that keeps the session alive underneath it.
The wire protocol is v0, documented in docs/PROTOCOL.md with the QUIC details in docs/QUIC.md. The roadmap runs M0 to M6: the wire protocol, surviving sessions, agent awareness, and the CLI are shipped; the Moshi transport is where the project is now; the multiplexer is next; and "every screen" — one layout a terminal, a desktop app, or a phone can attach to — comes later.
Should You Use Osewa Today?
Osewa fits one reader right now: a developer running long coding-agent sessions on a Linux or macOS host, who reconnects from different networks and wants the session — and the agent's status — to survive the move. If that is you, the install is one command and the enrollment is one SSH login.
| You should try Osewa if | You should wait if |
|---|---|
| You run long agent sessions on a remote Linux or macOS host | You need Windows support — it does not exist yet |
| You roam between networks, sleep laptops, or work from a phone | You need tabs, splits, or workspaces — the mux is still roadmap M5 |
| UDP is blocked on your network and Mosh cannot connect | You need an audited, proven tool — Osewa has no audit yet |
| You want agent status at a glance with osewa ls | You need a company, SLA, or support contract behind the tool |
| You are comfortable with a five-day-old open-source project | You want a finished standard — the wire protocol is v0 |
The project is five days old, with 76 stars, zero forks, zero open issues, and 181 commits as of November 5, 2026. Those numbers describe a launch week, not a track record, and they are the reason to try Osewa on a dev box before trusting it with anything that matters.
Console's review, published the same day this guide was written, lands in the same place: it likes the transport, the Ghostty engine, and the per-device keys, and it lists the tradeoffs plainly — transport-only for now, not a multiplexer, and no Windows support. The website animations annoyed the reviewer, which is a fair warning that the project is young in every direction.
Try it where the cost of a surprise is low. Keep SSH working alongside it, watch what the second release changes, and revisit the decision when the multiplexer lands.
Sources
Every fact in this guide was fetched on November 5, 2026. The Osewa paper is the primary source for the design, the benchmarks, and the roadmap, and the comparison pages are listed where they are named.
1. Osewa homepage — https://osewa.dev/
2. The osewa paper — benchmarks, design and roadmap — https://osewa.dev/paper
3. Osewa on Console, reviewed by David Mytton, November 5, 2026 — https://console.dev/tools/osewa
4. RuntimeWire, "Osewa — Open source SSH/Mosh alternative for agent terminals", November 4, 2026 — https://runtimewire.com/article/osewa-open-source-ssh-mosh-alternative-agent-terminals
5. Osewa repository, rjyo/osewa — https://github.com/rjyo/osewa
6. Osewa releases — https://github.com/rjyo/osewa/releases
7. Mosh homepage — https://mosh.org/
8. Eternal Terminal homepage — https://eternalterminal.dev/
9. tmux(1) manual, OpenBSD — https://man.openbsd.org/OpenBSD-6.1/tmux.1
10. libghostty-vt documentation — https://libghostty.tip.ghostty.org/
11. Moshi, "What is Moshi?" — https://getmoshi.app/docs/introduction
12. Hacker News submissions from osewa.dev — https://news.ycombinator.com/from?site=osewa.dev
Frequently Asked Questions
Is Osewa a replacement for SSH?
For interactive terminal work, yes — after a one-time enrollment over SSH. Osewa still needs SSH once to install itself and enroll your device, and SSH keeps the jobs Osewa does not claim, such as file transfer. The paper's own answer is that it replaces SSH for interactive work, not for everything SSH does.
Is Osewa the same thing as Moshi?
No. Moshi is a mobile terminal app for iOS and Android that you use to drive coding agents on a machine you already control. Osewa is the open terminal protocol that keeps the session alive underneath it.
They share an author, Joel (rjyo), and Moshi now offers Osewa as an experimental transport beside Mosh — but they are different products.
Does Osewa work on Windows?
No. Osewa supports Linux and macOS hosts on amd64 and arm64 only, and both the Console review and the repository confirm there is no Windows support. No Windows date has been announced.
Can Osewa replace tmux?
No, not yet. tmux is a multiplexer and Osewa is a transport, so they solve different problems: tmux keeps the shell alive after a connection dies, Osewa keeps the connection alive across network changes. You can run tmux inside an Osewa session today, and a multiplexer is the next item on Osewa's roadmap.
Is Osewa safe to use if it has no security audit yet?
It has a clear trust model — TLS 1.3, per-device Ed25519 keys, no passwords, revocation on next connect — but no third-party audit, and the author says so himself. It also adds a second open port and keeps the device key as a plain file. Try it on a dev box first, keep SSH working alongside it, and do not treat a five-day-old protocol as proven.
