Choose who can watch. Choose who can type.
A shared terminal gives real access to a process on your computer. Keep credentials private, use read-only when possible, and understand the MCP boundary.
On this page
Start with the access you need
Interactive access is the default. Anyone with the complete link and password can view and type with the wrapped process’s operating-system permissions.
For demos, reviews or a second screen that only needs to watch, create a read-only session.
shell --read-only claude- Input is rejected by both the relay and the CLI. A modified browser cannot turn this into an interactive session.
Keep the link, password and QR private
The QR code includes the password for one-scan access. Treat it like the link and password together. Do not put it in a public screenshot.
Removing someone from an account cannot erase a password they already know. Rotate active session credentials when that access must end.
shell password rotate <ID>- Disconnect old viewers, change the password and salt, and revoke existing MCP grants. The process keeps running.
Files require their own opt-in
Files are not shared by default. --files exposes regular files under the working directory; --files-root chooses a root. Requests are checked on the host, including traversal and symlink-escape checks.
Read-only terminal access does not cancel file access you explicitly enabled. Choose the root carefully.
What the service can see
With default E2EE, the host encrypts terminal payloads before the relay forwards them. The relay carries authenticated ciphertext, plus visible connection metadata.
- Visible metadata
- Connection IPs, timing, encrypted sizes, frame types, labels, access mode, lifecycle and terminal grid dimensions.
- MCP exception
- Issuing a grant authorizes server-side, in-memory decryption. The controller receives plaintext results. The browser disclosure remains for the grant’s lifetime.
- No-E2EE exception
- An explicit --no-e2ee session exposes terminal contents to the relay. HTTPS/WSS still protects the network hop.
What is retained
The host keeps bounded screen/replay state. The hosted relay also keeps a bounded last-screen cache for offline viewing: ciphertext in E2EE mode, potentially plaintext with --no-e2ee.
MCP’s durable records contain bearer hashes, grant metadata and operation fingerprints/outcomes—not plaintext terminal contents, bearers or frame keys. Ordinary task exit deletes its relay session state. This is not a full-history archive.
Encryption does not remove every trust
The browser code served by the website is trusted while you view a terminal or unlock your vault. E2EE does not protect against malicious code on either endpoint, or hide traffic timing.
Browser-started processes also trust the account service after you explicitly enable remote start. Use a restricted workspace and local permissions appropriate to the task.
If you shared too much
Rotate a leaked browser password; revoke a leaked MCP grant. Stop the specific target if its actions are unsafe. These actions cannot undo earlier commands or remove copies someone already made.
Encryption details explain key derivation and replay protection. MCP access explains grants and uncertain delivery.