v0.1 · zero-relay protocol, audited

End-to-end encryptedterminal sharing. Zero relays.

Stream a live shell over WebRTC with a clean Google OAuth handshake. Bypass SSH relays for secure, peer-to-peer remote execution — your terminal bytes never touch our servers.

$npx share-terminal start
No keystrokes through our infra140 KB CLI · zero install for viewer
~/work · share-terminalidle
$ npx share-terminal start
protocolwebrtcrelaynonee2eedtls-sctp
WebRTC DataChannelDTLS-SCTP end-to-end encryptionGoogle OAuth · device flow6-digit identity-locked pairing7-byte framing protocol10-minute session JWT140 KB CLI · zero install for the viewerNo keystrokes through our infraNo session recordingRedis holds only pairing codes (2 min TTL)WebRTC DataChannelDTLS-SCTP end-to-end encryptionGoogle OAuth · device flow6-digit identity-locked pairing7-byte framing protocol10-minute session JWT140 KB CLI · zero install for the viewerNo keystrokes through our infraNo session recordingRedis holds only pairing codes (2 min TTL)
01finding the wedge

Where the incumbents fail.

Developers don't switch tools unless the technical superiority is obvious. Here's the landscape — and the exact gap share terminal fills.

ToolArchitectureCritical flawShare terminal's wedge
SSH reverse tunneling (relayed)
All keystrokes and output flow through their central server. A no-go for strict compliance or zero-trust DevOps environments.
Zero-relay P2P. True end-to-end encryption. No third party ever sees terminal data.
WebRTC (direct P2P)
Abysmal UX. Users copy-paste massive Base64 connection strings over Slack to establish the handshake.
Identity-locked handshake. A clean 6-digit OAuth pairing code that steps out of the way instantly.
Heavy desktop / IDE plugin
Requires heavy desktop installations or specific IDE bindings. Too slow for a quick "jump in and fix this" session.
Browser-native viewer. 140 KB CLI for the host, zero install for the viewer. Instant deployment.
02the architecture

The server brokers the handshake.
Then it gets out of the way.

Most "share your terminal" tools relay every keystroke through their backend. We don't. Here's the exact lifecycle.

host
cli · 140 KB
signaling server
brokers only · then exits
viewer
browser · zero install
  1. 01oauth

    Identity verification

    Host and viewer authenticate via Google OAuth. The server matches the two sub claims before issuing any pairing token.

  2. 02signaling

    ICE handshake brokered

    The server passes offer / answer / ICE candidates between the two browsers over a 10-minute JWT-authenticated WebSocket. It never reads frame payloads.

  3. 03p2p

    Server disconnects

    Once ICE completes, a direct DTLS-encrypted SCTP DataChannel forms between host and viewer. The server is out of the path.

03security

Six guarantees, audited end-to-end.

We don't ask you to trust us. We ask you to read the protocol — it's short and we link straight to it.

Peer-to-peer by design

Terminal bytes flow directly between host and viewer over a WebRTC DataChannel. The server only brokers the initial handshake — it never sees a single keystroke or character of output.

End-to-end encrypted

The DataChannel runs over DTLS-secured SCTP. Anyone sitting between the two browsers — ISP, proxy, observer — sees only ciphertext.

Nothing is stored

No session recordings. No transcripts. No log of commands. Redis holds the pairing code for 2 minutes — that is the entire footprint.

Identity-locked pairing

The viewer must sign in with the same Google account as the host. Leaked codes are useless — claim attempts are rejected with 403.

Short-lived tokens

Session JWT to the signaler expires in 10 minutes and is bound to a single session, sub, and role. Replays don’t cross sessions.

Open & inspectable

A 7-byte framing protocol on top of one DataChannel. The whole CLI is 140 KB and you can read the entire wire layer in an afternoon.

04use cases

Targeted at the workflows incumbents can't serve.

Browsable shells unlock workflows that ssh-tunneling tools can't safely do. Two pillars where the architecture pays off, and a handful of adjacent wins.

mobile coding

Drive Claude Code or Codex from your phone

Leave share-terminal running on your laptop in private mode. Open the join page on your phone's browser, claim the code with the same Google account, and you're typing into your laptop's shell — Claude Code, Codex, vim, anything. Build apps on the train.

See the full use case
pair debugging

Two engineers, one shell, no screen-share lag

Share a live PTY with a teammate. They watch your output and can type into the same shell — every keystroke flows directly between your machines over WebRTC. No video stream, no input lag, no "wait, can you scroll back up?"

See the full use case
remote support

Support a customer's machine without VPN or open ports

Your customer runs one outbound command. You join from a browser and drive their shell. No inbound firewall changes, no SSH keys, no VPN provisioning — and terminal bytes never cross our servers or yours.

See the full use case
coding interviews

Live technical screens in a real shell

Candidate runs the CLI on their own machine. Interviewer joins from a browser and can take over to demo or unblock. You see exactly who claimed the code before any bytes flow.

timezone hand-off

Hand off a long-running shell across timezones

Leave a repro, a deploy, or a flaky-test loop running. The next engineer picks up the same live PTY in their browser and continues from your cursor — no rebuild, no "what state were you in?"

CLI demos

Let prospects drive your CLI in their browser

Real TUIs — vim, k9s, lazygit, your own product — running on a host you control, driven by a prospect with zero install. Closer to a demo console than a recorded GIF.

mentoring

Fix a learner's broken config from inside their shell

A student hits a wall on their own machine. They start a private session; you join, type the fix in their actual environment, leave. No "share your screen" gymnastics.

05how it works

Four moves from typed command to live shell.

  1. 01

    On your laptop

    $ npx share-terminal start

    The CLI signs you in with Google (device flow), asks the server for a 6-digit pairing code, and waits.

  2. 02

    In any browser

    enter code · 482017

    The viewer opens the web app, signs in with the same Google account, and types the code. The server matches the two identities and hands both sides a short-lived session token.

  3. 03

    Direct WebRTC handshake

    → datachannel open

    Both ends exchange offer/answer/ICE through the signaling server. The moment ICE completes, an encrypted DataChannel forms between them — the server steps out.

  4. 04

    Live, end-to-end

    $ vim ~/.config/st/...

    PTY output streams as OUTPUT frames, keystrokes return as INPUT, resize as RESIZE. Bytes never touch a relay. Close the tab and the CLI exits.

get started

One command. One encrypted tunnel.

No global install. No SaaS dashboard. No account to provision — sign in with Google, pair, share.

$npx share-terminal start
140 KB CLINode ≥ 20macOS, Linux