Browser-first · peer-to-peer terminal sharing

Your terminal.
Their screen.
Your machine stays yours.

Share a live shell through a link. Your teammate joins from a browser or CLI, requests view or control access, and connects over WebRTC. Choose native mode for trusted teammates or a sandbox for stronger isolation.

Click to copy the npm install command

Contribute
myna / shared session
Product walkthrough

Host runtime

Native or sandboxed

Transport

WebRTC DataChannel

Access policy

Host approves every guest

Host · shared shell
PTY

MYNA / HOST / SESSION

$ myna up --sandbox

✓ Sandbox started · limits configured

✓ Room code and share link created

… Waiting for a guest to request access

Guest requests: view · control

✓ Host approves the requested role

↔ Terminal I/O over WebRTC DataChannel

host@myna:~$
ILLUSTRATIVE TERMINAL OUTPUTSandbox available with --sandbox
Browser guest
Join flow

A teammate wants to join

Open the share link in a browser, then request a role.

Pending
https://…/#room-code

Host selects the role

PERMISSION GATE
Control

Guest can send terminal input.

View

Guest can watch, not type.

Illustrative UI — access is approved or denied by the host.

Peer-to-peer data path

Signaling brokers the handshake. Terminal I/O and resize events travel over the WebRTC DataChannel.

No guest install · No account · Host-controlled access

Native shell or isolated sandbox

Native mode

For people you trust.

Docker sandbox

Containerized sessions with resource limits.

Linux bubblewrap

Namespace-based sandbox option.

18–25 MB

Native CLI idle RAM

< 0.5%

CPU during streaming

256 MB

Docker sandbox RAM cap

15–50 ms

Reported direct P2P ping

PRODUCT WALKTHROUGH · NOT A LIVE SESSION · Performance depends on the environment.

What makes MYNA different

Collaboration that starts at the terminal.

Share the environment, control access, and work together without turning a terminal session into a screen-sharing call.

01 / 03

HOST + GUEST

One terminal. Two peers.

Share a terminal session with a teammate through their browser. The host runs the shell; the guest joins without installing a separate terminal client.

MYNA / CORE
02 / 03

HOST-CONTROLLED ACCESS

You decide who can type.

Guests request access, and the host approves their role. Keep a session view-only or grant control when collaboration requires it.

MYNA / CORE
03 / 03

PEER-TO-PEER TRANSPORT

Built around WebRTC.

A signaling server helps peers establish a connection. Once connected, terminal input and output travel over a WebRTC DataChannel.

MYNA / CORE
Under the hood

One shell.
A direct connection.

MYNA coordinates the connection, then lets peers exchange terminal data over WebRTC. Your shell runs on the host machine, while the host retains control over guest access.

MYNA / CONNECTION FLOW

From local shell to remote collaborator

SESSION FLOW
01

Host CLI

Your machine · Shell stays local

Starts the session and manages terminal input/output.

02

Signaling

Session discovery · Connection setup

Helps the peers exchange the information needed to connect.

03

WebRTC DataChannel

Peer-to-peer · Terminal transport

Carries terminal input and output after connection.

04

Guest

Browser or CLI · Approved access

A teammate joins and uses the permissions granted by the host.

Access remains host-controlled

The host approves guest permissions before collaboration begins.

Trust boundary

Conceptual connection flow. Signaling and peer connection setup may involve additional steps; this diagram is not a packet-level trace.

01

ACCESS POLICY

Host stays in control

Guests request access. The host decides whether to allow viewing or control.

02

LOCAL EXECUTION

Execution stays at the host

MYNA shares terminal interaction rather than moving your shell to a remote server.

03

TRANSPORT

A connection, not a video call

Terminal I/O travels through a WebRTC DataChannel instead of being streamed as pixels.

Where MYNA is headed

The foundation is here.
Now let's make it useful.

The core terminal-sharing experience is built. The next steps are about trust, reliability, and discovering what makes developers want to collaborate with MYNA again.

IMPLEMENTED

PHASE BUILT

Share the shell.

The core experience is here: a teammate can join your real terminal from a browser or the CLI.

  • Peer-to-peer terminal streaming
  • Browser and CLI guest workflows
  • Host approval and view/control roles
  • Native shell with optional sandbox backends
  • Freeze controls, guardrails and audit logging
Implemented · Phases 1–9
HARDENING

PHASE IN PROGRESS

Make trust dependable.

Implementation is ahead of release validation. The priority is closing security gaps and testing real-world behavior.

  • Authenticated peer-handshake design
  • Safe failure behavior for security controls
  • Rate limits and TURN lifecycle verification
  • Cross-platform installation testing
  • Reproducible security test evidence
Security & release readiness
VALIDATION

PHASE THE NEXT STEP

Learn from real developers.

Before adding more features, find out whether MYNA solves a real collaboration problem and where the experience breaks down.

  • Run structured sessions with 8–10 developers
  • Target joining a prompt in under 60 seconds
  • Measure how many guests connect without help
  • Track unprompted repeat use over two weeks
  • Let repeated user requests guide the next build
Validation · Phase 13

Possibilities, not promises

What could collaboration become?

These ideas are deliberately on hold. We’ll build only what validation shows developers actually need—not a pile of features for the sake of a roadmap.

01

IF DEVELOPERS NEED IT

Talk without switching apps

An ephemeral session chat for quick explanations and debugging context, without accounts or persistent messages.

Exploring
02

IF FILE SHARING HELPS

Pass around logs and patches

A careful way to share relevant files during a debugging session, with size limits, integrity checks and safe handling.

Exploring
03

IF DEBUGGING NEEDS IT

Go from issue to session

Bring a bug report into a collaborative terminal session, so teammates can investigate the same problem together.

Exploring
04

IF THE EVIDENCE SUPPORTS IT

A better debugging handoff

Explore session context, read-only code viewing and diffs if real users show that these would make collaboration easier.

Exploring

Have a real problem MYNA should solve?

Explore the code, share feedback, or contribute an issue.

Contribute
MYNA · Open-source terminal sharing

Your shell. Your approval. Your choice of isolation.

Need a second pair of eyes? Share the terminal.

Start a session, send your teammate a link, and approve view or control access yourself. Keep your usual shell for trusted collaborators, or choose a sandbox when you need stronger isolation.

Peer-to-peer

Terminal I/O over WebRTC

Host-approved

Choose view or control

3 runtime paths

Native, Docker, experimental bwrap

Explore on GitHub

Requires Node.js 22.12+ · Docker is only required for Docker sandbox mode.

Built in the open

Better debugging starts with sharing the real terminal.

MYNA lets a teammate join from a browser or CLI, request view or control access, and collaborate over WebRTC. Try it, report a bug, or help improve the project on GitHub.

npm install -g myna-cli