I currently use tmux. Not because I need to multiplex shells in a remote server, but because I like to have my sessions persisted in my local machine. Even between reboots (technically not the same session, but the same tabs and splits I had). I currently have that with tmux and a tmux plugin that restores my sessions. But I think that tmux is overkill for this. And if I'm in a tmux session, then I can't use my terminal emulator's native tabs and splits. Does anyone have a recommendation of how to handle only terminal sessions on Linux?
You've obviously written this because screen wasn't doing the right thing, but your readme only explains that it's a "young project, not a drop-in GNU screen replacement". What are its advantages over screen or tmux?
screen actually works the same way architecturally: it parses all output through its own built-in terminal emulator and redraws from that state on reattach. But that emulator is decades old and lags far behind what modern programs emit. Whatever it doesn't understand gets dropped or mangled on redraw. boo swaps that layer for libghostty-vt, Ghostty's VT core, so the saved state matches what your terminal would actually display, and terminal queries get answered while detached so TUIs don't hang unattended.
tmux is great, it was just never the model I wanted. I really liked screen's simplicity, sessions and a prefix key and nothing else to learn, and boo keeps exactly that.
I didn't say you couldn't have multiple clients, I said clients and servers are the same process forked. Or did someone add distinct client/server support to screen finally? I know theres a lot of stuff bolted onto screen over the years but I wasn't aware they dropped forked servers for the tmux model...
Did a bit of digging; the first client gets forked to create the "server". The forked server then detaches and runs in the background. You're right that -x creates an entirely new, separate client process, unrelated to the OG client or the forked server.
Without -x though it works as originally described.
Edit: gnu screen 1.0 was originally released in 1987. The -x flag was released in screen 3.0 in the 90s. TIL
I want boo to be a screen replacement, not a tmux replacement. tmux gives you a whole workspace: layout, scrollback, copy mode, a status bar. screen's appeal was that it did almost none of that: sessions, a prefix key, done. boo keeps that model and swaps the emulation for libghostty so reattach actually redraws correctly.
They also compose: a boo session is just a PTY running a program, so you can run tmux inside one if you want.
Installed using the curl-to-bash on Sequoia and I’m getting “error: ReadOnlyFileSystem” on ‘boo new’. Can’t see any open issues on gh and nothing in the readme.
Definitely interested in something like this - love ghostty and I’ve been finding Zellij a bit crashy recently (plus I don’t really need tabs).
This is super cool. I've been a heavy tmux user for a long time and using it more with my coding agent sessions and prefer ghostty. What was the biggest challenge when it came to building a multiplexer directly on top of libghostty that you ran into?
Really dig the minimal approach here. Swapping the backend to libghostty is exactly the kind of clean architecture we need. Going to test drive this today.
Slightly off-topic:
I currently use tmux. Not because I need to multiplex shells in a remote server, but because I like to have my sessions persisted in my local machine. Even between reboots (technically not the same session, but the same tabs and splits I had). I currently have that with tmux and a tmux plugin that restores my sessions. But I think that tmux is overkill for this. And if I'm in a tmux session, then I can't use my terminal emulator's native tabs and splits. Does anyone have a recommendation of how to handle only terminal sessions on Linux?
This is the exact use-case Boo is made for!
You've obviously written this because screen wasn't doing the right thing, but your readme only explains that it's a "young project, not a drop-in GNU screen replacement". What are its advantages over screen or tmux?
Fair. Adding a section for this now.
screen actually works the same way architecturally: it parses all output through its own built-in terminal emulator and redraws from that state on reattach. But that emulator is decades old and lags far behind what modern programs emit. Whatever it doesn't understand gets dropped or mangled on redraw. boo swaps that layer for libghostty-vt, Ghostty's VT core, so the saved state matches what your terminal would actually display, and terminal queries get answered while detached so TUIs don't hang unattended.
tmux is great, it was just never the model I wanted. I really liked screen's simplicity, sessions and a prefix key and nothing else to learn, and boo keeps exactly that.
can you share more on the tmux model vs boo?
Tmux is n clients to 1 server.
Screen is 1 server to 1 client.
In screen each client session is a fork of the screen server. In tmux there's one server and many client forks iirc.
this is incorrect. you can have multiple clients using screen -x instead of screen -a
I didn't say you couldn't have multiple clients, I said clients and servers are the same process forked. Or did someone add distinct client/server support to screen finally? I know theres a lot of stuff bolted onto screen over the years but I wasn't aware they dropped forked servers for the tmux model...
Did a bit of digging; the first client gets forked to create the "server". The forked server then detaches and runs in the background. You're right that -x creates an entirely new, separate client process, unrelated to the OG client or the forked server.
Without -x though it works as originally described.
Edit: gnu screen 1.0 was originally released in 1987. The -x flag was released in screen 3.0 in the 90s. TIL
I want boo to be a screen replacement, not a tmux replacement. tmux gives you a whole workspace: layout, scrollback, copy mode, a status bar. screen's appeal was that it did almost none of that: sessions, a prefix key, done. boo keeps that model and swaps the emulation for libghostty so reattach actually redraws correctly.
They also compose: a boo session is just a PTY running a program, so you can run tmux inside one if you want.
Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) are getting classified that way.
Apologies, half of this indeed was. As I was iterating on the README this seemed apt, but I will refrain!
Appreciated! The community feels strongly about this.
Been using zmx for a few months and love it: https://github.com/neurosnap/zmx/
Very similar, based on libghostty
same, love zmx and it's minimalism policy.
Installed using the curl-to-bash on Sequoia and I’m getting “error: ReadOnlyFileSystem” on ‘boo new’. Can’t see any open issues on gh and nothing in the readme.
Definitely interested in something like this - love ghostty and I’ve been finding Zellij a bit crashy recently (plus I don’t really need tabs).
How have you been using Zellij? It's been working great for me
I'll take a look at this now. Thanks for reporting!
Just published v0.5.13 which should fix this! It seems to be a path issue. Now boo falls back to tmpdir for storing sockets.
How would this compare to shpool: https://github.com/shell-pool/shpool
I think Cmux is the incumbent in the "screen-style terminal multiplexer built on libghostty" - any key differentiators here? https://cmux.com/
Cmux is a standalone terminal. Boo is a command-line similar to screen, backed by libghostty for terminal emulation.
This is super cool. I've been a heavy tmux user for a long time and using it more with my coding agent sessions and prefer ghostty. What was the biggest challenge when it came to building a multiplexer directly on top of libghostty that you ran into?
Interesting choice building on libghostty — how does it handle session persistence across reconnects?
Really dig the minimal approach here. Swapping the backend to libghostty is exactly the kind of clean architecture we need. Going to test drive this today.
this looks nice! i've been using herdr the last couple of weeks as a terminal multiplexer for agents, which works amazingly well.
One window per session
This no good ;)
Old busted screen can do multiple windows per session.