gilvtChoose tmux for detach/attach, remote persistence and shared terminal sessions. Choose gilvt for native macOS UI, Claude Code and Codex status, notifications and per-turn review. Use both when you need remote persistence and local Agent awareness.
The process ownership is the essential difference
gilvt directly owns a PTY for each pane and renders it with its terminal emulator. Tabs and splits are native application layout. When the app exits, those PTY clients are gone; gilvt can rebuild the workspace and resume supported Agent sessions, but it does not preserve arbitrary process memory.
Gilvt.app → PTY → shell / claude / codex
tmux inserts a server between the outer terminal and the real shells. The server owns the PTYs, so closing a terminal window only disconnects the client.
gilvt / Terminal.app → tmux client ⇄ tmux server → PTYs → processes
Capability comparison
| Capability | gilvt | tmux |
|---|---|---|
| Native macOS application | Yes | No; runs inside a terminal |
| Terminal rendering | Own GPU-rendered emulator | Renders through the outer terminal |
| Detach and reconnect to the same process | No | Core feature |
| Remote SSH persistence | Depends on the SSH connection | Excellent |
| Multiple clients on one session | No | Yes |
| Claude Code / Codex state | Built in | Requires scripts or plugins |
| Per-turn commands, files and diff | Built in | Not a core concept |
| Quick Look, Markdown and editor | Native views | External tools |
| Automation ecosystem | Early | Mature CLI, hooks and plugins |
Restore is not the same as persistence
gilvt saves the application workspace: windows, tabs, splits, directories and durable Agent identifiers. On relaunch it reconstructs that layout and offers Agent sessions for resume. A Python REPL's memory or a running development server is not checkpointed.
As long as the tmux server survives, attaching returns to the exact same shell, editor and process. After a machine reboot, ordinary tmux processes are also gone; plugins can rebuild layouts but cannot restore arbitrary in-memory state.
Why gilvt understands more about agents
tmux primarily models sessions, windows and panes. gilvt also models Agent sessions, turns, approvals, questions, tool calls, artifacts and resumable history. That enables an attention queue and review workflow rather than only a pane grid.
This semantic layer is useful when several agents run locally and the bottleneck is deciding where to look next.
When to use tmux inside gilvt
The combination is especially useful for remote development:
gilvt on macOS → SSH → tmux on server → long-running Agent or service
tmux keeps the remote processes alive across network interruptions. gilvt remains the local terminal and workspace. Some fine-grained Agent metadata may be harder to associate with inner tmux panes, so the exact integration depends on where hooks and session identifiers run.
Which should you choose?
- Use tmux when process survival, SSH detach/attach or multi-client sharing is the primary requirement.
- Use gilvt when you run several local Claude Code and Codex sessions and want native status, navigation, review and notifications.
- Use both when remote persistence and a native local Agent workspace are equally important.
gilvt does not position itself as a tmux replacement. It replaces the outer terminal-plus-dashboard workflow, while tmux remains a strong process-persistence layer.