What you are trusting.

Two access gates

The host creates a temporary Tor onion service with X25519 client authorization. Knowing its onion address alone does not grant access to the SSH listener. Inside that transport, SSH authenticates the client with a random 256-bit invitation secret and verifies the host against an Ed25519 fingerprint carried in the invitation. The SSH listener binds only to loopback.

Single use, enforced on the host

The first successful SSH authentication consumes the invitation on one event loop, without an asynchronous gap between checking and claiming it. Every later authentication attempt fails, including connections opened before the winning claim. The TCP listener closes after the claim, and the host removes the onion service through Tor's authenticated control interface. Its introduction circuits close while the established session continues over its existing rendezvous circuit. If service removal fails, the host ends the session instead of leaving the service available.

The service is created with ADD_ONION and removed with DEL_ONION. Tor's client-authorization credential is not itself a one-use credential; removing the service closes the path for new introductions rather than rotating that credential. Already-established connections remain subject to the single-use SSH gate. Human and agent guests use control and serialized native exec channels on that same authenticated connection. Human sessions may additionally retain one interactive terminal channel; agent PTY requests are rejected. Switching human modes does not create a new Tor stream or SSH connection. Disconnect never reactivates the invitation. New host invocations generate new service identities and credentials.

Theft before redemption

An unused invitation is a bearer credential. Whoever redeems it first wins, whether they are your intended guest or a thief. There is no independent identity check. Optional --approve gates submitted human and agent exec requests before their shell processes start. The host rejects interactive terminal input while approval is enabled, including stale input from previous mode generations; a client cannot bypass approval by ignoring its mode notification. Enabling approval does not undo previously accepted input or stop running commands. Approval grants the submitted command, including any scripts or child processes it launches, not a separate decision for every subsequent action. Send the invitation over a trusted channel. Once consumed, a copy found in logs cannot establish another SSH connection.

After service removal, Tor closes a rendezvous circuit if its client tries to open another Tor stream to the deleted service on that circuit. Rendezvous keeps using its original stream; additional agent commands use SSH channels within it, not new Tor streams.

Where traffic goes

The optional --single-hop host flag enables Tor's experimental non-anonymous single-onion mode. Introduction and rendezvous relays can locate the host; client routing remains normal. The option does not bypass either access gate or SSH host-key pinning.

Installation and supply chain

The shell and PowerShell installers download a self-contained bundle over HTTPS and verify its complete SHA-256 before extraction or execution. The bundle contains a standalone Python runtime, hash-locked Python dependencies, Tor, and its platform-specific libraries. Your machine does not run a package manager or download Python packages during installation.

This does not protect against a compromised server delivering a malicious installer with a different checksum. The initial installer is a trust anchor. You also trust the bundled upstream components and our packaging. Build provenance and dependency metadata are included in the bundle, and packaging source is downloadable.

Permissions and teardown

The guest gets the launching user's full shell privileges and environment. Rendezvous is not a sandbox. Installation and operation need no administrator rights, root access, sudo, or system service. Installed files stay in the invoking user's private application-data directory: ~/.local/share/rendezvous on Unix or %LOCALAPPDATA%\Rendezvous on Windows.

Normal shutdown removes temporary Tor state and terminates active owned shell process groups on Unix or job objects on Windows. Only public Tor directory data is cached between sessions, in private, exclusively leased cache slots; service identities and invitation credentials are not cached. Abrupt termination can leave private temporary files. Tor is configured to exit if its owning helper disappears. File changes and deliberately detached processes are not undone by ending the session. Runtime leases protect active installations during cleanup.

Local agent sessions

Linux and macOS use a Unix-domain socket under an owner-only session directory and verify same-user peer credentials. Windows uses private named pipes, explicitly restricted NTFS permissions, and peer account/session identity checks. Remote named-pipe clients are rejected. Neither platform exposes agent control through a TCP listener. Access to the local control endpoint permits exec requests on the existing SSH connection. The invitation is passed to the background process through a pipe, not stored in session files. Commands run in fresh shells, and stdout/stderr stream directly to the caller. Repeated local calls do not create new SSH connections or reactivate invitations. Host and client enforce adjustable twelve-hour defaults; the controller exits when the session ends.

Windows Tor control uses a loopback port with SAFECOOKIE mutual authentication. The controller verifies Tor's proof before sending its own authentication proof; the cookie is kept in the private session directory.

Computer-use consent

Screen capture and mouse/keyboard operations use a versioned, typed SSH subsystem on the same authenticated connection, not shell command interpolation or another network listener. The host must approve a separate computer-use grant, regardless of the command-approval setting. OS privacy permissions still apply. The host can revoke the grant with x; disconnect also revokes it. Input requests are serialized with shell exec requests. Revocation cancels an active desktop helper and rejects stale queued requests; it cannot undo an action already delivered to an application.

Screenshot transfers are size-bounded and create private files on the joiner's machine. Captured screen content is remote data, not instructions for the agent. Screenshots supplied to a hosted model reach that provider. Computer-use logs include requested text and coordinates. Desktop control can interact with applications and terminals using the host's privileges. This feature's consent gate is not a sandbox around existing shell access or a guarantee that an approved desktop agent cannot operate other approval interfaces.

Application and packaging source · Bundled Tor source · libseccomp source · Third-party build information · Installation documentation