Single-session/background-job view falls back to unreliable raw OSC 52 clipboard copy instead of tmux-buffer (SSH + tmux)

Description

When SSH'd into a Linux host and running Claude Code inside a real tmux session, text selection/copy behaves inconsistently between the two UI views:

• Fleet / agent-management (list) view: plain click-drag selection + system paste (Cmd+V/Ctrl+V) works correctly. This view apparently does not capture the mouse for its own copy logic, so the terminal handles selection/copy natively.
• Single session / background-job detail view: plain click-drag selection triggers Claude Code's own copy pipeline, which shows:

sent N chars via OSC 52 · if paste fails, hold Shift (Option in iTerm2, Fn in Terminal.app) while selecting for native copy
...but the OSC 52 write does not actually land in the system clipboard. Pasting only works if the user holds Shift while dragging, which bypasses Claude Code's mouse capture entirely and lets the terminal (WezTerm in this case) do native selection/copy instead.

Root cause (traced in installed binary, version 2.1.239)

The clipboard-copy-method selector (minified as HKn() in this build) picks between native / tmux-buffer / osc52:

function HKn(){
  if(!wKn())                       // wKn() = is this an SSH session?
    switch(zt()){                  // zt() = OS platform
      case"macos": case"windows": case"wsl": return"native";
      case"linux": if (local clipboard tool detected) return"native"; break;
    }
  if (process.env.TMUX) return "tmux-buffer";   // reuses tmux's own OSC52 relay (set-clipboard)
  return "osc52";                                // raw OSC 52 write, no tmux relay — the unreliable fallback
}

Over SSH, if TMUX is visible in the process environment, Claude Code uses tmux-buffer (i.e. tmux set-buffer -w ...), which rides on tmux's own native OSC 52 relay (set-clipboard external) — a path we verified is correctly configured and working on this host (tmux 3.4, set-clipboard external, terminfo Ms capability present). If TMUX is not visible, it falls back to writing a raw OSC 52 escape sequence directly to stdout, bypassing tmux's relay — which is the less reliable path, hence the built-in "hold Shift" fallback hint in the UI copy itself.

Inspecting the actual environment of the process rendering the single-session/background-job detail view, TMUX is not present in process.env, even though the session is genuinely running inside a correctly configured, real tmux pane (confirmed: tmux -V → 3.4, ~/.tmux.conf has mouse on, tmux show-options -g set-clipboard → external). This causes the detector to always take the unreliable raw-osc52 branch for this view, instead of the tmux-buffer branch that is otherwise clearly intended for SSH+tmux setups and that the top-level/fleet view's environment does have access to.

Expected behavior

Sessions/views running inside a real tmux pane — including background-job/single-session detail views — should see TMUX in their environment (or otherwise correctly detect that they're inside tmux), so the more reliable tmux-buffer copy path is chosen, matching the experience of the fleet/management view.

Environment

• Claude Code version: 2.1.239 (Linux binary)
• OS: Linux (SSH'd into a remote host)
• Multiplexer: tmux 3.4, set-clipboard external, mouse on
• Local terminal: WezTerm (default bypass_mouse_reporting_modifiers = "SHIFT", which is why holding Shift during selection works around the issue)

Repro steps

1. SSH into a Linux host that has tmux installed.
2. Start a tmux session, then run claude inside it.
3. Open a background job / individual session's detail (chat) view.
4. Click-drag to select some rendered text (no modifier key held).
5. Observe the "sent N chars via OSC 52 ..." status message.
6. Try to paste the selection elsewhere (e.g. into another app, or cat into a terminal) — it does not appear.
7. Repeat step 4 while holding Shift — selection/paste now works, because the terminal (not Claude Code) handles it.

Suggested fix

Ensure TMUX (and/or an equivalent internal "are we inside tmux" signal) is propagated to whatever process/context evaluates the clipboard-copy-method for this view, so it can correctly choose tmux-buffer over the osc52 fallback when actually running inside tmux.