[BUG] /copy in `claude agents` (FleetView) silently fails — toast shows success but OS clipboard is not updated (tmux + VS Code Remote SSH)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.150)

What's Wrong?

The /copy command behaves inconsistently between a regular claude session and a claude agents (FleetView) session running under the same shell:

• Regular claude session: /copy works as expected. The toast says "Copied to clipboard (N characters, M lines)" and the content can be pasted in the host with Cmd/Ctrl+V.
• claude agents session (attached to a background agent): /copy reports the same success toast — "Copied to clipboard (1905 characters, 25 lines) / Also written to /tmp/claude-1000/response.md" — but the OS clipboard is not actually updated. Pasting in VS Code yields whatever was previously on the clipboard.

The fallback file at /tmp/claude-1000/response.md is written correctly, so the copy code path runs, but the clipboard write step silently no-ops.

The toast does not indicate which paste path to use (Cmd/Ctrl+V vs tmux prefix+]), unlike the behavior introduced for regular sessions in v2.1.77 (referenced in #35135).

This appears related to (but distinct from):

• #60755 — observation that the agents view has its own input-handler / copy logic separate from the main interactive session.
• #54164 — confirms the documented copy path for tmux (tmux paste buffer) vs SSH (OSC 52). The toast wording in the failing case ("Copied to clipboard", not "Copied to tmux buffer") suggests the agents-view path is not taking the tmux-aware branch.
• #52139 — Ink renderer issues specifically in FleetView/spawned-agent sessions under tmux.

What Should Happen?

/copy in a claude agents session should produce the same clipboard outcome as /copy in a regular claude session under the same terminal/tmux/SSH stack:

• The content should reach the OS clipboard so Cmd/Ctrl+V works in the host editor.
• If the path used differs (e.g. tmux paste buffer vs OSC 52), the toast should accurately tell the user which paste method to use, matching the v2.1.77 fix tracked by #35135.

Steps to Reproduce

Setup (Linux container reached over VS Code Remote SSH, running inside tmux):

1. ~/.tmux.conf:

``tmux
set-option -g default-terminal "screen-256color"
set -as terminal-features ',screen-256color:clipboard'
set -g allow-passthrough on
# set-clipboard left at default ('external')
`
Reload with tmux source-file ~/.tmux.conf`.

1. Verify the OSC 52 transit through tmux → VS Code is healthy:

``bash
printf '\033]52;c;%s\007' "$(printf 'hello' | base64)"
`
Pasting in VS Code yields hello`. ✅ baseline confirmed.

1. Verify /copy in a regular session works:

``
$ claude
> (any prompt)
> /copy
`
Toast: Copied to clipboard (...). Paste in VS Code with Ctrl+V` → content arrives. ✅

1. Reproduce the bug in claude agents:

``
$ claude agents
`
Attach to (or dispatch and attach to) a background agent. Run /copy on any response.
Toast: Copied to clipboard (1905 characters, 25 lines) / Also written to /tmp/claude-1000/response.md.
Paste in VS Code with Ctrl+V` → nothing changes (previous clipboard contents remain). ❌

/tmp/claude-1000/response.md is correctly populated, confirming the copy code path executed but the actual clipboard write step did not reach the OS.

Error Messages / Logs

No errors. The toast claims success:

Copied to clipboard (1905 characters, 25 lines)
Also written to /tmp/claude-1000/response.md

Environment

• Claude Code Version: 2.1.150 (Claude Code)
• Platform: Anthropic API
• OS: Linux 6.17.0 (devcontainer / Linux Other)
• Terminal: VS Code integrated terminal (VS Code Remote SSH to Linux host)
• tmux: 3.3a, TERM=screen-256color, set-clipboard external, allow-passthrough on, screen-256color:clipboard advertised
• Clipboard CLIs: xclip / xsel / wl-copy / pbcopy are not installed on the remote host — so the only viable clipboard path is OSC 52 (which is confirmed working for raw escape sequences and for regular claude /copy).

Regression

I don't know. I have not tested earlier versions.

Additional Information

The combination of (a) the toast text matching the non-tmux branch ("Copied to clipboard" rather than the tmux-buffer wording from #35135), (b) the regular claude /copy working in the exact same shell/tmux/terminal stack, and (c) no clipboard CLI being available, suggests the agents-view /copy path either:

1. Bypasses the tmux-aware branch that the regular session uses (so it never writes to the tmux paste buffer), or
2. Attempts an OS-clipboard write through a backend (e.g. xclip/pbcopy) that fails silently when no such binary exists, instead of falling through to OSC 52.

Either way the result is a silent no-op with a misleading success toast.