Screen-share is a pixel feed pretending to be collaboration
Zoom or Meet sharing your terminal is a stream of pixels. Your teammate sees a blurry version of your shell, can't select text without you stopping and pasting for them, and asks you to scroll back constantly because their copy of the buffer doesn't exist. Worse, when they suggest a fix, you type it — which is slower than them typing it.
share terminal trades the pixel feed for a real PTY. Your teammate's browser is a true terminal client: their keystrokes go into your shell, your shell's stdout goes back to their browser at byte-level fidelity. Selection, scrollback, copy-paste — all of it works because they aren't looking at a video, they're looking at a terminal.
How a pair session goes
- 01
Start a public session
Run `share-terminal start --public`. The CLI prints a 6-digit code. Public mode means any signed-in teammate can claim it within the 2-minute window.
- 02
Drop the code in your team chat
Paste the code into Slack, Discord, or wherever the pair conversation is happening. Before the code is claimed, the CLI shows you who attached — their Google email, name, and IP.
- 03
Both type. Both see the same output.
Your keystrokes and theirs land in the same PTY. The shell doesn't know which keyboard is which. You can run tests, they can grep through logs, you both watch the same vim buffer scroll.
- 04
Close the tab to end
When they close the browser tab, the CLI exits cleanly. Nothing was recorded, nothing is left listening on your machine.
Patterns we see work well
Repro hand-off
You've gotten a flaky test to fail once. Don't lose the state — start a session in the same shell, hand it to whoever owns that area, let them poke at the live process.
Deep debugger session
You're inside pdb, gdb, or a node `--inspect` REPL. Pulling a teammate in over share-terminal lets them step through the program with you instead of guessing from a screenshot.
Onboarding deep-dive
A new hire is lost in the build pipeline. Give them your shell for thirty minutes so they see the real commands, in the real env, with the real errors.
"You drive, I'll watch"
Sometimes the right move is to let the other person own the keyboard. The PTY doesn't care who sends the bytes — start the session, hand them the code, sit back.
What it isn't
share terminal pairs two people on one shell. It is not a broadcast tool. The CLI accepts a single viewer per session — pairing, not presenting.
It also isn't a permission system. Once your teammate is in the shell, they have whatever your shell has. If that's more authority than you want to hand over, run the CLI as a scoped user, inside a container, or in a worktree of the project you actually want to pair on.
Starter: pair on a failing test
A reproducible flow — share a focused shell scoped to the area you're debugging.
- 01
Reproduce the flake one more time. Do not clear the shell — your env, vars, and scrollback are part of what your teammate will need to see.
cd ~/code/your-repo pnpm test --filter your-package -- -t "the flaky one" - 02
From the same shell, hand it over. Public mode lets any teammate signed in to share terminal claim the code.
share-terminal start --public - 03
Paste the printed code in your team chat. Before any bytes flow, the CLI prints who claimed it — Google email, name, and IP — so you can confirm it's the right person.
✓ pairing code 482017 · expires in 1:48 → viewer attaching · [email protected]