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.
Host runtime
Native or sandboxed
Transport
WebRTC DataChannel
Access policy
Host approves every guest
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
--sandboxA teammate wants to join
Open the share link in a browser, then request a role.
Host selects the role
PERMISSION GATEGuest can send terminal input.
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.
Collaboration that starts
at the terminal.
Share the environment, control access, and work together without turning a terminal session into a screen-sharing call.
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
Host CLI
Your machine · Shell stays local
Starts the session and manages terminal input/output.
Signaling
Session discovery · Connection setup
Helps the peers exchange the information needed to connect.
WebRTC DataChannel
Peer-to-peer · Terminal transport
Carries terminal input and output after connection.
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.
Conceptual connection flow. Signaling and peer connection setup may involve additional steps; this diagram is not a packet-level trace.
ACCESS POLICY
Host stays in control
Guests request access. The host decides whether to allow viewing or control.
LOCAL EXECUTION
Execution stays at the host
MYNA shares terminal interaction rather than moving your shell to a remote server.
TRANSPORT
A connection, not a video call
Terminal I/O travels through a WebRTC DataChannel instead of being streamed as pixels.
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.
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
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
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
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.
IF DEVELOPERS NEED IT
Talk without switching apps
An ephemeral session chat for quick explanations and debugging context, without accounts or persistent messages.
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.
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.
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.
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
Requires Node.js 22.12+ · Docker is only required for Docker sandbox mode.
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