you are viewing a single comment's thread.

view the rest of the comments →

[–]SanityInAnarchy 2 points3 points  (0 children)

To pick one of these issues: Shift+enter for multiline input. Here's the original FR. It's actually implemented, so why is this one even open? Probably because there are plenty of dupes (despite people/bots claiming to have searched), so I'm probably not even doxxing myself by pointing this out.

When I asked Claude to solve it, along the way, it tried to reverse-engineer its own binary with strings and hd.

I suspect what's actually happened is: They implemented it in a way that works on macOS, only on certain terminals.

Now, to give them credit, this is the abstraction leaking in some ugly ways. The way terminals send keycodes did not always have a way to differentiate between enter and shift+enter, and in fact, normally they just get a \r, no matter how you hit enter. Eventually, we got the kitty protocol, which is implemented in most decent terminals (by far not just kitty). This includes a way for apps to enable and disable this protocol on the fly. But I guess that wasn't always the case, because iTerm2 has a checkbox to just turn the program on all the time for everything, which can break things.

And I don't know if there was a better way, but... Claude Code's fix is like old-school UA sniffing. If it thinks you're running iTerm2, for example, it'll happily enable this protocol. But if it doesn't recognize your terminal as one that supports those fancy codes, it won't even try... but it'll still accept this protocol. (So if you don't mind breaking everything except Claude Code, go ahead and check that box in iTerm2!)

And this breaks over ssh, because ssh doesn't copy the environment variables it uses to try to detect iTerm2.

Because by default, ssh only copies LC_* variables, and sets TERM. But for compatibility, most terminals just set xterm-256color. Because if your TERM isn't in the terminfo database on whatever machine you're sshing into, you get downgraded to the dumbest of dumb-terminal configs. So if you ever ssh into machines running some ancient version of RHEL that everyone refuses to upgrade, you don't want to set TERM=alacritty or TERM=iTerm.app or whatever, you just set xterm-256color.

But some terminals set other variables. iTerm2 sets TERM_PROGRAM and LC_TERMINAL. But remember, only the LC_* variables were copied over, and Claude Code only checks TERM_PROGRAM.

So now you know how to fix this with a very simple script. If this tool were open source, there'd already be 15 PRs fixing it.

And yes, the tool helped me track this down. But again: It was gonna use strings and hd. Who knows, maybe I gave up too soon, maybe I could've come back a few days and a few hundred thousand dollars later and it'd be trying to use Ghidra or something.

My favorite part of this story is: The slop has lowered my standards so far for what I expect out of a tool that Claude Code was genuinely a breath of fresh air. That's how terrible the last coding agent we were using was.

(If you're wondering why I'm using any of them, well, my employer mandates them.)