Session Sharing

Share a session to a web browser

ssh-tool can share a live session with a colleague who opens a link in a plain web browser - no ssh-tool on their side. They watch your terminal, or, with your explicit approval, type into it. You stay in control: you choose what to share, you approve every guest, and you confirm a short word-code with them so a leaked link is worthless.

It is off by default and per-guest opt-in. Nothing is streamed until you click Allow.

How it works, in one picture

  colleague's browser  ──https (self-signed)──▶  ssh-tool app
  (any machine that can                          (serves the guest page +
   reach yours: LAN / VPN)                        a websocket per guest)

Your ssh-tool serves a small guest page and a websocket over HTTPS on a network interface you choose. There is no cloud relay - both machines must be able to reach each other, on a LAN or over a VPN (your WireGuard / NetBird / Tailscale profile works).

Setup

1. Settings -> Sharing -> Enable session sharing. Off by default. While it's on, this page shows the certificate fingerprint (a short word-code) and lets you regenerate it.

2. Right-click a tab -> "Share to browser". The dialog lets you pick:

   • Which tabs - defaults to the current tab. It's a snapshot: tabs you open later don't appear to the guest unless you add them (right-click -> "Add to share").
   • Read-only (the guest can only watch) or full control (the guest types into the same terminal as you, tmux-style).
   • History - whether the guest sees your existing scrollback or only new output. Default: only new output (the scrollback may contain something you cat-ed earlier).
   • Network - which interface to serve on (not 0.0.0.0 by default) and the port (8443; if it's in use the share falls back to a free one).

3. You get a link and a word-code like cobalt-otter-viola-medley. Send the link to your guest, and send the word-code separately (phone or chat, not in the same message).

Joining, from the guest's side

The guest opens the link. Their browser warns about the self-signed certificate

• that's expected; they click through. They then see a "waiting for you to let them in" screen showing the same word-code.

Approving a guest

When a guest connects, you get a prompt showing their IP address and the word-code. Read the code back with them out-of-band; if it matches, allow them in. If it doesn't match, deny - someone may be intercepting the connection. The prompt flashes the taskbar and pops a notification if the app is in the background.

This approval - plus the word-code comparison - is what actually authenticates the session. The browser's certificate warning is not the security boundary; your Allow click is.

While a guest is watching

• A marker appears on the shared tab. A full-control guest is shown loudly: a red banner across the top of the window ("A browser guest can type in this terminal").
• The status bar has a share segment listing attached guests. From there you can kick one guest or stop all sharing in one click.
• If a guest clicks to a different tab than you, a small ring marks the tab they're looking at.
• Live layout: splitting a shared tab, switching tabs, and adding a tab all follow through to the guest. The guest can follow your active tab or click around on their own; a "Follow host" button re-syncs them.
• Closing the shared session (or the whole tab) ends the share and disconnects the guest.

Read-only vs full control

Read-only is enforced on the backend, not just hidden in the guest's UI - a read-only guest's keystrokes are rejected server-side. A full-control guest types into the same PTY you do (interleaved input is normal tmux behaviour).

Security notes

• Encrypted with a self-signed certificate. The fingerprint (the word-code) is stable across shares and restarts; a change means either you regenerated it or something is wrong.
• No cloud relay. Reachability is your responsibility - use a LAN or your own VPN profile. Binding to a specific interface (not 0.0.0.0) keeps a share off networks you forgot you were on, but the real access control is your approval.
• Local shells are shareable too, not just SSH sessions.
• Optionally, guest keystrokes can be recorded to the audit log (Settings -> Sharing). Off by default: the audit log is plaintext on disk, and a controlling guest's keystrokes can include passwords.
• Guest links expire if unused (30 minutes); a used link stays valid for the share's life so a guest can reconnect after a network blip.

See also

• LLM integration (MCP) - the same "share a live session" idea, but with an LLM client instead of a browser.