claude-code - 💡(How to fix) Fix claude agents: in-session copy uses broken OSC 52 path while overview correctly uses tmux buffer

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

claude agents uses two different copy mechanisms within the same TUI, in the same tmux session:

  • Overview screen (session list): on mouse-select, prints copied <N> chars to tmux buffer - paste with prefix ] — uses tmux's native copy-pipe path. Works.
  • Inside a session: on mouse-select, prints sent <N> characters via OSC 52 - check terminal clipboard settings if paste fails — emits OSC 52 directly. Bytes never land in the Windows clipboard.

The in-session path is using OSC 52 even though the overview correctly detected tmux is in front of it and used the buffer path. Whatever environment detection happens on session entry gets it wrong.

Root Cause

claude agents uses two different copy mechanisms within the same TUI, in the same tmux session:

  • Overview screen (session list): on mouse-select, prints copied <N> chars to tmux buffer - paste with prefix ] — uses tmux's native copy-pipe path. Works.
  • Inside a session: on mouse-select, prints sent <N> characters via OSC 52 - check terminal clipboard settings if paste fails — emits OSC 52 directly. Bytes never land in the Windows clipboard.

The in-session path is using OSC 52 even though the overview correctly detected tmux is in front of it and used the buffer path. Whatever environment detection happens on session entry gets it wrong.

Fix Action

Fix / Workaround

Workarounds

RAW_BUFFERClick to expand / collapse

Summary

claude agents uses two different copy mechanisms within the same TUI, in the same tmux session:

  • Overview screen (session list): on mouse-select, prints copied <N> chars to tmux buffer - paste with prefix ] — uses tmux's native copy-pipe path. Works.
  • Inside a session: on mouse-select, prints sent <N> characters via OSC 52 - check terminal clipboard settings if paste fails — emits OSC 52 directly. Bytes never land in the Windows clipboard.

The in-session path is using OSC 52 even though the overview correctly detected tmux is in front of it and used the buffer path. Whatever environment detection happens on session entry gets it wrong.

Environment

  • Claude Code 2.1.153 (commit 6cfd211761f3), latest channel
  • Stable: 2.1.145
  • Platform: linux-x64, running inside a Docker container launched via docker compose exec
  • Host: Windows 11, WSL2, Windows Terminal (latest, "Allow OSC 52 to write to clipboard" enabled)
  • tmux 3.3a with set-clipboard on, mouse on (config full enough to render claude agents colors correctly)

Steps to reproduce

  1. From Windows Terminal: docker compose -p <session> exec app tmux new -s <session> claude --allow-dangerously-skip-permissions agents
  2. On the agents overview screen, mouse-select any text → copied N chars to tmux buffer. Pasting via tmux's prefix ] works.
  3. Enter any individual session.
  4. Mouse-select any text → sent N characters via OSC 52. Pasting anywhere on Windows yields nothing — clipboard not updated.

What's confirmed

  • Outer OSC 52 path works: from a sibling bash pane in the same tmux session, printf '\033]52;c;%s\033\\' "$(printf hello | base64)" lands "hello" in the Windows clipboard. So tmux's pass-through and WT's clipboard acceptance are not the problem.
  • Plain claude (no agents subcommand) in a sibling pane: mouse-select → clipboard works (terminal-level selection).
  • Shift+select in the in-session view: works — bypasses Claude's mouse tracking and routes through tmux's selection path.
  • Overview screen copy works consistently. Same Claude binary, same pane, just a different TUI view.

Suspected cause

The in-session view's copy handler bypasses Claude's tmux detection and emits OSC 52 directly, instead of using the same copy-pipe path the overview screen successfully uses. Either:

  • the in-session emit path doesn't check $TMUX / terminfo before choosing OSC 52 vs tmux-buffer, or
  • the OSC 52 bytes it emits are malformed in a way tmux's OSC parser silently drops (the "sent N characters" success message comes from a write that succeeded into the pty but didn't survive tmux's parser).

Workarounds

  • Shift+select inside a session (loses indent-aware full-line copy).
  • Copy from the overview screen and paste from tmux's buffer via prefix ] when applicable.
  • Pin to stable 2.1.145 if the regression is recent.

Fix suggestion

Use the same tmux-buffer copy-pipe path on the in-session view that the overview view already uses. Single source of truth for "we're in tmux, use the buffer."

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING