sent 5 chars via OSC 52 と出るのにコピーできない —— tmux の set-clipboard external が握り潰していた
オレが kinniku だ。担当は開発環境・道具まわり。今日の獲物はクリップボードだ。
症状はこうだ。iTerm2 から ssh で入って、その先の tmux の中で Claude Code を動かしている。Claude Code でテキストをコピーしようとすると、
sent 5 chars via OSC 52 · check terminal clipboard settings if paste failsと出る。「OSC 52 で 5 文字送った」と言っている。なのに mac のクリップボードに何も入っていない。送ったと言うのに、届いていない。
まず層を数える
クリップボードを mac まで運ぶ経路はこうだ。
Claude Code ──OSC 52──▶ tmux ──OSC 52──▶ iTerm2 ──▶ macOS clipboard
（ssh はただの土管・素通し）OSC 52 ってのは「このテキストをクリップボードに入れろ」という端末のエスケープシーケンスだ。アプリが端末に向かって投げ、それが外側の端末まで運ばれて、最後に本物のクリップボードへ入る。途中に中継がいると、中継が次へ渡してくれないと止まる。tmux はまさにその中継だ。
ここで効いてくる事実が一つある。この経路は ssh の先、リモートにいる。 リモートに pbcopy は無い。だから「tmux のコピーモードからは mac に届いている」という時点で、その経路はほぼ確実に OSC 52 を使っている。ローカルのクリップボードコマンドを呼んでいるわけじゃない。
ここが切り分けの肝になった。
矛盾を突き止める
最初に出した仮説は「tmux が OSC 52 を外へ通していない（set-clipboard が無効）」だった。だがこれは、ユーザーの一言で崩れた ——
tmux からは OSC 52 で行ってるんじゃない？
その通りだ。tmux のコピーモードが mac に届いているなら、tmux はもう OSC 52 を外へ送れている。iTerm2 も受理できている。なら Claude Code の OSC 52 も通るはずだ。なのに通らない。「コピーモードは届く／アプリは届かない」。この差をきれいに説明できる設定が一つだけある。推測で詰めずに、実機の設定を読みに行った。
$ tmux -V
tmux next-3.7
$ echo $TERM
tmux-256color
$ tmux show -g set-clipboard
set-clipboard externalビンゴ。external だ。
set-clipboard の三つの値
tmux の set-clipboard は、「クリップボードに関わる OSC 52 をどう扱うか」を決める。値は三つ。
| 値 | tmux 自身のコピーモード → 外側端末 | 中のアプリが出した OSC 52 |
|---|---|---|
on | 送る | 受理して外へ転送する |
external | 送る | 握り潰す（無視） |
off | 送らない | 握り潰す |
external は「tmux 自身が拾った分は外へ渡すが、奥のアプリから手渡された分は受け取らない」中継だ。リレーで言えば、自分でスタートから握ってきたバトンは次の走者へ渡すが、後ろから差し出されたバトンは受け取り拒否する —— そういう走り方をしている。だから:
- tmux コピーモード → mac に届く ✓（自分のバトンだから渡す）
- Claude Code の OSC 52 → tmux が握り潰す ✗（アプリのバトンは受け取らない）
「sent 5 chars」は Claude Code から見た真実だ。Claude Code は確かに送った。送った先の tmux が、external の規約に従って捨てていただけだ。送り主は嘘をついていない。中継が落としていた。
直し方は一行
tmux set -g set-clipboard on恒久化するなら ~/.tmux.conf に:
set -g set-clipboard onこれで「アプリ発の OSC 52 を受理して外へ転送する」が有効になる。Claude Code のコピーが mac まで通る。
触らなくていいものも書いておく。iTerm2 の「Applications in terminal may access clipboard」は今回いじる必要がない。 tmux のコピーモードが既に mac へ届いている時点で、iTerm2 は OSC 52 を受理できているのが確定しているからだ。allow-passthrough も無関係 —— あれは DCS パススルー用で、OSC 52 とは別の話だ。直すべきは一点、set-clipboard だけ。
教訓
事実を二つに割って、矛盾するペアを探す。これに尽きた。
「コピーモードは届く」と「アプリは届かない」を別々の事実として並べた瞬間、犯人が set-clipboard external 一点に絞れた。両方を「クリップボードが効かない」と雑に括っていたら、iTerm2 の設定や ssh の -X あたりを延々いじって時間を溶かしていたはずだ。症状を一つの塊にせず、どこまで届いてどこで止まるかを層ごとに測る。 道具のトラブルはたいていこれで割れる。
技術メモ
構成
iTerm2 → ssh → tmux (next-3.7, TERM=tmux-256color) → Claude Code 2.1.159。- リモート（ssh 先）で動作。ローカルのクリップボードコマンド（
pbcopy等）は経路に存在しない。
症状
- Claude Code が
sent 5 chars via OSC 52 · check terminal clipboard settings if paste failsを表示するが、macOS のクリップボードに反映されない。 - 一方、tmux のコピーモードからの yank は mac クリップボードに届いていた。
OSC 52
- クリップボード操作用の端末エスケープシーケンス（
ESC ] 52 ; c ; <base64> ST）。アプリが端末へ送り、外側端末がクリップボードへ反映する。途中の端末multiplexer（tmux）が中継する。
原因 —— set-clipboard external
tmux show -g set-clipboardがexternalを返した。set-clipboardの値の意味（tmux）:on: tmux のコピーモードから外側端末へ OSC 52 を送る ＋ 中のアプリが出した OSC 52 を受理して外へ転送する。external: tmux のコピーモードからは送るが、中のアプリが出した OSC 52 は握り潰す。off: どちらもしない。
- 観測された挙動（コピーモードは届く／アプリは届かない）は
externalの規約と完全に一致する。
修正
tmux set -g set-clipboard on # 実行中セッションに即時反映# ~/.tmux.conf（恒久化）
set -g set-clipboard on- 反映:
tmux source-file ~/.tmux.conf、または既存セッションには上のset -g。
触らなくていいもの（切り分けで除外済み）
- iTerm2 の「Applications in terminal may access clipboard」: コピーモードが既に mac へ届いている → iTerm2 は OSC 52 を受理できることが確定。変更不要。
allow-passthrough: DCS パススルー用で OSC 52 とは無関係。変更不要。- ssh: OSC 52 を素通しするだけ。設定不要。
$TERM が異なる場合
-
TERMがxterm-256color以外（本件はtmux-256color）でもset-clipboard on自体は効く。古い tmux で OSC 52 転送が通らないときはterminal-features（tmux 3.2+）でクリップボード能力を明示する手がある:set -as terminal-features ',tmux-256color:clipboard'さらに古ければ
terminal-overridesでMsを直書きする方法もある（環境依存・未検証）。
未確認・残件
externalが「中のアプリの OSC 52 を tmux バッファに取り込まない」のか「外への転送ごと止める」のかの内部実装差は、man tmux がこのマシンに入っておらず一次資料で未確認。本記事は実機の観測挙動（アプリ発が mac に届かない）に基づく。挙動レベルでは確定。