Feature tour

Features

What the application does, grouped by the way you use it.

The list below groups the implemented capabilities by workflow; each item maps to an actual entry point in the application.

Connection and terminal

  • Multi-tab SSH terminal: rendered with xterm.js, supporting password and SSH-key authentication, an xterm-256color PTY and window-size synchronisation.
  • Connection health: configurable SSH keepalive (interval plus retry count); the tab status dot goes from green to yellow (connection-suspect) and then red (connection-closed); a “Reconnect” button reuses the same tab instance, and a monotonically increasing session_id prevents stale background tasks from polluting state.
  • Telnet: plain TCP with a built-in IAC negotiation state machine (ECHO / SGA / TERMINAL-TYPE / NAWS); optional auto-login, off by default (plain-text protocol).
  • Serial (COM): enumerates ports and shows USB device friendly names with VID:PID; configurable baud rate, data bits, stop bits, parity and flow control; includes baud-rate auto-detection (trying each rate in turn and ranking them by “how much it looks like terminal text”).
  • Local terminal: opens the local shell as a top-level tab or a split pane, side by side with remote tabs.
  • SSH tunnels: local port-forwarding rules saved per connection, which can be added, edited, deleted, started and stopped from the sidebar; the backend syncs state through the tunnel-changed event.
  • Network scan: scans a subnet for hosts with open SSH/Telnet ports and can create connections directly from the results.

Files and editing

  • SFTP file management: remote file tree, listing directories / read / write / rename / delete / create directory, upload and download; supports pause and resume, with transfer-progress events.
  • Transfer queue: one row per file showing completed/total size and live speed; directories and drag-and-drop uploads are walked once on the Rust side with walkdir, with progress reported in 4 MiB chunks (single-file uploads use 64 KB chunks); cancelling an upload cleans up the partial remote files it created, completed files are kept, and target files that already existed are not deleted.
  • Remote editor: embedded Monaco editing, presented in a split pane or a floating window; UTF-8 / GBK encoding auto-detection (encoding_rs).
  • Hex and image viewing: binary files are viewed as a hex dump, and images are previewed inline by MIME type.
  • Network file tools: a built-in FTP server (PASV/EPSV), an HTTP/HTTPS file server (one-click generation of a self-signed certificate), a TFTP server, plus an FTP client (no TLS / explicit / implicit) and a TFTP client.

Operations panels

  • Docker and host analysis: one command surface supports two kinds of host (DockerHostRef) — containers on an SSH session jump host (running docker exec over the exec channel), or the local daemon (spawning the CLI directly to avoid quoting issues); probe_local_docker tries docker and then podman, and distinguishes “not installed” from “installed but the daemon is not running”. Features include a container list with create/delete/start/stop, one-shot and streaming logs, a three-layer analysis report, container file browsing and entering a container shell; there is also analyze_host, a read-only analysis of the server's OS/kernel/architecture/packages/installed tools, and command_help for looking up command help.
  • Kubernetes and Helm: K8s mode follows the currently focused terminal to choose the host (an SSH jump host or the local kubeconfig); context/namespace selectors plus a search box, defaulting to All namespaces, with namespace labels stably colored by name. Ten resource kinds (pods/deployments/statefulsets/daemonsets/services/ingresses/jobs/cronjobs/configmaps/secrets) share one row model; each row supports viewing/editing and applying YAML, scaling, deleting (with an in-app confirmation), viewing/streaming logs (with ANSI colors), entering a Pod shell, browsing Pod files and port forwarding (rules can be saved); the Helm tab supports CLI detection, listing releases, viewing values and revision history, rollback, uninstall, and install/upgrade.
  • Git panel: manages one repository at a time, with the host likewise following the focused terminal; everything calls the real git CLI (remote via the exec channel with env LC_ALL=C GIT_TERMINAL_PROMPT=0 … bash -lc, local spawned directly with HideConsole). It covers status (porcelain v2), line-by-line diff (2 MB cap), paginated history with commit-graph lanes, branch and remote management, stage/unstage/discard, commit/amend, fetch/pull/push (pull forces --ff-only, and force push only offers --force-with-lease and requires a second confirmation), a three-way conflict view with operation abort, stash, blame, clone (with progress), repository scanning, git init, and a “local ignore” that writes only to .git/info/exclude. Path arguments are never shell-concatenated; the backend rejects absolute paths, drive letters, backslashes and ...
  • Session recording: off by default; it can be enabled in settings or forced with the WROLP_RECORDING=1/0 environment variable. Events are written per session to <data dir>/recordings/<workspace>/<group>/<connection>/<timestamp>_<session8>.jsonl (NDJSON), flushed every 5 seconds and on disconnect; SQLite stores only the index (events_file, event_count), so wrolp.db does not grow with recordings. A bottom panel lets you browse recordings, reveal them in the file manager, export to asciinema v2 (.cast), replay and delete, and it supports legacy-data migration and index rebuilding by directory.
  • Command sets: reusable command groups stored in SQLite (bindable to connections).

