[question] how to disable copy on select?

[fu050409]

question

I dont want to copy the text i selected, but i cannot find a way to disable this behavior.

context

No response

[krotname]

From the current config/docs, I do not think there is a separate "select text but do not copy it" switch yet.

Herdr's selection path is currently designed as copy-on-select: the selection lifecycle in src/selection.rs says mouse drag highlights the cells, and mouse up extracts the text and copies it. The README describes the same behavior: drag-select inside a pane copies pane text.

There are two related settings, but neither is exactly this feature:

[ui]
mouse_capture = false

This lets your outer terminal handle normal mouse selection/copying instead of Herdr. The tradeoff is that Herdr's mouse-native pane/sidebar interactions are disabled too.

[ui.toast.clipboard]
enabled = false

This only hides the "copied to clipboard" popup. It does not stop the copy itself.

So the current answer is: not granularly configurable. Use mouse_capture = false if you want to opt out of Herdr mouse selection entirely, otherwise this would need a new config option such as copy_on_select = false / mouse_copy_on_select = false.

[tdi]

@bausmeier why is that ? just curious - tmux was also "werid" in how copy was done

[bausmeier]

It's the same sentiment that someone else already expressed in another discussion thread (#748):

Middle-click paste is muscle memory in my Linux workflow. With herdr I select text in a pane but can only paste it via the system-clipboard path, which clobbers whatever I had on Ctrl+C and breaks the select-here / middle-click-there flow I use constantly between terminals and the browser.

What sets herdr apart from the alternatives for me is this:

run your agents where they already run; your machine, a server, anywhere you can ssh. each one gets its own real terminal, not an app's imitation of one

But in this case the "real terminal" is behaving differently to what I expect. I like being able to interact with herdr's own UI with a mouse, but want to interact with the actual terminal part as I usually would.

I'm not coming from tmux here. My current setup is persistent layouts using a tiling window manager. Visibility of agent state is the key feature that herdr provides me over that, and the ability to detach and reattach is nice to have too.

[voidwarriorchan]

I completely agree.

[timwitty]

I ran into this issue immediately when I tried to adopt herdr and basically stopped using it. This isn't the behavior I want from my terminal. If it was, I would have it enabled for my terminal.

I'm also not coming from tmux, I want it herd my agents, the paning and such is just extra for me.

[rdhar]

The recent addition of ui.copy_on_select resolves this behaviour.

[rdhar]

As of v0.7.4 released July 15, 2026, ui.copy_on_select is available to disable automatic clipboard copying after mouse selection while keeping the selection visible. This can be configured by adding/reloading the following to your "~/.config/herdr/config.toml" file:

[ui]
copy_on_select = false

[timwitty]

@rdhar I tried and it doesn't solve this fully for me. While it eliminates the copy, it also completely disables mouse text selection. So, you cannot even select the text in order to use your terminal's default copy behavior.

[rdhar]

@timwitty could you confirm the version of herdr you're running?

$ herdr --version
herdr 0.7.5

This bug is fixed in https://github.com/ogulcancelik/herdr/releases/tag/v0.7.5 yesterday, via #1471.

[timwitty]

@rdhar Thanks for the follow up. I was on 0.7.4. And it is closer but not quite there. The text stays selected now without copying automatically, but I can't copy it. I'm on macos, neither ctrl+c or cmd+c work and right click brings up herdr menu. I'm very new to herdr so, I could be missing something on getting this to work.

[blalor]

copy_on_select = false is insufficient, from what I can see. Selecting text with click-and-drag doesn't automatically copy, but double-clicking on text does.

[rdhar]

@timwitty @blalor Tested locally and reproduced the buggy behaviour, so I've left a comment tagging both of you in the linked issue #1471 (comment).

[ogulcancelik]

all issues about this should be fixed now!