[FEATURE] Setting to disable copy-on-selection in the agents view (TUI)

Status Fixed / completed
Maintainer reply ✓ Yes — bcherny
Activity 15 comments · opened May 20, 2026 · closed Aug 17, 2026
💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Summary

Add a setting to disable Claude Code's automatic copy-on-selection behavior in the agents view (the background-agents management UI), so selection only highlights and explicit Cmd+C is required to copy (matching native macOS terminal conventions).

Current behavior

Inside the agents view in the Claude Code TUI, any text selection (drag, double-click word, triple-click line) is automatically copied to the system clipboard, and a "copied X chars to clipboard" toast appears.

This does not happen in a normal interactive Claude Code session — only inside the agents view — so the auto-copy logic appears to live in that view's input handler specifically.

Why this is a problem

Any quick visual selection inside the agents view silently overwrites whatever the user had in their clipboard. This is surprising and easy to miss, especially because:

  • The same behavior does not happen in a normal interactive Claude Code session.
  • The same WezTerm session does not exhibit this behavior at a regular shell prompt or inside other TUI CLIs (e.g. Codex).

Even with WezTerm configured with disable_default_mouse_bindings = true and explicit Nop bindings on mouse-Up events, the auto-copy still happens inside the agents view, confirming it is Claude Code's own copy logic in that view, not the terminal's.

Proposed solution

Add one of:

  • A copyOnSelection boolean in ~/.claude/settings.json (default true to preserve current behavior)
  • An env var like CLAUDE_CODE_NO_COPY_ON_SELECT=1

Setting it to disable would mean selection only highlights inside the agents view, and Cmd+C is required to copy, matching native macOS terminal conventions and the rest of Claude Code.

Workarounds considered

CLAUDE_CODE_DISABLE_MOUSE=1 is too heavy-handed since it disables all mouse interaction, not just the copy-on-select side-effect.

Environment

  • Claude Code (latest)
  • WezTerm 20240203 on macOS
  • Reproduces: agents view inside Claude Code
  • Does NOT reproduce: normal interactive Claude Code session, Codex CLI, shell prompt

View original on GitHub ↗

15 Comments

marc-himmelberger · 4 months ago

I face the same problem on Windows in the VScode terminal when connected to WSL, no special mode needed, just plain claude. I would also appreciate a dedicated NO_COPY_ON_SELECT option, as CLAUDE_CODE_DISABLE_MOUSE also effectively breaks scrolling for me.

pidement · 4 months ago

Yes please, add an option to disable this feature. I frequently use Shift-click to select a range of text, and this change breaks that behavior.

In general, I don’t like features that change the app’s behavior without asking first. This should be opt-in or configurable.

ArthurkaX · 4 months ago

Add an option pls!

ArthurkaX · 4 months ago

Hey everyone! Good news - it turns out this feature is actually already built into Claude Code, it's just a bit hidden.

You can disable it right now by following these steps:

  1. Run the /config command in your interactive session.
  2. Scroll down to the Copy on select option.
  3. Change it to false and press Enter.

@parthnaik-phantom since the built-in config solves this issue, you can probably close this ticket whenever you see this!

WillSmithTE · 3 months ago

Can we please make this opt-in? Terribly annoying default

Eloren1 · 3 months ago

Claude saw this page but still thought that there is no way to disable. Dear Claude, it's possible: /config -> Copy on select -> false but this should be done by user.

And another annoyance that you can disable in ~/.claude/settings.json:

```{
"env": {
"CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1"
}

Eloren1 · 3 months ago

@Youjin-cmd it's configurable, read the topic instead of ranting about all the same thing

<img width="292" height="102" alt="Image" src="https://github.com/user-attachments/assets/c0691718-2ae2-45ee-bd3c-18228d144b63" />"I agree" button

Youjin-cmd · 3 months ago

@Eloren1 My bad, Thank you for your reminder!

gui-wf · 2 months ago

Still, a file configurable would be appreciated. So we can more decoratively configure this

gui-wf · 2 months ago
Claude saw this page but still thought that there is no way to disable. Dear Claude, it's possible: /config -> Copy on select -> false but this should be done by user. And another annoyance that you can disable in ~/.claude/settings.json: `` "env": { "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1" } ``

which version is this accessible? mine, 2.1.216 is not there in TUI configs. A feature like this, implemented and no opt-in, without a config to accompany it, not cool

jlrs-rgb · 2 months ago

/config -> Copy on select -> false seems to work to disable the automatic copying, but since the ctrl+c copy and copy from terminal gui dropdown is still blocked, it leaves the whole experience kind of broken. this is such a weird default really because no other terminal experience works this way. please fix!

bcherny collaborator · 1 month ago

There's a toggle for this: run /config and turn off Copy on select. With it off, selecting text (including in the agents view) only highlights; use Ctrl+Shift+C (or Cmd+C on terminals with the kitty keyboard protocol, which WezTerm supports) to copy explicitly.

Docs: https://code.claude.com/docs/en/fullscreen (Use the mouse)

🤖 Generated with Claude Code

jlrs-rgb · 1 month ago

That's a very unsatisfactory "fix". Why should I have to remember a different keyboard shortcut to copy text for this one terminal app? It makes no sense. Very frustrated about this.

snailwei · 1 month ago

claude code intercepts the terminal copy on select, but it's buggy, it breaks the original terminal working copy features, the /config -> copy on select (disable) seems not effective at all. How do completely disable this buggy feature?!

github-actions[bot] · 1 day ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.