Helping someone troubleshoot a terminal problem remotely often involves a frustrating loop:
“Run this command and send me the output.”
Then you wait for a screenshot, send another command, and repeat the process.
I built rsynx to make that workflow more direct.
What is rsynx?
rsynx is an open-source tool for sharing a live terminal between two people.
It does not require:
- Exchanging SSH credentials or keys
- A public IP address
- Port forwarding
- Inbound firewall configuration
The host remains in control of the session. A guest must be approved before joining, and typing access requires an additional approval.
It can be useful for:
- Remote technical support
- Collaborative troubleshooting
- Pair debugging
- Helping someone manage a Linux machine
- Demonstrating terminal commands in real time
Installation
On Linux and macOS, run:
curl -fsSL https://rsynx.ir/i | sh
The installer downloads the appropriate binary and installs rsynx into your local binary directory.
If you prefer not to pipe an installation script into your shell, you can inspect the script first:
curl -fsSL https://rsynx.ir/i
You can also manually download a binary from the project’s GitHub Releases page:
Download rsynx from GitHub Releases
Windows users can manually download the appropriate binary from the Releases page.
How it works
1. Start a session
The person sharing their terminal becomes the host:
rsynx host
rsynx creates a new session and displays:
- A six-digit session code
- A four-character password
The host sends these temporary credentials to the guest through a trusted communication channel.
2. Join the session
The guest connects using the session code:
rsynx join <code>
For example:
rsynx join 123456
The guest is then asked to enter the four-character password.
Providing the correct code and password does not automatically grant access. A connection request is shown in the host’s terminal.
3. Approve the connection
The host can review the incoming request and either approve or reject it.
Only after approval can the guest enter the shared session.
4. Watch and chat
Once connected, the guest can:
- Watch the host’s terminal live
- Follow commands and output in real time
- Chat with the host on the same screen
This avoids moving constantly between the terminal, screenshots, and a separate messaging application.
5. Request typing control
Watching the terminal does not automatically give the guest permission to type.
If interaction is required, the guest can request temporary typing control. The host must approve this request separately.
The host remains in control and can revoke typing access at any moment.
A deliberate approval flow
Since terminal access is sensitive, rsynx separates the process into explicit steps:
- The guest enters the session code and password.
- The host approves or rejects the connection.
- The guest initially watches the terminal.
- Typing control requires another host approval.
- The host can revoke control whenever necessary.
This workflow is intended to make remote collaboration understandable for both participants while keeping the host in control.
rsynx is not a replacement for SSH
SSH remains the standard choice for persistent, administrative access to remote systems.
However, SSH is not always convenient for a temporary support session. It may require exchanging keys, creating accounts, exposing a reachable address, or changing network and firewall settings.
rsynx focuses on a different use case: temporary, interactive terminal collaboration between two people.
Open source
rsynx is open source and released under the MIT License.
You can inspect the source code, report issues, suggest improvements, or contribute to the project on GitHub:
- Website: https://rsynx.ir
- GitHub: https://github.com/arazshah/rsynx
- Releases: https://github.com/arazshah/rsynx/releases
Feedback is welcome
I would especially appreciate feedback about:
- Terminal compatibility
- Host and guest user experience
- Connection and approval flow
- Typing-control handoff
- Security expectations
- Real-world remote-support scenarios
- Windows, Linux, and macOS behavior
If you try rsynx, please let me know what worked, what broke, and what you would improve.
You can leave a comment here or open an issue on GitHub.
One command to install. One code to connect.
Top comments (2)
The "run this and paste the output" loop is exactly why I ended up building a relay on my own box. Two things I'd watch as you grow the user base: approval UX on the host side (the guest-typing second approval is the right call, most tools skip it), and what happens when the host machine is behind a corporate proxy that kills long-lived websockets — I've had to add a fallback polling path for that and it's ugly.
How are you handling session recording? For remote support, being able to hand someone a replay afterwards is worth more than the live sharing itself, and it also forces you to think early about what gets captured (secrets in shell history, etc.).
Thanks — this is exactly the kind of feedback I’m looking for.
The separate approval for typing control is intentional: joining a session should not automatically grant input access, and the host should always be able to revoke it immediately.
The corporate-proxy/WebSocket case is a great point. rsynx currently relies on a persistent connection, but a fallback transport such as long polling is something I need to investigate as the project grows.
Session recording is not available yet. If I add it, it will need to be explicitly opt-in, clearly visible to both participants, and disabled by default. I also want to think carefully about redaction, retention, encryption, and how users can avoid capturing passwords, tokens, and other sensitive terminal output.
Thanks again — your experience building a relay is especially useful. I’d also be interested to know which proxy environments caused the most problems for you.