先日、リモートサーバのtmux セッションでコピーしたテキストが、Mac側のクリップボードに反映されない問題に遭遇しました。
tmux側の設定は正しいはずなのに、なぜかコピーが効かない。
結論から言うと、原因は mosh でした。
本記事では、mosh経由でOSC 52クリップボード連携が不安定になる理由と、実際に検証した結果、そして実用的な対策をまとめます。
環境
- クライアント: macOS
- 端末: Alacritty 0.16.1
- サーバ: Linux （tmuxあり）
- tmux: 3.4
- mosh: client/server ともに 1.4.0
症状
tmux側はOSC 52連携想定の設定が入っていたが、mosh経由だと以下の状態になりました。
- tmux内のコピーバッファには入る
- しかしMac側クリップボードへ反映されない
OSC 52とは？
OSC 52 は、端末エミュレータとアプリケーション間でクリップボードを共有するためのエスケープシーケンスです。
リモートサーバ上のtmuxやvimから、ローカルマシンのクリップボードへ直接コピーできる仕組みで、SSH経由でも動作します。
検証: mosh経由でのOSC 52テスト
mosh経由でtmux内から、以下のOSC 52テストを実行しました。
✅ 通る（Mac側クリップボードに入る）
A. ペイロード直書き + BEL終端（最小）
| |
HelloがMac側のクリップボードに入る。
❌ 通らない（Mac側クリップボードに入らない）
B. base64をコマンド置換で作って送る（元々のテスト）
| |
- 私の環境では入らなかった。
改善版（推奨）
base64の末尾改行（および環境によっては折返し）が混ざると壊れやすいので、改行を除去して送ります。
| |
推定原因
mosh 1.4.0 でOSC 52対応は追加されています（リリースノート にも明記）。
ただし、私の環境では「受理できるOSC 52の形式」がかなりシビアに見えました。以下のような条件が絡むと、mosh側がOSC 52として扱わず（もしくは途中で破棄）、クライアント端末へ転送されない可能性があります。
- base64の出力に改行が混ざる
- base64が折返しする（環境差）
- 終端がBEL (
\a) 以外 - オプション/形式の差
特に $(... | base64) の形は、多くの環境で末尾に改行が含まれるため、OSC 52のペイロードとして壊れるパターンがあります。
対策案
案1: moshを捨てる（推奨）
SSH + tmux に寄せる。
- クリップボード（OSC 52）が素直に通りやすい。
- 切れてもtmuxが生きていれば復帰が楽。
SSH側は ControlMaster と keepalive を入れると体感が良くなります。
~/.ssh/config 設定例:
Host myserver
HostName example.com
ControlMaster auto
ControlPath ~/.ssh/sockets/%r@%h-%p
ControlPersist 10m
ServerAliveInterval 60
ServerAliveCountMax 3
案2: mosh継続 + “通る形式” に寄せる（妥協案）
- tmuxの
set-clipboard onに任せず、tmuxバッファを自前で\033]52;c;<base64>\a（BEL終端）形式で吐く。 - base64は必ず改行除去 (
tr -d '\n') を入れる。 - tmux側のクリップボード設定は公式Wiki（tmux Wiki: Clipboard ）を一度確認しておく。
ただし、moshはUDP 1パケット相当のサイズ制限で長文が切れる可能性があります（実装/議論上の既知制限）。
現時点の結論
- 「mosh経由でもOSC 52は一応通る」が、形式依存で壊れやすく運用が不安定。
- クリップボード重視のワークフローでは、moshを捨ててSSHを強化するのが最短。
まとめ
moshは不安定なネットワーク環境で威力を発揮しますが、OSC 52クリップボード連携に関しては「形式依存で壊れやすい」という弱点があります。
個人的には、クリップボード連携を重視するなら、moshを諦めてSSH + tmuxの組み合わせに寄せる方が安定すると思います。
同じ問題でハマっている方の参考になれば幸いです。