p2pmux — a terminal multiplexer where every pane runs on its owner’s own machine

[pelazas]

p2pmux — a terminal multiplexer where the grid spans machines instead of collapsing onto one box.

Zellij-like tabs, panes and nested splits, except every pane is a PTY on the machine of whoever opened it, with that machine's shell, PATH, env and subscriptions. You join with a ten-character code and land in one grid where some panes are on your laptop and some are on a teammate's, on their own network and their own OS. Take control of a free pane by typing into it; presence gives a color per member and shows who is watching what.

The case that made me build it: two developers, two Claude subscriptions, one session. Your teammate drives Claude Code in a pane hosted on your machine, on your subscription, and never touches your key — the process and the credential files never leave your disk. The pane beside it is on their box with their Python env, and you drive that one without installing anything. Both halves are true at once, and the README says so plainly: whoever holds a pane has a real shell as you. It is a trusted shared shell, not a sandbox.

It is also useful with nobody else in the room. Bare p2pmux opens an inbox listing every Claude Code, Codex, Cursor, Pi and OpenCode agent running on every machine in the session, sorted by which one is blocking you — one laptop and two droplets is a normal session. State comes from the agents' own hooks, never from guessing at output timing, and an agent with no hooks says state unknown rather than being guessed about.

What iroh does here. Every pane's byte stream is an iroh (1.0.3) connection between the two peers that actually need it — direct when hole-punching works, over a relay when NAT says no. The tab bar prints which one you got, direct 55ms or relayed 120ms, and that turned out to be the single most reassuring piece of UI in the whole thing: people trust the session once the terminal tells them how it is connected. The ten-character code is good for six hours and is backed by a plain ticket that contacts no service at all, for when our rendezvous is down. No account, no server for anyone to run; the only thing I host is a mailbox that hands over an encrypted join code and forgets it. If the coordinator's laptop closes, every pane elsewhere keeps running and after five minutes the earliest-joined survivor takes the role over.

Getting NAT traversal for free is why this exists at all. I had budgeted weeks for writing and operating the rendezvous half myself, and iroh deleted that entire work item.

macOS and Linux, both architectures, MIT, Rust:

curl -fsSL https://p2pmux.com/install.sh | sh

p2pmux                       # you host; Ctrl+S shows the join line
p2pmux join 4KP7Q-M2XRW      # them, on their own machine

Early — v0.1.10 — but sessions run between continents today. The iroh-side thing I would most like other people's experience on is interactive latency: a keystroke has to round-trip before the character appears, so the relay path is felt in a way that a file transfer never is. If you have shipped something latency-sensitive on iroh, I would like to hear what the relay path felt like to your users, and whether you did anything beyond hoping for a direct connection.