Luvus: pane snapshots, a loopback bridge, and an 18 row agent table

Luvus Web pairs a phone through loopback and leaves the panes running

The browser client is described as optional and read-only by default, for live workspaces, terminals and agent session titles. Devices are paired by link or by QR code, several at once, and each can switch between named sessions. Control is opt-in, so the read-only framing is the default shape rather than a mode you switch on. The transport detail matters more than the feature: the bridge listens on loopback, which means it is not reachable from a phone until you put a TLS tunnel in front of it, and the project says that tunnel has to be one you trust, because that is the whole path from your phone to the machine holding your agent sessions. The second half of the note is the part that tells you what the bridge is not. Stopping it leaves the TUI, the server and the panes running. So the web view is a separate front end onto work that continues without it, not a tunnel you have to keep up for the session to survive. Remote work by SSH is a different mechanism again: machine profiles are saved, one TUI switches between local and remote workspaces, `--remote` attaches directly, and each machine targets a remote named session whose panes stay alive when you switch away. The project states plainly that these SSH connections are separate from Luvus Web pairing, so pairing a phone and connecting to a second machine are two independent trust decisions.

Session snapshots record terminal content unless you turn that off

Workspaces are persistent by design. A background server keeps tabs, panes, layouts, terminal state and named sessions alive, and `luvus` with no arguments launches a session or reattaches to the one already running. That durability is the point, and it comes with a storage question the feature list answers in one clause. Saved pane screens can be disabled when terminal content should not be written to the session snapshot. Read plainly, pane screen contents are part of what a snapshot holds, and there is a setting to keep them out. That is the one place in this documentation where the default behaviour of the persistence layer is called out as something you might want to change, and it deserves to be read as the storage footprint it is: agent sessions routinely contain command output, file contents, tokens pasted in, and error text from tools, and the snapshot is the durable artifact that survives a restart. Nothing else in the persistence list is described that way. Terminal state is named, layouts are named, sessions are named, and none of those three come with a note about what they write. If a snapshot is going to be copied between machines or kept as an artifact after a project ends, that one setting decides how much of your terminal history travels with it.

Eighteen rows of agents, five of which can be forked

The support table has three columns, and the note under it explains which of them is cheap: live status needs no agent integration. Every one of the eighteen rows has a tick there. The rows cover Claude Code, GitHub Copilot CLI, Codex, Arc Studio CLI, Antigravity CLI, Letta Code, opencode, Kimi, Grok, Hermes CLI, Pi, Oh My Pi, Muse Code, Fx, Cursor, Kilo Code and Devin, and the last row folds six more names into one line, Gemini, Aider, Amp, Droid, Qwen and Kiro, all marked the same way. So agent detection is broad by construction. The narrower claim is elsewhere in the same document. Forking is offered for Claude, Grok, Codex, Pi and OMP, sessions forked with their context intact, which is five agents out of more than twenty names in the table. Fork is the expensive operation, because it has to carry conversation state rather than infer status from a process, and the table's middle and right columns show the same shape of inequality for resume and for precise events. Reading the three columns together gives three different tiers of integration, and the tiers do not line up agent by agent. An agent can have full event hooks and no resume, resume with no event hooks, or both. Six of the rows sit in the middle rather than at either end.

Four different answers in one resume column

The middle column of the agent table is not a yes or no column. It carries at least four distinct values, and the distinction between them is the whole integration story. A plain tick covers most of the table, including Claude Code, Codex, opencode, Kimi, Grok, Pi and Oh My Pi. Three agents are marked as resuming with an integration, Letta Code, Hermes CLI and Devin, which is a third answer meaning it works but something extra has to be wired up on the agent side. Cursor is marked with a resume command, and Kilo Code with exact-ID resume, two more values that name a mechanism rather than a guarantee. Two rows say no outright: Arc Studio CLI, and the combined row of Gemini, Aider, Amp, Droid, Qwen and Kiro, which have no resume and no precise events at all. The right-hand column is graded the same way, with a bare no for Arc Studio, Pi, Muse Code, Fx, Cursor and Kilo Code, and a middle value of session only for Antigravity, Letta Code, Hermes CLI and Devin, meaning the events that arrive describe the session rather than the individual step. Nothing in this repository defines what those four values mean operationally, or which integration is required for the three that name one, and the table itself points at the hosted documentation for the complete CLI and API reference. Reading a tick as equivalent to a session-only row is the mistake this column invites.

Both install scripts are excluded from the crate that publishes them

Installation has three documented channels. On macOS, Linux and FreeBSD the script is piped to a shell, with Homebrew as the second path on the same platforms, and Windows gets its own PowerShell line:

