tmuxは必須ではないかもしれない：開発ワークフローでtmuxを置き換える方法

(bower.sh)

17 ポイント投稿者 GN⁺ 2025-08-04 | まだコメントはありません。 | WhatsAppで共有

tmuxを長年使ってきたが、最近は tmux の複雑さと限界（カラー互換性、スクロールバック、マウスでのコピー、プロトコル未対応など）に疑問を感じるようになった
セッション永続性（detach/attach）や ウィンドウの分割・管理 など、tmux の主要機能は必ずしも tmux でしか実現できるわけではない
dtach, abduco, shpool のような Unix 哲学に沿った軽量ツールを活用すれば、セッション管理に集中しつつ ネイティブのスクロールバック と シンプルさ を確保できる
特に shpool + ssh の組み合わせにより、複数のリモートセッションをウィンドウマネージャで直接管理し、ネイティブ機能（通知、スクロール、タイトルなど）をそのまま使える環境を構築できる
完璧ではないが、筆者にとっては tmux を完全に置き換えられ、シンプルで保守しやすいワークフローに満足している

tmuxの長所と短所

セッション維持（detach/attach）、ウィンドウ管理（タブ、split）など、これまで tmux が提供してきた機能がワークフローの中核だった
しかし、適切な TERM 設定がない場合の色表示の問題や、ターミナルと tmux 間の相互作用を考慮する必要があるなど、複雑さが増していた
スクロールバッファの利用も tmux 独自の方式に慣れる必要があり、マウスを使った範囲コピーも split 環境では不便だった
kitty graphics protocol など 新しいターミナル機能 への対応が不十分で、実験的プロトコルをサポートしない問題もある
重複した escape code の再解釈や、セッション/ウィンドウという概念を追加することで、マルチプレクサが ターミナルエコシステムの発展を妨げる という批判もある

セッション永続性:
- 単純な方法として ctrl-z + fg, nohup, disown などもあるが、完全な代替にはなりにくい
- セッション維持だけ を目的とした複数のツール（dtach, abduco, shpool）が登場している
  - fork() と UNIX ソケットの組み合わせにより、daemon と client の間を接続する
  - tmux と違って仮想 split を持たないため、ネイティブのスクロールバック をサポートし、バッファ復元機能を備えるものもある
- 実際の使用感では、代替ツールの多くはバグがあり、nvim 内で detach のキー組み合わせが動かないなど、完成度 は低かった
- shpool だけが detach/attach コマンドとキーマップのカスタマイズの面で最も完成度が高かった
ウィンドウ管理:
- ローカルではウィンドウマネージャで分割・配置を管理する
- リモート（SSH）環境でも ssh_config と shpool を組み合わせることで、複数セッションを別々のウィンドウで独立して維持できる
- autossh と組み合わせれば、ネットワーク再接続時でもセッションを維持できる

筆者は個人的に ghostty（ノートPC）、sway+foot（個人用PC）でウィンドウを管理している。サーバーは Proxmox ベースのヘッドレス VM で、常時 SSH 開発環境を維持している
複数の shpool セッションに ssh のショートカットで自動接続し、ローカルのウィンドウマネージャで独立して制御する
- ssh_config で各ホストごとに shpool セッションへの attach を自動化
- ターミナルごとに IRC、dotfiles 管理、別個の neovim 環境など、複数セッションへ個別接続 が可能
ネイティブスクロール、通知、ターミナルタイトルなど、tmux では不安定にしか対応できなかった機能が、むしろより自然に動作する
欠点もある: vim 再接続時のターミナル状態の復元に遅延があり、nvim 使用時にはリサイズの問題もある
- マルチプレイヤー非対応（複数クライアントで autossh が同時発生するとセッション衝突が起きる）
それでも筆者基準では tmux の完全代替に成功 した