AionUi: a local Cowork app that puts CLI agents behind a desktop UI

The problem AionUi solves: many CLI agents, no shared cockpit

Command-line coding agents are individually usable and collectively annoying. Each one has its own invocation, its own configuration file, its own way of reporting progress, and none of them know about the others. If you want a scheduled task to run at night, you write a cron entry and hope the output is somewhere you can find it in the morning.

AionUi's answer is to treat those agents as backends behind one interface. The README describes it as "more than a chat client" and a "Cowork platform where AI agents work alongside you on your computer", listing Claude Code, Codex, Qwen Code, Hermes Agent and Cursor Agent among the external agents it can host. The audience is therefore narrow and specific: developers who already pay for or run at least one CLI agent, and who want file access, multi-step execution and remote monitoring without assembling a dashboard.

The second audience is less technical. AionUi ships 21 built-in assistants, including PPT Creator, Word Creator, Excel Creator, Pitch Deck Creator and Financial Model Creator, aimed at people who want document output rather than code. Those two audiences share an interface but not much else, which is worth keeping in mind when reading the feature list.

Built-in agent engine versus external CLI agents

There are two distinct execution paths in AionUi, and the README does not always separate them clearly.

The first is the built-in agent. The README states it ships with a complete agent engine, so "AionUi works the moment you install it", with no CLI tools to install and any API key accepted to get started. Capabilities listed include file read/write, web search, image generation and MCP (Model Context Protocol) tools. This path is self-contained: the app is the agent.

The second path wraps external CLI agents. Here AionUi is a front end, and the actual work happens in a process you installed separately. That distinction matters operationally. A built-in agent fails when your API key is wrong; an external agent fails when the binary is missing, the version drifts, or its own configuration is stale. The README's comparison table claims dozens of external agents in "one unified interface", but it does not document what happens when an external agent is absent or exits non-zero.

The repository layout supports the wrapper reading. Top-level entries include .claude/ and .gemini/ directories alongside a packages/ workspace and an examples/ directory containing acp-adapter-extension, ext-feishu and ext-wecom-bot. The ACP adapter example suggests an extension point for adapting other agent protocols, though the README does not document that interface.

Installing AionUi and running a first task

The README points to the GitHub releases page for downloads, and the repository ships install scripts under homebrew/ and a Dockerfile for a server deployment. For a source checkout, the justfile exposes the development entry points.

The justfile defines dev as bun run start, which launches the Electron app with Vite hot reload:

just dev

You should see the Electron window open. The preflight recipe checks prerequisites and warns if Node.js is below version 22, so run it first if the build fails:

just preflight

For a browser-based deployment instead of a desktop window, the Dockerfile builds a runtime image that serves the WebUI. It sets PORT to 3000 and ALLOW_REMOTE to true, and declares /data as a volume for the SQLite database:

docker build -t aionui .
docker run -p 3000:3000 -v $(pwd)/data:/data aionui

The container command is bun dist-server/server.mjs. The Dockerfile installs libicu-dev in the runtime stage because the Office preview component is a .NET binary that aborts without ICU, which is a concrete hint that the document assistants are not optional extras in the server image.

To run the WebUI directly from a checkout without Docker, the package scripts provide webui and webui:prod, with --remote variants that map to the justfile recipes webui-remote and webui-prod. The README does not document authentication for the remote mode beyond the existence of a resetpass script.

Cron, remote access and the 24/7 claim

The feature that separates AionUi from a chat window is scheduled automation. The README's comparison table lists "Scheduled automation" as "Cron, 24/7 unattended", and the project describes itself as a 24/7 Cowork app. Remote access is offered through a WebUI plus Telegram, Lark, DingTalk and WeChat.

Combining those two is where the design gets interesting and where the documentation gets thin. An unattended agent with full file access, reachable from a phone, is a different risk profile from an interactive one. The Dockerfile sets ALLOW_REMOTE=true by default, which means the container is built to accept remote connections out of the box. Nothing in the README excerpt explains what protects that endpoint, how sessions are scoped, or what a cron job is allowed to touch.