# macOS, Linux, and FreeBSD
curl -fsSL https://luvus.dev/install.sh | sh

# Homebrew
brew install RizRiyz/luvus/luvus

# Windows PowerShell
irm https://luvus.dev/install.ps1 | iex

The crate manifest draws a line between what a published package contains and what a git checkout contains, and it puts both of those scripts on the other side. The exclude list drops `/install.sh`, `/install.ps1`, `/assets`, `/docs`, `/web`, `/website`, `/nix`, `/plugins`, `/examples`, `/community`, `/scripts`, `/MODULE-GUIDE.md`, `/CONTRIBUTING.md`, `/SECURITY.md` and `/RELEASING.md` from the package, so someone installing through cargo gets a binary and no installer, no browser client directory and no Nix files. The comment above that list gives the reason, keeping the published crate lean. One entry is called out as an exception in the other direction: `/changelog` is deliberately not excluded, because `build.rs` embeds those notes into the binary for the in-app changelog modal and they have to be present wherever the crate is built. Four entries in that list, `/docs`, `/RELEASING.md`, `/preview.html` and `/preview.ans`, name paths that are not in the checkout listing, so the list is maintained against release tooling rather than against the tree. One more small divergence: the manifest sets its homepage to the GitHub URL while the project site is luvus.dev and the documentation field points at luvus.dev/docs/.

The 1.88 Rust floor belongs to ratatui, and bitflags is pinned exactly

The package declares `edition = "2021"` and, three lines below it, `rust-version = "1.88"`, with a comment explaining why. Ratatui 0.30 and its core crate use Rust edition 2024, so the dependency tree needs rustc 1.88 or newer whatever the package's own edition says. The stated reason for setting the floor honestly is the error message: a lower value makes `cargo install` fail with a cryptic `edition2024` error instead of a clear requirement for a newer compiler. That is a self-imposed constraint to protect someone else's install, and it also means the floor moves when ratatui does. The dependency list makes the same point in miniature. Ratatui, crossterm and portable-pty take caret ranges, crossterm with its serde feature enabled, while bitflags is pinned with an equals sign at `=2.13.0`, the only exact pin in the visible list, so a future bitflags release needs a manifest edit rather than a lockfile refresh. The visible list stops partway through at alacritty_terminal, which is the terminal parser the pane rendering and copy mode work depends on. Cargo.lock and a `vendor/` directory both sit at the root, so the dependency set is committed rather than resolved afresh per machine, which is what makes the exact pin on bitflags a decision instead of a preference.

luvus doctor looks for git, gh and ssh, which is the Git feature list

Three commands cover the whole quick path:

luvus          # launch or reattach to your session
luvus doctor   # check your setup: git, gh, ssh
luvus update   # check for and install a newer release

The diagnostic is a three-item check, and those three items are exactly what the Git and GitHub surfaces consume: status, branches, commits, contributors, pull requests, issues and repository activity in one dock, plus worktree creation and removal, path leases scoped to their project, and the merge step for completed work. A machine with git but no `gh` gets the local half of that dock and not the pull request half, and the check is the only place the requirement is stated outside the feature list. Update is separate and says so: `luvus update` checks for and installs a newer release, and the migration path from previous releases is a documented step of its own rather than something that happens automatically. Two platform caveats sit alongside. FreeBSD is supported on amd64 only, while Windows goes through the PowerShell installer rather than the shell one, so the two script channels are not interchangeable. On macOS there is a keyboard conflict to resolve first: the prefix is bound to `Ctrl+Space`, which macOS also uses for input source switching, and the fix is to turn off *Select the previous input source* under System Settings, Keyboard, Keyboard Shortcuts, Input Sources. The prefix itself is remappable along with keys, presets and a help view that shows the effective shortcuts, and the interface can be switched between eight languages.

Editorial conclusion

Judge this by its seams rather than by the length of the feature list. The pane, session and worktree machinery is the substance, and the agent layer sits on top of it in tiers that the support table makes plain: live status everywhere, real resume for some agents, fork for five. Anyone running agents on more than one machine should read the Luvus Web section before pairing a phone, because the bridge listens on loopback, needs a tunnel you trust to reach it from elsewhere, and does not stop your panes when it goes away, which means the remote view is separable from the session rather than a window onto it. Before trusting it, turn off saved pane screens if terminal content should not land in a snapshot, run luvus doctor to confirm git, gh and ssh are where the binary expects them, and check your rustc against the 1.88 floor that the manifest inherits from its terminal UI dependency.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. RizRiyz/luvus on GitHub