Ask HN: Why are Gemini CLI and Claude Code TUIs so terrible?

Posted by oblio 11 hours ago

I figured I'd jump into this great age of GenAI coding with Gemini CLI and Claude Code.

I created a small project to test things out and started asking questions (plus set up agents files). And frankly, I'm less than underwhelmed. Bugs galore, some making both these tools unusable (which is shocking, I'm fairly sure Claude Code was the first one and it's not Open Source, so Gemini CLI must be an independent reimplementation - but somehow they both seem to share the same types of bugs).

For example when I ask Claude Code a question on Ubuntu 24.04, if the answer is longer than about a full screen, I can't scroll up to see the entire answer. When I scroll up to see the answer, the Claude Code scrolls up ALL THE WAY TO THE TOP OF THE ENTIRE CONVERSATION, and I can't scroll down gradually. So I either see the first question and whatever fits in one screen-full of text or I see the bottom screen-full of text for the last question. No in-between. This makes Claude Code unusable since most answers are longer than a page.

Gemini CLI also suffers from silly scrolling bugs.

These are known issues, I've asked Gemini about both and it provided workarounds that mostly don't work.

I'm trying to use the CLI modes instead of TUI (claude -p "question here"...) but it's a lot more cumbersome. Plus I lose the immediate context for series of questions.

Is this the GenAI revolution? Am I holding it wrong? Is everyone vibe coding on Macs?

I'm fairly sure I have the latest versions for both CLIs and I swear I've seen better implemented TUIs from the 90s, before the 10x vibe coding revolution.

Now, don't get me wrong, they're both nice for exploring and definitely unlock lots of possibilities, but how can the tools themselves be so abysmal with so many billions invested into them?

I'd think both companies can afford top notch CLI/TUI tool developers - and DX is a sink-or-swim type of test for both tools.

Is OpenAI Codex any better?

Comments

Comment by vmitro 10 hours ago

If you check out the GitHub issues on the Claude Code repo and sort by comments, you'll see that the first page is littered with the same issue you're talking about.

The answer seems to be in the vendored ink.js, at least in Claude Code's case. I actually asked Claude Code to look into its own minified and abfuscated source code and pointed it to ink.js's repo to try and deduce how and why the bug occurs; the easiest way to reproduce is to already have a few hundred to a couple of thousand lines of chat output ready and enter enough newlines that the height of the inputed text is > the height of the current terminal. But not only input box, but also other ink.js "widgets" have the same problem: everything gets redrawn over and over again (each color change of the flabbergasting... status re-triggers it, forcing terminals that don't handle OSC10/11 codes properly to rescroll from the beginning... or at least that's my interpretation).

Anyway, after a few flabbergastings of its own and my suggestion to make a wrapper around its output via xterm.js to always render a sliding fixed window of terminal_width x terminal_height and manage its scroll internally, as well as mapping the mouse wheel to scrolling / panning horizontally this virtual viewport and I had a basic, scroll-bug-free, 650 LOC node.js app that basically circumvents this issue completely, plus works in Windows Terminal and VS Code terminal. I've been using this as a drop in replacement since about a week or so and the only thing missing is a bit more draw call waiting on terminal resize since it triggers a reflow with visible scroll, but much, much faster than the annoying bug (sub 100ms).

As always, the feature creep is strong, there are som vim bindings now, and Claude, Gemini and Codex are currently working together (I have multiple terminal planes inside the app a la tmux) on implementing FIPA ACL inter agent communication via built-in MCP chat server. You can check it out at github.com/vmitro/bukowski and don't worry about the license, it's satire, it's basically free for any use (and besides, Paddle won't let me set up the $1M "Premium Luxury Enterprise License for Companies valued > $1B that Make non-open-source AI Tools"...)

Comment by oblio 9 hours ago

Thank you for the tool suggestion, it sounds great, I'll take a look!

At this point I was thinking about setting up https://opencode.ai/ - I think Claude Pro (aka $20 per month) allows it?

I don't want API access (I think), because that's priced per actual usage and I want a capped subscription cost, and I'm fairly sure OpenCode needs API access.

I really want to use the official clients but they're just SO bad.

Which, if you think about it, is the perfect anti-advertisement for AI coding. If the prestige AI shops can't create almost perfect clients for their own tools, then how good really is AI for coding???

Comment by krasin 10 hours ago

I am usually running Claude Code in tmux on a Mac. Absolutely zero scroll issues (but I use tmux scroll for that, naturally). It's a delight.

Comment by vmitro 10 hours ago

I did try using tmux in VS Code's terminal, but still managed to hit this issue with very large scroll buffers. Bumping tmux's internal scrollback buffer capacity to a 50-100k would delay the issue, but it would still eventually occur. In the last few CC versions they did get rid of the old buffer after e.g. conversation compaction, so that's maybe why you don't experience the issue anymore. An Anthropic engineer had even done a PR on tmux's GitHub repo to implement the OSC10/11 shennanigans, so jt seems tmux is not immune to it at all.