Dinotty
A multi-device terminal server for AI coding agents: server-side VTE, session persistence, file browser and plugins. Self-hosted, never lose a session across phone, tablet and desktop.
Evidence shows deliberate security design: dual token/verification-code login, capability-based token permissions, zeroize for secrets, documented emergency recovery, 409 lockout prevention on plugin uninstall. However most of this is README self-description; actual server auth implementation is not in evidence, so scores stay at 2. Dependency security deducted: no lockfile/audit/deny evidence, and russh-keys pins a beta (0.50.0-beta.7). Source attribution deducted: deb maintainer is 'Dinotty Contributors <[email protected]>', anonymous and non-traceable.
CI covers frontend build/type-check, clippy -D warnings, cargo test; tests present are real and detailed (AboutTab update-check scenarios). Version references are consistent (0.25.1; 0.20.0 is test fixture data). Deducted: error-message quality only appears indirectly; server-side failure paths (SSH failures, PTY crash recovery) lack direct evidence.
Clear positioning for multi-device terminals for AI coding agents; covers macOS/Linux/Windows, DINOTTY_SHELL override, responsive layouts. Deducted: the web-preview reverse proxy may expose local dev servers under login protection without explicit boundary description, so trigger_precision is thin.
Install notes are thorough (per-platform, systemd, unsigned-macOS xattr workaround, verification-code recovery) — full marks. MIT license text consistent (though the 2026 copyright year is slightly odd). Full doc index present. Deducted: no CHANGELOG file evidence; versioning is only described via a linked release guide; maintenance is a personal repo with an anonymous deb maintainer — weak update-path evidence.
Value proposition (text-level transport vs remote desktop, quantified ~1-10 KB/s) and differentiation (server-side VTE session restore vs ttyd/gotty) are clear; server-side VTE + persistent PTY is genuine engineering effort. Deducted: bandwidth/latency figures are asserted without benchmark evidence.
Key security claims link to dedicated doc pages (traceable), but core implementation source is not in the provided evidence, so static review must rely on docs. Quantified claims (bandwidth multipliers, comparison table) cannot be cross-verified; separation of fact from inference is weak, especially in competitive comparisons. No executed verification performed (confidence: low).
- Core auth/permission implementation source is not in evidence; security claims (verification-code login, token permissions) should be treated as documentation-level promises, not verified facts.
- russh-keys is pinned to a pre-release beta (0.50.0-beta.7); evaluate stability before production use.
- The server listens on port 8999 by default and exposes terminal, SFTP, SSH credentials, and filesystem access; secure reverse proxy/firewall and independent auth review are required before public deployment.
- Web preview reverse proxy and the hot-reloadable JS plugin system (event subscriptions, HTTP API) enlarge the attack surface; treat third-party plugins as untrusted code.
- No CHANGELOG or third-party audit evidence found; track behavior changes across Releases yourself.
- The Linux one-liner downloads and sudo-installs from GitHub; verify checksums before running.
What does this agent do, and when should you use it?
Dinotty is a self-hosted multi-device terminal server written in Rust, built to run AI coding agents such as Claude Code, opencode, Codex, and OpenClaw on any device. The backend uses Axum 0.7 and Tokio with portable-pty to run a full VTE state machine on the server, so PTY processes survive disconnects and a page refresh restores your exact session. The frontend is Vue 3 + TypeScript with xterm.js 5, and an optional desktop client is built with Tauri. Terminals, plugins, files, SSH, and web previews are all draggable panes with multi-workspace isolation and a Mission Control overview. It transmits text only (~1–10 KB/s), requires no relay or subscription, and is designed for weak-network and mobile scenarios.
You start dinotty-server on your machine (default port 8999) and open http://<ip>:8999 in a browser, logging in via a token or a 6-digit verification code. A server-side VTE parser maintains the exact screen state at all times; the client auto-reconnects with exponential backoff and restores the session on refresh. The pane system combines terminals, a built-in file browser (code highlighting, Markdown rendering, Office preview, audio/video playback), SSH/SFTP remote connections, Git change indicators with inline diff, and web preview via a built-in reverse proxy for local dev servers — all draggable across tabs. Broadcast mode executes input from one pane in all panes simultaneously; command bookmarks support right-click capture and one-click execution. The plugin system supports hot-reloadable JS plugins with a CLI bridge, shipping with CC Switch, JSON Formatter, and a Claude Code conversation manager. There is also a notification system (terminal bell/OSC detection, WebSocket push), system monitor charts, a command palette, an Open API HTTP endpoint for external control, and a built-in MCP JSON-RPC server so AI assistants can operate terminal sessions.
- A developer mid-task with Claude Code on a desktop who needs to take over the same session from a phone or iPad while away from the desk.
- Ops engineers or developers using the built-in SSH client and SFTP file management to treat remote servers like local terminals.
- Server-side engineers juggling many machines, using the server list and multi-workspace isolation to manage connections.
- Remote coders on 3G/4G who need text-only transport and auto-reconnect instead of bandwidth-hungry, laggy remote desktop.
- Power users extending the terminal via hot-reloadable JS plugins, command bookmarks, and the Open API (Stream Deck, Shortcuts, automation scripts).
- Teams letting AI assistants automate terminal work through the built-in MCP JSON-RPC server.
What are this agent's strengths and limitations?
- Server-side VTE rather than a WebSocket-to-PTY pipe: PTY processes survive disconnects and the exact screen state is restored on refresh — the core differentiator vs ttyd/gotty/Wetty-style tools.
- Text-only transport of ~1–10 KB/s, 100–1000x less bandwidth than remote desktop (VNC/RDP/Parsec); smooth on 3G/4G with low battery drain.
- Self-contained environment: file browser, Git change indicators, SSH/SFTP, web preview, and plugin system all built in.
- Self-hosted with no subscriptions or relay fees; your data stays on your machine; MIT licensed.
- Strong extensibility: hot-reloadable JS plugins, Open API HTTP endpoint, built-in MCP server, capability-based multi-token permissions, and audit log/webhooks.
- The macOS build is unsigned and requires manually running an xattr command to remove the "damaged" restriction — friction for non-technical users.
- Building from source requires a Rust toolchain plus a pnpm/Node.js frontend build, a non-trivial compile cost.
- Verification-code login depends on an installed notifier plugin subscribed to the auth.verification_code event; uninstalling such a plugin is rejected with 409 and lockout requires a documented emergency recovery procedure.
- As a self-hosted service, you manage deployment (systemd/Docker), port exposure, and token security yourself.
- On Windows, default shell detection follows a DINOTTY_SHELL → pwsh.exe → powershell.exe → cmd.exe order and may need manual configuration in non-PowerShell environments.
How do you install or deploy this agent?
Option 1: download from GitHub Releases — macOS: .dmg (unsigned, so run xattr -cr /Applications/Dinotty.app after install); Linux: .deb (sudo dpkg -i dinotty_*.deb), start with systemctl start dinotty and enable on boot with systemctl enable dinotty; Windows: run .exe (in PowerShell: .\dinotty-server.exe -p 8999, optionally set $env:DINOTTY_SHELL = "pwsh.exe" to override the default shell). Linux one-liner: VERSION=$(curl -s https://api.github.com/repos/xichan96/dinotty/releases/latest | sed -n 's/.*"tag_name": *"\([^"]*\)".*/\1/p' | sed 's/^v//') && curl -LO "https://github.com/xichan96/dinotty/releases/download/v${VERSION}/dinotty-server_${VERSION}-1_amd64.deb" && sudo dpkg -i "dinotty-server_${VERSION}-1_amd64.deb". Option 2: build from source — git clone --depth 1 --single-branch -b dev [email protected]:xichan96/dinotty.git, then in the frontend directory run pnpm install && pnpm run build, and back at the repo root run cargo run. Requires a Rust toolchain plus pnpm/Node.js.
How do you use this agent?
After starting the server, open http://<your-ip>:8999 in a browser (default port 8999; use -p to change, e.g. dinotty-server -p 3000). Log in with the default token, or switch to verification-code login under "Security & Access" (requires a notifier plugin subscribed to the auth.verification_code event, e.g. feishu-notify; codes are valid 5 minutes, single-use, invalidated after 5 wrong attempts; if locked out, edit ~/.dinotty/settings. on the server host — %APPDATA%\dinotty\settings. on Windows — set auth.login_method back to "token", and restart the service). Once logged in, run Claude Code, opencode, Codex, etc. in panes; sessions survive disconnects and page refreshes. For debugging use RUST_LOG=debug cargo run; type-check the frontend with npx vue-tsc --noEmit.
How does this agent compare with similar options?
The README includes an explicit comparison with remote desktop solutions (VNC/RDP/Parsec): Dinotty transmits text only (~1–10 KB/s typical) while remote desktop streams full-screen pixels at 30–60 fps (~1–10 MB/s, 100–1000x more); Dinotty wins on weak-signal tolerance, battery consumption, and resolution adaptation. A dedicated doc also compares against ttyd/gotty/Wetty and other AI coding remote solutions (docs/en/getting-started/comparison.md), with the key difference being Dinotty's server-side VTE state machine versus pipe-forwarding, enabling session recovery after disconnects.