tmux OSC 52 clipboard silently fails after reattaching session to terminal without Ms capability
0 reputation · 30 Jul 2023, 08:07 UTC
0 reputation · 30 Jul 2023, 08:07 UTC
Maintain consistent system-clipboard access via OSC 52 when a tmux session is reattached to different terminal emulators, some of which declare the Ms terminfo capability and others that do not.
tmux 3.2–3.4 uses the static Ms entry in the attached terminal’s terminfo to decide whether to forward OSC 52 sequences when set-clipboard external is set. No runtime negotiation or capability probe occurs at attach time. If a session created under a terminal that advertises Ms (e.g., Kitty, WezTerm, iTerm2) is reattached to a terminal lacking the capability (e.g., a minimal xterm or a distribution terminfo missing the entry), tmux silently drops the escape sequences. The user receives no warning, fallback, or error message, and key bindings that invoke copy-pipe or rely on the built-in clipboard integration appear to work but leave the system clipboard unchanged.
Terminfo databases shipped with common distributions may omit Ms even for terminals that support OSC 52, producing false negatives. Nested tmux sessions add a further requirement: both inner and outer tmux must have allow-passthrough on (default since 3.3) and the outer terminal must honor the passthrough.
copy-pipe to xclip/wl-copy) without user intervention?set-clipboard external is active but the attached terminal lacks Ms?33775 reputation · 30 Jul 2023, 13:59 UTC
There is currently no native tmux mechanism to detect terminal capabilities at runtime during a client attach event, nor is there a built-in hook to trigger warnings when the Ms terminfo capability is missing. Because tmux 3.2–3.4 evaluates the Ms capability statically based on the TERM variable of the attaching client, the failure is silent by design.
When set-clipboard external is active, tmux checks the terminfo database for the Ms (set clipboard) capability. If you attach from a terminal where the TERM environment variable points to a definition lacking Ms, tmux assumes the terminal cannot handle OSC 52 and drops the sequence to avoid printing garbage characters to the screen. Since this check happens at the client-attach level and not as a continuous negotiation, the session remains unaware that the clipboard is effectively disabled until a manual check is performed.
Since tmux lacks a runtime callback for this, you must implement a wrapper or a manual verification step to handle fallbacks.
To determine if your current terminal environment is the cause of the failure, run the following command on the host machine:
infocmp | grep Ms
If this returns no output, the terminfo for your current TERM does not advertise OSC 52 support, and tmux will block the sequences.
To confirm the terminal emulator itself supports OSC 52 regardless of the terminfo database, send the sequence directly:
printf "\e]52;c;$(printf "test-clipboard" | base64)\a"
If the text "test-clipboard" appears in your system clipboard, the issue is strictly the Ms terminfo entry.
Because you cannot detect this automatically within tmux, the most reliable approach is to use a shell script for clipboard operations that checks for a known "safe" terminal or environment variable before deciding between OSC 52 and a local tool (like xclip or wl-copy).
If you are using nested tmux sessions, ensure the following is set in both the inner and outer sessions (available in tmux 3.3+):
set -g allow-passthrough on
To provide a more specific fallback script, please specify if you are using a consistent TERM variable across all clients or if the TERM changes based on the emulator used (e.g., xterm-256color vs kitty).
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.