AZET Desktop App vs CLI: Choosing Your Surface
Maker's note: 기준일 2026-10-03. This comparison stays inside what the AZET project README (version 0.3) states about each surface — including the things it explicitly does not claim.
One runtime, two surfaces
AZET 0.3 ships as a macOS app and a CLI sitting over the same runtime. Settings, profiles, credentials, and the usage ledger all live in one AZET data root, so these aren't two products — they're two ways of driving the same engine, and the differences come down to visibility and control.
What the desktop app is for
The Electron app bundles its own Chromium and Node.js, so it runs without a source checkout or separate installs. Its control surface covers the practical loop of running tasks: an isolated control screen, task input, session interrupt and resume, profiles, usage views, and settings.
Its defining trait is that it runs the real thing. The app executes the actual tabs you see and shares them with the runtime — when a task clicks, types, or extracts, it happens in a browser you can watch, not a hidden simulacrum of one. Window behavior is deliberate: the close button hides the process rather than killing it, the menu's Quit terminates fully, and a hidden browser quits on its own after 15 idle minutes. And the fence runs the right way: no app-control IPC and no Node API is exposed to web content.
What the CLI is for
bin/azet addresses the same engine from a terminal. The
packaged CLI keeps running even after the app is fully quit, on its
bundled Node runtime — though browser tasks still go through the app,
opened in hidden mode so the run uses the same profile's browser
storage. From source, the CLI can also run a standalone per-profile
Chromium (Google Chrome by default, overridable with
AZET_CHROME_PATH).
Beyond task runs, the CLI owns the long tail of the product: session
commands (list, resume, steer,
queue, stop), the persistent JavaScript REPL,
memory, skills, services, the usage ledger, remote host commands, and
updates.
Side by side
| Dimension | Desktop app | CLI |
|---|---|---|
| Primary interaction | Visual control screen, task input, session controls | Terminal commands and scripts |
| Browser visibility | Real tabs in a window you watch | Hidden-mode app; standalone Chromium from source |
| Runs when app is quit | Not applicable | Yes, on its bundled Node runtime |
| Session control | Interrupt and resume from the UI | session resume, steer, queue,
stop |
| Update scope | Replaced by a new desktop ZIP installer | azet update refreshes CLI runtime, libraries, skills,
native helper |
| Best fit | Watching runs, managing profiles visually | Scripting, REPL work, living in the terminal |
What neither surface verifies for you
This section matters as much as the comparison. The README separates implemented scope from operational activation conditions in a completion matrix, and states that even features with execution records are verified only up to that record's source version and observation date. Across both surfaces, the project does not mark these complete: real paid payment flows, real hosted text-model calls, Apple notarization, and sends or edits performed on personal service accounts.
A few more precise boundaries. The desktop package is ad-hoc signed — not Developer ID, not notarized — so macOS first-run security steps remain, and full Intel desktop execution is not claimed. The app is not an operating-system sandbox isolating malicious code running as the same local user. And neither surface owns your AI provider logins: official Claude and Codex CLIs — bring your own — with their existing logins are required separately. AZET verifies their authentication state and models without copying credentials or performing the provider login for you.
Choosing
If your work is watching a browser do things and stepping in — a run paused mid-form, a profile switched by eye — the app is the surface built for that. If your work is composed of commands, scripts, and REPL experiments, the CLI is the natural home, and its session commands give you the same interrupt-and-resume control in text form.
Because profiles, credentials, and the ledger are shared, the honest answer is that most people end up using both: the app for visibility, the CLI for reach. Picking one to start with is fine; treating them as rivals would be a category error.
If you want to follow the project and the azet.io portal as they come together, the waitlist at https://azet.io is open — and whichever surface you prefer, we'd rather you arrive knowing exactly what each one does and doesn't claim.
FAQ
Are the desktop app and the CLI two different products? No. They're two surfaces over one runtime — settings, profiles, credentials, and the usage ledger all live in a single AZET data root, so work done in one shows up in the other.
Do I have to pick one surface and stay there? No, and treating them as rivals would be a category error. The app is built for watching runs and managing profiles visually; the CLI owns scripting, the REPL, and the long tail of session, memory, and skills commands. Most people end up using both.
What happens to browser tasks when the app is fully quit? The CLI keeps running on its bundled Node runtime, but browser tasks still route through the app — it opens in hidden mode so the run uses the same profile's browser storage, and opening the GUI shows the window again.
Does either surface log me into my AI providers? No. AZET works with the official Claude and Codex CLIs you bring, already logged in. It verifies their authentication state and models without copying credentials or performing the provider login for you.