ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
74% Positive
Analyzed from 1815 words in the discussion.
Trending Topics
#claude#terminal#cli#code#windows#gui#paste#more#image#wsl
Discussion (63 Comments)Read Original on HackerNews
Desktop apps are a second class citizen that do not get feature parity
Lot of actions on Claude Code seem much more suited for a thoughtfully designed GUI
Even the chat responses and links therein can benefit from judicious use of rich text and formatting and real hyperlinks to other parts of the UI or elsewhere
Favourite Skills can be toolbar buttons or menus if user so wishes.
It was very poor UX (from the demos i saw) -- and i tried it myself in Windows native command terminal and the rendering was horribly broken (windows is a second class OS for dev tools).
A light weight GUI with keyboard shortcuts that mimic CLI experience would have been far better without taking anything away from power users of the terminal.
Started using computers when that was the only affordable way to use computers.
For some reason, some people really love to live in 1970's with their expensive HiDPI monitors.
A few years ago I watched an account work through my companies numbers using their accounting software. It's entry method? A windows commander like tool. The menu options like add expense etc were all numbered. So he never left the numeric part of his keyboard.
The tool looked super old and obsolete but as soon as you see a power user use it, you see why.
I can string together a complex series of text-related tasks far more effectively as a shell pipeline than I can by pointing and clicking in a UI. I can scale that sequence of tasks out to operate on every file on the filesystem if I want, or down to a single character in a single file.
Claude Code being a full-featured TUI is also helpful because I can quickly/easily use it remotely via SSH without having to deal with setting up X forwarding, VNC, Parsec, etc. The remote host doesn't even need to have a window manager. Sure, it'd be nice if it also had an elegant multi-page GUI so I could more easily drill into the actions its performing and make better use of my large screen to watch it do multi-agent things, but if I have to choose between the two, I prefer the TUI.
That said, I'd much rather use a GUI to do things that are actually visual/spatial in nature.
For those interested: https://github.com/madarco/agentbox
Since it's a CLI app, I can wrap it in yoloAI for the sandbox protection, and also use VS Code's tunneling feature to reach that sandboxed workdir (with permissions safely bypassed) through my GUI.
https://freeimage.host/i/screenshot-2026-05-19-at-141349.ByS...
I have a similar setup, but I access it directly via iTerm2 instead of VS Code's terminal. I've figured out the right terminal settings to get copying/pasting text to work (including with neovim's + register), but not images. Would be nice to paste images, though. Currently I have to SCP them over.
If I copy a file in Finder and paste it into a claude session, it shows in the TUI as [Image #1].
If I do the same, but paste into a claude session running over SSH, it pastes the path to the file, not the data.
If I open the image in Preview, copy the pixels (CMD-A, CMD-C), pasting that into a terminal does nothing.
So it looks like CC just puts UI sugar over top of the image path when it has file access to it? That's not really image pasting, though...
I still use GUI apps too, and actually find claude code to be closer to a GUI app than a cli.
People prefer terminal apps because they run inside our terminal app environments (kitty, zellij, tmux), tend to be keyboard driven, tend to be more lightweight than GUIs, tend to be scriptable, and can be run remotely over a standard ssh session.
A conventional GUI is a nonstarter in comparison.
Personally, I much prefer the CLI. The CLI is a tool that has been refined for over 50 years to excel at text input and output. Once you learn it, it can feel like an extension of your brain.
Frankly, the idea of having to decipher what a picture is supposed to represent to use a skill fills me with horror.
Being a power user, having used computers for more than 30 years, I usually prefer GUI because that's an evolution over CLI.
Going from the basic interpreter on ZX Spectrum to the command line in MS DOS had me mesmerized. Going from the DOS CLI to Windows 95 GUI, had me me mesmerized, too.
I think people in general consider themselves more pro and "hackers" if they use CLI and editors like Vi and Emacs.
There are bonus points for memorizing hundreds of different keyboard shortcuts and not using the mouse at all.
If they absolutely have to use GUI, they not use a desktop environment in Linux but a stacking window manager.
Unfortunely they hear that and only understand Emacs.
That's the real reason.
If you don't believe me, take a look at the leaked codebase from a couple weeks ago. It's the stuff of nightmares, because too many junior devs slopcoded in all places without any plan or understanding of software architecture patterns. They never actually take the time to refactor, there's dozens of outdated redundancies and orphaned modules all over the place.
Without good architecture patterns, there can be no good GUI nor good UX.
(disclaimer: I work at MS, not on WSL)
My current workaround is to paste it inside the working directory on the host machine, then @ reference it, but would be nice to streamline that workflow.
I sure wish it didn't have to be a console app
https://github.com/ghostty-org/ghostty/discussions/10099#dis...
Code: https://github.com/rajveerb/wsl-clip-bridge
As it stands the only reason I have to pain myself back into using Linux on bare metal laptops, instead of VMs, is independence from US technologies in European soil, which also implies not having to care about Claude.
I'd rather continue to be as productive as possible.
Terminals are not alternative web browsers/graphical application sandboxes.
If it ain't broke, don't fix it