Foot is the lean Wayland-native choice; Alacritty is the portable minimalist GPU terminal; Ghostty is the more feature-complete, polished daily-driver. For an Arch/Linux workflow with a compositor and tmux/zellij already doing session layout, foot is often the most coherent fit.
Aspect
foot
Alacritty
Ghostty
Primary design
Minimal, Wayland-native terminal
Minimal, GPU-accelerated cross-platform terminal
Native-feeling, GPU-accelerated full terminal app
Programming language
C
Rust
Zig
Platforms
Wayland Linux/BSD-focused
Linux, macOS, Windows, BSD
Linux and macOS
Rendering
CPU/software-oriented, optimized for low overhead
OpenGL GPU rendering
OpenGL on Linux; Metal on macOS
Resource model
Very lightweight; optional server/daemon mode can share Wayland, parsing, rendering, and font-cache work
Lightweight, but GPU-oriented
Larger feature/UI footprint
Tabs and splits
No built-in multiplexer-like UI
No built-in tabs or splits
Built-in tabs and splits
Configuration
INI-style foot.ini
TOML (alacritty.toml)
Simple key/value config
Graphics
Supports sixel and other modern terminal capabilities
Deliberately limited graphics scope
Kitty graphics protocol
Best pairing
Sway/Hyprland/River + tmux/zellij
Any OS + tmux/zellij
Standalone terminal workflow, especially macOS or desktop Linux
Given a Linux/Arch, command-line-heavy workflow:
Try foot first if you are on a Wayland compositor and already use tmux or zellij. It is likely the most mechanically simple, low-overhead choice.
Use Alacritty if cross-platform dotfile parity matters or you regularly use non-Wayland systems.
Use Ghostty if you want a polished terminal UI with native splits/tabs and modern terminal graphics, and accept a larger, more opinionated application.
One useful feature is to be able to paste images or screenshots into a Claude Code session, foot appears to support that.
What happened: your terminal’s clipboard held actual PNG bitmap data (not a file path or URL). Claude Code read those bytes on paste, wrote them to a session-scoped cache file, and sent the image inline to me as base64 in the message:
/home/cbrake/.claude/image-cache/03894d10-3015-4a6a-984b-aeb3f83f7e8d/1.png — 250 KB, PNG, 1307×1350, RGBA, written at 11:48
The directory name is this session’s ID, so the cache is per-session
I received both the decoded pixels (which is how I read the table) and a text note giving that path. If it had been a link, I’d have gotten a URL and would have needed WebFetch to retrieve it; if it had been a file path, I’d have needed to read the file.
Incidentally, this settles the “Claude Code image paste” row of that table for your setup — clipboard→Claude Code image paste works in whatever terminal you’re running right now.
What actually happens is that Claude Code bypasses the terminal:
Claude Code’s TUI captures Ctrl+V as a key event before it means anything to foot.
It shells out to a clipboard helper — the binary contains wl-paste, xclip, and xsel strings, and you have wl-paste and xclip installed.
wl-paste -t image/png pulls the raw bytes straight from the compositor’s clipboard.
Those bytes land in ~/.claude/image-cache// and get base64’d into the API request.
Your clipboard still holds that screenshot, offered as image/png plus a pile of Qt-converted formats (application/x-qt-image — a KDE app such as Spectacle put it there). wl-paste reads it directly.
So the practical requirements are Wayland (or X11) plus wl-paste/xclip on PATH — the terminal is irrelevant. That table’s “Uncertain; test on your compositor/clipboard setup” row can be marked resolved for your machine: it works, and it would work identically in Alacritty or Ghostty for the same reason.
Two related notes:
foot’s sixel support is the opposite direction — foot rendering images to your screen, unrelated to clipboard input.
The SSH row holds, and now you can see why: wl-paste talks to the local compositor. Run Claude Code on a remote host and there’s no local clipboard to reach, regardless of terminal.