AI assistant

  • Two modes: Chat (non-streaming ai_chat_sync) and Agent (streaming plus tool calling via run_agent_stream); Agent can call tools on connected servers.
  • Isolated dual chat: the AI in the inspector sidebar is an application-level conversation (it belongs to no terminal, and the backend refuses all of its shell tools); terminal-bound AI docks inside each pane and can run run_command, read files and “send to terminal”.
  • Multimodal input: messages can carry images (the backend receives them as openai_content multi-part structures), images can also be pasted, and clicking a thumbnail opens the full image.
  • Send to terminal: AI code blocks or selected text are injected into the target pane according to connection type (SSH/local shell/serial/Telnet); it only inserts and never executes, so you can review before running.
  • Templates and resend: a template dropdown inserts prompts; any historical message can be edited and resent; cancel_ai_chat aborts in-flight generation.
  • Multiple endpoints: several AiEndpointProfiles can be saved (each with its own encrypted API key, URL, model and system prompt), and model lists can be fetched from {endpoint}/v1/models.
  • Security: API keys are encrypted with an AES-256-GCM file vault (vault.key is a machine-bound file); the OS keychain is not used.

Interaction and data

  • Split trees and floating panes: the terminal area is a split-tree layout that splits horizontally or vertically, with leaf nodes holding a terminal, Docker logs or the editor; any pane can pop out into its own floating window, and each session's open files and logs are isolated from the others.
  • Relocatable data directory: settings can point the data directory at any location, migrating wrolp.db, recordings/, connections.json and the window configuration together; the choice is recorded in data_root.json at the default location and takes effect on the next start; an empty target is copied into, a non-empty one is reused, and existing data is never overwritten. vault.key can optionally be migrated too, making the whole directory portable.
  • Database maintenance: shows the current size of wrolp.db and the space that can be reclaimed, with a “Compact now” (VACUUM) action.
  • Keybindings: all shortcuts live in a single table in src/lib/keybindings.ts; settings allow rebinding each entry, resetting a single one, or resetting everything; reserved keys (Tab, Enter, Ctrl+C/V/X/Z/D/W) are refused.
  • Other: custom title bar, persisted window geometry and opacity, single-instance protection, an auto-updater (checks latest.json on GitHub Releases, verifies installers with pubkey, installs in passive mode), and a Chinese/English UI (following the system language by default).

Tech stack

Frontend: React 19 + TypeScript + xterm.js 5.5 (fit/serialize/webgl addons) + Monaco Editor + Vite 6 + SCSS. Dependencies are deliberately few; runtime dependencies are essentially only the Tauri API, xterm, Monaco, react-markdown/remark-gfm, uuid and similar.

Backend: Tauri 2 + Rust (tokio). Key crates:

  • russh 0.64 + russh-sftp 3 (pure-Rust async SSH / SFTP)
  • rusqlite 0.31 (bundled SQLite, WAL mode)
  • portable-pty, serialport (local PTY and serial ports)
  • aes-gcm, rand, base64 (key vault)
  • axum + tower-http + axum-server + rcgen (built-in HTTP/HTTPS file server and self-signed certificates)
  • suppaftp (FTP), reqwest (AI endpoint calls), encoding_rs, walkdir, chrono
  • Windows-specific: windows / windows-core / webview2-com

IPC and storage: Tauri invoke commands are the primary mechanism, and terminal output is polled from the frontend (a workaround for Windows background-task limits). Tauri events are used only for pushes the UI cannot poll — connection-closed, connection-suspect, connection-ok, transfer-progress, tunnel-changed, ai-term-mark, native-drag-drop, baud-detect-progress. All data lives in one relocatable directory: window.json (window, recording and keepalive settings), the encrypted connections.json (connections and workspaces), wrolp.db (session index, command sets, snippets), and recordings/ (NDJSON recordings).