The headache I recently had was it somehow started interpreting mouse clicks in the terminal to mean I clicked an option when I was really just trying to get/confirm window focus.
They also randomly changed how copy-paste works in a way that made it really annoying to copy text.
Vibe-coders pumping out features: this is the reaction you're going to get if you inflict this on your users! Nobody wants software that updates every day and changes in fundamental ways that are hard to keep up with.
Copy/paste is one of the most basic, low-level features of a modern operating system. NO APPLICATION SHOULD EVER SCREW WITH IT, IN ANY WAY!
And I say this not just as a seriously annoyed user, but also as a professional UI developer: it is a well-known anti-pattern to override the user's expectations, at any level ... and that applies tenfold to the most basic patterns that every other app follows.
I don't care if you added a magic way to write all my code for me: if the only way to invoke it is to break copy/paste, you've failed at development!
> Copy/paste is one of the most basic, low-level features of a modern operating system. NO APPLICATION SHOULD EVER SCREW WITH IT, IN ANY WAY!
-Ghostty enters the chat-
Middle-click paste in Ghostty is hazardous: the damn thing can move your cursor to the position of your mouse pointer and paste there. An utterly infuriating behaviour - it is a text terminal. It has no business emulating the usability crimes GUIs first committed and then committed to.
I wonder if it's the same behavior as copilot cli. I dug into it when I got annoyed and found that there's a fundamental tension between rendering the cell based UI and supporting the terminal's native copy paste. At least on copilot cli there were extra zero width characters being copied.
My memory is that once you begin using the alternate screen, you need to turn on mouse reporting, and then you lose native copy. Different terminal emulators also act totally differently when in this state.
This bit me too. If I wanted a mouse-driven app, I'd use the GUI. I don't understand why they're trying to replicate that experience in a text environment.
Both Claude Code and Codex have issues overwriting or duplicating text for me when scrolling.
Probably from trying to keep scrollback virtual while anticipating terminal resize. But I wouldn't mind a way to opt back in to naive, unlimited convo scrollback.
I saw that but it asked me if I wanted to optin first! I did accidentally and hated it since I always click on the terminal to make it focused and now accidentally click on something that actually responds!
I really hate that change. It's counterintuitive that a shell recognizes mouse clicks to mean "select this option".
Also, the auto-copy selected text feature is awful. That's another thing that is so counterintuitive. I have never seen a UI where just selecting text means auto-copy to the paste buffer. Who is coming up with these awful UX ideas?
On top of that, the scroll "feel" of the new client (at least on macOS) isn't quite as good as their old one. It just feels off and not like a native terminal.
Vibe-coders pumping out features: this is the reaction you're going to get if you inflict this on your users! Nobody wants software that updates every day and changes in fundamental ways that are hard to keep up with.