Slack was having a bad day on my machine. Typing :wave: was taking two seconds to autocomplete. Two seconds to autocomplete an emoji! The fan was spinning. The whole app felt sluggish.
I have Slack running pretty much nonstop. Most people do. And the whole time I was watching that emoji dropdown crawl I kept thinking.. man, this is just text.
Terminals are great at text. The tools I rely on every day - vim, btop, tig, k9s - are a joy to use. They are incredibly fast and responsive. They feel alive. Meanwhile the app that I have to live in all day, where all my conversations happen, is the slowest thing on my machine. It is also freaking enormous, a bundled Electron app that takes up a ton of memory and disk.
Slack is just text. Terminals are great at text. So why am I running 1.5GB of Chromium to read it?
Where are all the TUI Slack clients?
I figured someone would have built this already. Slack is twelve years old. The TUI ecosystem has been mature for years. The intersection seemed obvious.
But it didn't exist. Not really. There were a few projects, mostly abandoned, mostly bare-bones. Nothing daily-driveable. Nothing that felt like a real Slack client. The gap was weird.
The honest answer is that polishing a TUI Slack client probably wasn't worth one person's year. Slack works, more or less, for most people. The desktop app is bloated but functional. The cost of building a real replacement was high and the audience was small. So nobody did it.
The unbuilt apps in the world aren't blocked by demand anymore. They're blocked by whether someone cares enough to scratch the itch.
What if I built it?
So I decided to try. Were TUI libraries up to a good Slack experience in 2026? Many unknowns: Real-time messaging. Threads. Multi-workspace. Polish that didn't feel like a 1995 IRC client. Images and avatars, which I knew were possible in terminals but didn't know how they worked, or whether they'd hold up in a Slack TUI.
The answer, working through them one at a time, seemed to be yes. The TUI ecosystem is in a really good place. Opencode, the AI coding TUI, was already proof. I use it daily. Modals, spinners, motion. Well put together.
Early on while I was deciding the stack, I really wanted to land on one single, portable binary. I didn't want to ask users to install Node or Python or Ruby or any runtime. I wanted a single download that just worked. That meant Go.
The next question was what TUI libraries are available for Go. I discovered charm.land. What a joy this suite of librares is. Bubbletea handles architecture, lipgloss handles styling. The V2 release also handled layouts, which was the key to making it feel polished without a ton of custom code.
Images and avatars are a core part of Slack's UX. So I knew I needed to figure out something there. Kitty's graphics protocol does what it says on the tin, and my tests showed it was viable for my use case.
All that being done, I figured I'd let agents do most of the typing and see how fast I could go.
The build
I started with the part I was most worried about: images.
The Kitty graphics protocol gives the terminal a way to render true-pixel images, not just half-blocks or sixel. In a Kitty or Ghostty terminal, slk shows real Slack avatars and images. They look like avatars, not blocky ASCII approximations. This was the moment slk stopped feeling like a half-toy. The screenshots in this post look the way they do because the avatars and images actually render in the terminal. If you try slk in a non-Kitty terminal, you'll get ASCII approximations instead.
The main slk view. Avatars are real pixel data rendered via the Kitty graphics protocol, not ASCII approximations.
The rest of the work was less surprising and more satisfying. Real-time messages, edits, deletes, reactions, and typing indicators over a WebSocket. Multiple workspaces stay connected in parallel with live unread badges in the left rail. Press 1 through 9 to jump between them. Vim-style modal editing. Fuzzy channel finder. Threads in a side panel, plus a workspace-wide threads view because I always forget which channel a thread came from.
The threads side panel. The workspace-wide threads view sits one keypress away.
35 themes ship with it (including Hot Dog Stand, haha. I'm old.), with a live switcher. Smart paste handles clipboard images and file paths and text in one go, captions included. Slack-native sidebar sections are kept live, or you can configure your own with globs.
Mid-switch in the live theme switcher. 35 of these ship with slk.
The binary is 24 megabytes. A live multi-workspace session uses a fraction of the RAM. The official Slack app on the same setup uses five hundred megabytes to a gigabyte and a half. Same conversations. Same productivity.
This isn't a toy. It's my daily driver on Linux and Mac.
One week of intense vibed-out building
The spark hit hard.
I had been irritated by Slack for years, the kind of irritation that builds when a piece of software is always there but never quite right. Once I started writing slk, I couldn't stop. I ravenously coded for a week. I shipped more commits in those seven days than I'd shipped in any week of my life.
One week of slk commits. More than I'd shipped in any week of my life, and I commit stuff near-daily.
The setup was four tmux windows, opencode in each one, agents running in parallel git worktrees. Most of the typing was theirs. The decisions were mine.
The agents were great at the things I didn't want to spend a week on. Bubbletea boilerplate, lipgloss styling, parsing Slack's internal protocol, the theme system. The repetitive UI plumbing that holds the whole thing together.
I drove the things that mattered, starting with the architecture. After that was settled, it was a matter of implementing functionality on top. Then many many rounds of small polish decisions that make a tool feel alive, not just functional.
The reality is that building this way feels magical and is insanely addictive. The agents did not replace the builder's high of seeing something work. They cranked it up to borderline unhealthy levels. I was riding a wave of obsession for a week, and the agents were the jet fuel.
Most vibe-coded projects are toys because most people stop. slk is what happens when a builder gets obsessed and runs four agents in parallel for a week. The skill isn't writing code. It's communication, judgment, and being ready to ride the obsession when it shows up.
...but slk is not garbage
The line on vibe-coded software is that it is garbage. Unreliable. Falls apart the second anyone pushes on it. I am living that in my day job right now. The people saying it are not wrong.
slk is not that. slk works. The reason is not the agents. The reason is how I drove them.
I challenged the agents deeply on architecture at the start. I stressed unit tests and TDD for every change. I stressed documentation and readability. I actually read the code.
I insisted on agents generating code I would have strived to have written myself - well-documented, well-factored, easy to change, easy to extend. All those things that Uncle Bob likes. If the agent shipped code that didn't meet that bar, the code did not stay.
Most vibe-coded projects are garbage because most operators don't bring the discipline. The agent is the typist. You're still the architect.
Try it out
I built slk for me. That has not changed. If you live in the terminal and live in Slack, it might fit your life too. If it does, here you go:
brew install gammons/tap/slk
The source is on Github. There's also a marketing page of sorts. The wiki has setup, keybindings, and configuration. Read the tradeoffs page first if you want to know what is and isn't there. It's still not perfect - there are missing features and bugs. But it is a real Slack client that you can use today.
slk is not feature-complete. Huddles, screen sharing, and Slack apps are not there. But it is my daily driver. PRs welcome. Bug reports more welcome. The people I most want to hear from are terminal nerds who try it.
Top comments (0)