From gaming on Windows to Claude in my status bar

Two years on Linux, a Steam Deck, Proton running everything else, and one question: what if Claude could actually drive my machine? It ended up in the one place I always look.

Gaming was the last thing keeping me on Windows

I had looked at Linux for years. I tried it at several points in my professional life, always with the same outcome: interesting, but I had a machine I also used for gaming, and Windows was the only viable PC gaming platform. So Windows stayed.

Two things changed that. Valve's Proton compatibility layer matured to the point where most of my Steam library ran on Linux natively. And Valve launched the Steam Deck. The Deck became my main gaming device, Proton covered anything I still wanted to play at the desk, and suddenly gaming was not a Windows reason anymore.

The excuse was gone. My desk machine did not need to run Windows. It could be anything I wanted.

I switched to PopOS. That was two years ago. Hello Linux, finally.

Then Claude CLI arrived, and I gave it the keys

A couple of years in, PopOS felt steady and familiar. Most of the Windows-shaped parts of my workflow had found Linux equivalents. But the usual low-grade friction was still there: packages that behaved differently from one setup to the next, a couple of hardware-specific quirks I had never run down, scattered minor issues I kept telling myself I would fix later.

That is when Claude CLI landed.

The first thing I did was the least guarded experiment: I let it have full access to my machine. Not a sandbox, not "generate a command for me to review", actual access. I wanted to see what would happen if I stopped reading forum threads and let an agent do the research for me.

I asked it to audit the laptop. PopOS was running well on hardware that had been designed for Windows, but I had seen a couple of unexplained crashes and some weird behaviour. Rare, but rare bugs are the worst kind of annoying.

"Audit my machine, investigate everything, make it the most stable install possible."

It went away for a while, made changes, explained them as it went, restarted a few services. Since then, not a single crash. Not one weird behaviour. The machine has been perfectly stable.

That was the moment the experiment stopped being an experiment.

Claude as my Linux co-pilot

What happened next was a progression. Not "I learned Linux, then I added Claude as a helper". The other way around. Every step of my Linux evolution was Claude handing me the shortcut.

The first wave was on PopOS, my daily driver for most of those two years. When Cosmic landed, PopOS's new compositor, I tried it and liked it. One problem: on my laptop, I could not switch workspaces with the touchpad. A small thing, but on a touchpad-heavy workflow, every gesture counts.

"Hey Claude, could you add this feature please?"

It could. It did. Workspace-switch gestures, working.

Around the same time, I was ditching my last Windows laptop and installing PopOS on its replacement. I was already used to my existing config, and I did not want to rebuild it by hand.

"Create a USB key that contains all my apps and preferences. Also leave a small documentation file, because another agent will have to use it later."

It made the USB. I took it to the other machine. I asked the agent on that side to import it. It did.

The detail I want you to notice in that story is not the USB. It is that the first agent wrote documentation for the second agent. I did not ask it to explain the USB to me. I asked it to explain it to the next agent. That is not a chatbot. That is collaborating infrastructure.

Then, about three weeks ago, a new desktop machine arrived, and I decided to accelerate.

I wanted to try Hyprland. Hyprland is powerful but famously configuration-heavy. The usual deal is: expect an afternoon, probably a weekend, deep-diving into the docs before you have something pretty. I did not have that afternoon.

"Could you install Hyprland and apply a retrowave style?"

(I will not defend the taste. It is mine.)

It set up Hyprland. It themed it. I had a working retrowave tiling desktop in minutes, not hours.

From there I landed on Niri, the most fire-and-forget compositor I have used, and for me the most productive one. Niri gets out of my way. Windows go where I want them, I do not think about layout. That single property, fire-and-forget, turned out to be the principle I wanted from my assistant too.

From tool to infrastructure: Claubar

By the time I was running Niri with Claude as my permanent co-pilot, I noticed a pattern. Every few minutes, I wanted to talk to Claude about something. Every few minutes, I would open a terminal, type claude, wait for the session to spawn, ask my question.

Niri had solved a similar problem for my windows: fire-and-forget. No window juggling, no layout thinking. I wanted the same for my assistant. Not on-demand. Always-there.

The result is Claubar: a fork of Waybar (the Linux status bar) that hosts a permanent Claude session inside a drop-down terminal pane.

• One keystroke away. Super+` expands the bar into a terminal pane. Press it again, it collapses. Drag the bar to resize on the fly.
• Always on. The Claude session spawns when the bar starts, respawns if it crashes, and always runs with --continue, so the conversation survives reboots.
• Available everywhere. The panel overlays the desktop, regardless of workspace, regardless of application. One keystroke from anything you are doing.
• No Electron, no browser tab. Just a libvte widget inside GTK. Same lightness as Waybar itself.

Super+` expands the bar into the terminal below. A previous session is already there, because the agent runs with claude --continue. The terminal resizes and scrolls like any other. Super+` again, gone. Always there, never in the way.

Technically it is a stock Waybar fork with one extra top-level config key, a VTE-based lower pane, and just enough glue so your existing Waybar modules and CSS keep working. Open source, MIT-licensed, alpha today, running on my daily driver.

Repository: gitlab.com/nirmak-group/claubar.

Living with it

A few examples of how Claubar shows up in my actual week.

System admin with no Googling. A systemd unit was failing, I did not know why. I asked Claubar to read the journal, explain the failure, and fix the config. Three messages, two minutes. Before, I would have opened a browser, searched terms, compared forum answers of varying age. Now I ask the agent that is already watching me work.

Non-coding tasks, just as often. I downloaded a long PDF and did not want to read all of it. I asked Claubar to summarise the key findings. One sentence in the bar, done. No application switch, no file upload.

Small glue tasks that used to eat an afternoon. Adding a new audio input and auto-switching it when a specific app opens, the kind of task that usually means twenty minutes of blog-post reading plus half an hour of config tweaking. Instead: two messages, Claubar read the state, applied the config, tested it.

Drafting, translating, rewording. I write in English here and in French elsewhere. Sometimes I just want a phrase sharpened or translated properly. The assistant is right there. No context switch.

The claim I want to make carefully: on my day-to-day work, Claubar is a genuine multiplier. Not "saved three minutes" here and there. The deeper effect is that tasks I would have avoided, postponed, or clumsily half-done, I now actually do, because the friction of asking dropped to zero.

The distro is next, but Claubar is enough today

The longer-term ambition is a full Linux distribution built around this principle: Claude as the central assistant, a default setup tuned for productivity, portable across every machine I own. I have been running toward that for a while.

But Claubar is the interesting part. A distro is packaging. The substance is the agent living in my bar. Shipping Claubar alone today is more honest than teasing a distro that does not yet exist. The distro will be its own story when it is actually built.

Beyond the laptop

This is a personal project. It lives on my machine. It does not scale to a team in its current form.

But the principle does.

Inside organisations, configuration friction is a silent tax. New-hire onboarding takes days because the right environment has to be hand-built. Compliance configs drift, then need manual audits. Business users wait on IT tickets for small requests that one agent with the right permissions could resolve in minutes.

The pattern is the same. An always-on agent, given the right tools and the right scope, removes the gap between wanting to do a thing and doing the thing. I applied it to my laptop. The same shape applies to onboarding pipelines, compliance reviews, and internal tooling queues.

That is the bridge I am building: the space where operational transformation and AI agents are the same job, not two.