AionUi made the smartest decision I’ve seen in the AI assistant space this year: it wraps the CLI AI agents you use instead of reinventing them. Claude Code, OpenCode, Gemini CLI, Goose — it auto-detects what’s installed and gives you a unified GUI while leaving the agent logic alone. That respect for the ecosystem is why it’s now the interface layer of my local-AI stack.
This is Part 5 of 6 in the Building a Private Local-AI Stack series.
- The Use Case
- LightRAG as a Personal Knowledge Base
- OpenRouter and the Case for Safe Models
- Right-Sizing a Local LLM with llmfit
- AionUi: A GUI for Your CLI AI Agents (this post)
- Basic Memory: An AI Memory in My Obsidian Vault
What AionUi Actually Is
AionUi is an open-source Electron app — they call it a “Cowork” app — that auto-detects the CLI AI agents on your machine and drives them through a unified interface. It supports Claude Code, Codex, Gemini CLI, OpenCode, Goose, and twenty-odd others. It also ships its own built-in agent powered by an aioncore/aionrs engine, but that’s not the point. The point is federation: you already have CLI agents you trust, and AionUi orchestrates them instead of asking you to throw them away.
The GUI gives you what you’d expect from a desktop AI assistant: a conversation pane, file management, a diff viewer for proposed changes, and support for MCP (Model Context Protocol) servers so you can extend the agents with your own tools. But the architectural bet underneath is the interesting part: AionUi treats CLI agents as first-class components — wraps them, doesn’t rebuild their logic, doesn’t fork their codebases.
Most tools in this space either ignore the CLI agent ecosystem entirely or try to reimplement the agent from scratch — reinventing every bug, edge case, and integration the CLI projects have solved. AionUi detects what you’ve installed, lets you pick one, and drives it. You get the maturity of an established CLI with the convenience of a GUI, and you’re not locked into AionUi’s own engine if their roadmap diverges.
Why Wrapping Beats Reinventing
The CLI agents are good — battle-tested, rich ecosystems of plugins, MCP servers, integrations. Reinventing that for the sake of a GUI is waste. You end up with version 0.1 of something that exists at version 3.0 elsewhere.
AionUi’s bet is that the value is in orchestration, not owning the agent. A GUI that can team up multiple agents — one for code generation, another for natural-language reasoning — adds capability you can’t get from any single CLI. File management, diff previews, persistent chat history are what a GUI does better. Multi-agent coordination is new ground. And by not owning the agent, AionUi inherits every improvement those CLI projects ship upstream. If OpenCode adds a feature I care about, I get it the moment I upgrade OpenCode.
When a vendor owns the whole agent stack, every feature request becomes a prioritization fight, and you’re stuck waiting for them to port a capability you could have had yesterday if the tool just let you use the CLI agent that already has it. AionUi sidesteps that. The GUI is the interface layer. The CLI agents are the engines. Both can evolve independently.
MCP Servers and the Node ABI Gotcha
AionUi supports importing MCP servers — the same Model Context Protocol servers I use with my CLI agents. I imported basic-memory, brave-search, context7, telegram, google-tasks, and a handful of others. Once imported, the GUI agents have access to the same tools. AionUi isn’t operating in a vacuum — it’s tapping into the extension ecosystem I’ve built over months.
The gotcha: AionUi ships its own bundled Node runtime (version 24.11.0 at the time of writing), and if an MCP server is a native Node module — compiled C++ bindings — built against your system Node, it crashes on load because the ABI versions don’t match. Node’s N-API has ABI compatibility rules, and when the system Node ABI doesn’t match AionUi’s bundled Node ABI, the native module crashes. You get a silent failure or a cryptic SIGSEGV, and the MCP server never appears in AionUi’s server list.
The fix: for any native-module MCP server, point its launcher script at the absolute path of your system node binary instead of letting it find node on the PATH (which resolves to AionUi’s bundled version when running inside the app). That forces the server to run with the Node ABI it was compiled against, and the crash disappears. Not an AionUi bug — just the reality of bundling a runtime — but it cost me an afternoon and will trip up anyone else trying this on Linux.
Telegram: The Standout Feature
The Telegram integration is what made AionUi useful in a way I didn’t expect. I imported a telegram MCP server I’d already built, connected to a Telegram bot, and the entire stack became something I could drive from my phone — from anywhere. I send a message to the bot, it routes through AionUi, which hands it to whichever agent I’ve configured (OpenCode, Claude Code, the built-in agent). That agent runs on my local machine with access to LightRAG, my documents, my MCP servers — the works. The reply comes back through Telegram, wherever I am.
The local-AI stack went from desk-bound to reachable 24/7. I can triage email, query my knowledge base, kick off a batch job from a train platform. The agent still runs on my hardware, still has access to my local documents, still respects the sensitivity boundary from the rest of this series — it’s just reachable without me being at the machine. For a stack built around automation, that accessibility matters. The Telegram integration works — it’s the standout feature I use daily.
The Honest Gripes
AionUi is a great idea with rough edges — two bit me and will bite you.
No official Fedora package. AionUi ships binaries for major platforms, but Fedora (my daily driver) isn’t one of them. The project has an AppImage, which runs anywhere, but AppImages are second-class citizens on Fedora: no system integration, no proper desktop file registration unless you jump through hoops, and they don’t play nicely with distro updates. I wanted a real RPM.
So I built one. I forked the repo, created a feat/fedora-rpm-build branch, and added a bun run build-rpm target that produces a proper installable RPM artifact. It works — I’m running it now — but this was DIY. Linux packaging for AionUi is not polished yet. If you’re on anything other than Ubuntu or a Debian derivative, expect to either live with the AppImage or roll your own package. Not a dealbreaker, but not smooth.
Memory and disk footprint. AionUi is Electron — bundling Chromium, Node, the aioncore agent engine, extensions, and everything else into a single artifact. The Linux build alone is roughly 330 MB compressed, and the unpacked installation is larger. It’s not light on RAM at runtime either — expect a few hundred megabytes just for the GUI process, before you start an agent session.
This is the Electron tax. For a desktop tool you leave running, it’s acceptable — but it’s not light. If you’re on a machine where RAM is precious or disk is tight, AionUi will be a noticeable presence. Frame this as “the trade-off for not maintaining separate native builds on five platforms,” and it makes sense — still a trade-off.
Where It Fits
AionUi is the interface layer of my private local-AI stack — sitting on top of everything I built in the first four parts (LightRAG, OpenRouter, the local LLM, the whole sensitivity boundary) and giving me a unified place to drive the agents that orchestrate all of it.
I recommend it if you live in CLI AI agents and want a GUI plus remote access without giving up the tools you’ve built around those agents. If you’re starting from scratch with no existing CLI agent investment, AionUi’s value is less obvious — you’d be using it to wrap agents you haven’t chosen yet, which is backwards. But if you run OpenCode or Claude Code daily, have a pile of MCP servers you’ve written or imported, and you want to drive it all from a GUI or your phone, AionUi delivers that without asking you to rewrite your stack.
It’s not perfect — Linux packaging situation is frustrating, and the Electron footprint is real. But the core idea (wrap, don’t reinvent) is sound, and the Telegram integration alone justifies its place in the stack. Leaving my desk, sending a message to a bot, and having my own agents running on my own hardware with my own tools answer me from anywhere is the kind of accessibility automation should unlock.
That’s the full stack: a knowledge base that remembers, safe cloud models for the non-sensitive work, a right-sized local model for the private work, and a GUI that wraps the agents that tie it all together — without forcing me to abandon the ecosystem I’ve invested in.
Any opinions in this article are my own. AionUi is open-source (https://github.com/iOfficeAI/AionUi) and actively developed.