### System details

Omarchy tmux configuration using:

- `tmux 3.6a`
- `mosh 1.4.0`
- An OSC 52-capable local terminal
- Remote shell session running tmux over mosh

### What's wrong?

When connecting to an Omarchy system over `mosh`, tmux mouse copy can appear to work inside tmux but not update the local system clipboard.

Observed behavior:

1. Start a remote session with `mosh`.
2. Attach to tmux using the Omarchy tmux config.
3. Highlight text with the mouse, or use tmux copy mode and copy a selection.
4. tmux creates/updates its paste buffer, but the copied text does not land in the local clipboard.

The same workflow may work over plain SSH, which makes this easy to miss until switching to mosh for an unstable connection.

### Why it happens

Omarchy enables tmux clipboard support with:

```tmux
set -g set-clipboard on
```

That relies on tmux emitting an OSC 52 clipboard sequence through the terminal `Ms` capability. With mosh in the middle, the reliable form is:

```text
OSC 52 ; c ; <base64> BEL
```

A generic/generated tmux `Ms` capability may emit a parameterized form such as:

```text
\033]52;%p1%s;%p2%s\a
```

In practice, mosh 1.4.0 only forwarded the clipboard update reliably when the target was explicitly `c`:

```text
\033]52;c;%p2%s\a
```

There is another wrinkle: existing tmux clients can keep stale terminal features after config reloads, so fixing only `terminal-overrides` may not repair already-attached sessions.

### Verified fix/workaround

A robust workaround is to make tmux copy actions pipe the selected text to a small OSC 52 helper that writes directly to the active tmux client TTY. This avoids relying on tmux's generated `Ms` path and works through mosh.

Helper script:

```sh
#!/bin/sh
tty=$1

if [ -z "$tty" ] || [ ! -w "$tty" ]; then
  exit 0
fi

{
  printf '\033]52;c;'
  base64 | tr -d '\n'
  printf '\007'
} > "$tty"
```

Example tmux bindings:

```tmux
bind -T copy-mode-vi y send -FX copy-pipe-and-cancel "$HOME/.local/bin/tmux-osc52-copy '#{client_tty}'"
bind -T copy-mode-vi MouseDragEnd1Pane send -FX copy-pipe-and-cancel "$HOME/.local/bin/tmux-osc52-copy '#{client_tty}'"
bind -T copy-mode-vi DoubleClick1Pane select-pane \; send -X select-word \; run-shell -d 0.3 \; send -FX copy-pipe-and-cancel "$HOME/.local/bin/tmux-osc52-copy '#{client_tty}'"
bind -T copy-mode-vi TripleClick1Pane select-pane \; send -X select-line \; run-shell -d 0.3 \; send -FX copy-pipe-and-cancel "$HOME/.local/bin/tmux-osc52-copy '#{client_tty}'"
```

The important detail is `send -FX`, so `#{client_tty}` is expanded at copy time.

This direct helper path was verified by sending an OSC 52 sequence through mosh and confirming it reached the local terminal, then wiring tmux copy actions through the helper.

### Suggested Omarchy-side fix

Consider adding an OSC 52 copy helper and routing tmux mouse/copy-mode copy bindings through it, or otherwise making the tmux `Ms` capability mosh-compatible by forcing the explicit `c` target and ensuring attached clients refresh cleanly.

A smaller partial fix is:

```tmux
set -g terminal-features "xterm*:ccolour:cstyle:focus:title,screen*:title,rxvt*:ignorefkeys"
set -g terminal-overrides "linux*:AX@,*:RGB,xterm*:Ms=\\E]52;c;%p2%s\\007"
```

But in testing, the direct helper was more reliable for existing and new mosh sessions because it bypassed stale tmux client terminal features.