gilvt需要 detach/attach、远程持久化和共享会话时选择 tmux。需要原生 macOS UI、Claude Code/Codex 状态、系统通知和逐轮 review 时选择 gilvt。远程持久化与本地 Agent 管理同样重要时，两者组合使用。
本质区别是进程由谁持有
gilvt 为每个 pane 直接持有 PTY，并由自己的终端模拟器渲染。标签页和分屏是原生应用布局。应用退出后，这些 PTY client 也会消失；gilvt 可以重建工作现场并恢复支持的 Agent session，但不会保存任意进程内存。
Gilvt.app → PTY → shell / claude / codex
tmux 在外层终端和真实 shell 之间加入 server。server 持有 PTY，因此关闭终端窗口只会断开 client。
gilvt / Terminal.app → tmux client ⇄ tmux server → PTY → 进程
能力对比
| 能力 | gilvt | tmux |
|---|---|---|
| 原生 macOS 应用 | 是 | 否，运行在终端内部 |
| 终端渲染 | 自己的 GPU 终端模拟器 | 通过外层终端渲染 |
| 重新连接同一个进程 | 不支持 | 核心能力 |
| 远程 SSH 持久化 | 依赖 SSH 连接 | 非常适合 |
| 多个 client 连接同一会话 | 不支持 | 支持 |
| Claude Code / Codex 状态 | 内置 | 依赖脚本或插件 |
| 逐轮命令、文件与 diff | 内置 | 不是核心概念 |
| Quick Look、Markdown、编辑器 | 原生视图 | 依赖外部工具 |
| 自动化生态 | 早期阶段 | 成熟 CLI、hooks 和插件 |
恢复工作现场不等于保留运行进程
gilvt 保存应用工作现场：窗口、标签页、分屏、目录和持久 Agent 标识。再次启动时重建布局，并让受支持的 Agent session 等待恢复。Python REPL 内存和正在运行的 dev server 不会被 checkpoint。
只要 tmux server 仍存活，attach 就会回到同一个 shell、编辑器和进程。机器重启后，普通 tmux 进程同样消失；插件可以重建布局，但无法恢复任意内存状态。
为什么 gilvt 更理解 Agent
tmux 主要建模 session、window 和 pane。gilvt 还建模 Agent 会话、轮次、审批、问题、工具调用、产物和可恢复历史，因此能提供注意力队列与 review 流程，而不只是 pane 网格。
当多个 Agent 在本地运行，而瓶颈是决定下一步该看哪里时，这层语义尤其有价值。
什么时候在 gilvt 中使用 tmux
远程开发是典型组合：
macOS 上的 gilvt → SSH → 服务器上的 tmux → 长期 Agent 或服务
tmux 保持远端进程跨网络断线存活，gilvt 继续作为本地终端和工作台。内层 tmux pane 的精细 Agent 元数据可能更难与外层 pane 对应，具体能力取决于 hooks 和 session id 在哪里运行。
应该选择哪个？
- 进程存活、SSH detach/attach 或多 client 共享是核心需求时，使用 tmux。
- 本地并行运行 Claude Code、Codex，希望获得原生状态、导航、review 与通知时，使用 gilvt。
- 远程持久化和本地 Agent 工作台都重要时，组合使用。
gilvt 并不把自己定位为 tmux 替代品。它替代的是外层终端加独立 Agent 看板的组合，而 tmux 仍然是很强的进程持久化层。