The examples/ directory contains ext-feishu and ext-wecom-bot, so the chat-platform integrations appear to be extensions rather than core code. That is a reasonable structure, but it also means the reliability of a Telegram or WeChat bridge depends on an extension you may have to maintain yourself.

Where AionUi is the wrong tool

If your workflow is one agent, one terminal and one repository, AionUi adds an Electron runtime, a workspace of packages, a SQLite database and a build toolchain for no benefit you will notice. The built-in agent's value proposition is that it works immediately; if you already have a CLI agent configured the way you like, the GUI is a layer between you and it.

The second limitation is version coupling. AionUi wraps external agents whose interfaces change on their own schedule. The README does not document a compatibility matrix, so a working setup can break when you update Claude Code, Codex or Gemini CLI rather than when you update AionUi. The release cadence is brisk (v2.1.61, v2.2.1 and v2.2.2 within roughly two weeks), which suggests fast iteration rather than a frozen interface.

Third, the document assistants produce .pptx, .docx and .xlsx files through a separate project, OfficeCLI, and the README links its canonical catalog to a different repository, AionCore. If your interest is the Office output rather than the agent orchestration, you are depending on two projects and the integration between them, and the README does not describe what happens when OfficeCLI is unavailable.

AionUi versus Claude Cowork and plain terminal wrappers

The README positions AionUi directly against "Claude Cowork", and the search data shows people comparing the two. The difference in approach is scope. Claude Cowork is tied to one vendor's models and one vendor's agent; AionUi's premise is that the agent is interchangeable. The README's table lists dozens of external agents and states "Any API Key", which is the whole argument: you keep your existing subscriptions and swap the backend instead of the interface.

The cost of that flexibility is integration depth. A single-vendor Cowork product can assume capabilities that a generic wrapper cannot, because it controls both halves. AionUi has to work with agents that expose different tool sets, different permission models and different output formats. The ACP adapter example in examples/acp-adapter-extension suggests the project is aware of this and provides an adaptation layer, but the README excerpt does not document its contract.

A plain terminal multiplexer or a shell script that pipes agent output into a log file is the other alternative, and for scheduled jobs it is genuinely competitive. What it does not give you is the phone-facing WebUI, the assistant presets, or a single place where several agents' runs are visible together.

Licence, maintenance and upgrade cost

AionUi is licensed under Apache-2.0, and package.json carries the same identifier. That is a permissive licence with an explicit patent grant, which matters if you intend to embed or redistribute the app. Apache-2.0 also requires that you preserve notices and state changes you make. This is not legal advice; if you plan to ship AionUi inside a product, have someone qualified read the licence and check the licences of the bundled assistants, skills and the OfficeCLI dependency, which are separate repositories.

Maintenance is real but not dormant. The repository is not archived, and the last push was on 2026-09-09, matching the v2.2.2 release on the same date. Releases v2.1.61, v2.2.1 and v2.2.2 landed between 2026-08-25 and 2026-09-09. Three releases in about two weeks implies active development, and also implies that pinning a version is the sane approach for anything scheduled.

The upgrade cost sits in three places: the Electron app itself, the external CLI agents it wraps, and the /data volume holding SQLite state. The Dockerfile declares that volume, so a container upgrade that recreates it without a backup loses your configuration and scheduled jobs. The repository provides a resetpass script for credentials but the README does not document rollback or migration between versions.

Editorial conclusion

Adopt AionUi if you already run one or more CLI agents and want a single window, scheduled runs and phone access without building that plumbing yourself. Skip it if you only need one agent in one terminal, or if you cannot accept untested upstream releases against a young codebase. Before committing, verify that your chosen agent is in the supported list, that the WebUI binds the way you expect under ALLOW_REMOTE, and how the /data volume is backed up, because SQLite state and cron jobs live there.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes