Avibe: A Local-First Control Plane for Claude Code, Codex and OpenCode

The problem Avibe targets: agent CLIs that die with the terminal

Claude Code, Codex and OpenCode each run as a command line tool on one machine. The README frames the consequence bluntly: the agent is "trapped on one machine", and closing the laptop stops it. Away from the desk you cannot see what it is doing or steer it. The third complaint is lock-in, phrased as every tool wanting to be the whole stack with its app, its cloud, its subscription and your code uploaded elsewhere.

Avibe's answer is to keep the official CLIs in place and put a control plane around them. The project describes itself as a local-first Agent OS, and the README claims avibe.bot never sees your data. That is the audience filter: people who already trust these CLIs with a repository and want remote reach without adopting a new hosted agent runtime. It is not a replacement for the CLIs and it does not reimplement them.

One Agent registry in front of three different CLIs

The mechanism the README is most explicit about is the Agent registry. Official Claude Code, Codex and OpenCode CLIs run behind one registry, and you choose models and reasoning per Agent. The registry also routes projects to a particular specialist, and Skills are described as reusable and shared across backends.

That last point matters more than it looks. If Skills are genuinely shared across three backends with different tool-calling conventions, the registry is doing translation work rather than just storing a command line per Agent. The README does not explain how that translation is implemented, so treat shared Skills as a documented claim rather than a verified one. The Runs view shows collaboration as a graph: which parent Session started each background Session, where it reports back, and the execution history behind each node. That graph is the part of the design that distinguishes Avibe from a single-session chat wrapper.

The Agent Harness: run, schedule, watch, inspect

Most chat interfaces only act when you type. Avibe gives the agent what the README calls durable primitives: run, schedule, watch and inspect. A task or watch detail exposes its trigger, the Agent and session it is bound to, its delivery configuration, and its run history. The README notes that standalone definitions can intentionally omit a conversation delivery target, which implies a task can exist without reporting into a chat thread.

This is the design decision worth arguing about. Persisting schedules and watches means state survives restarts, which is what makes background work plausible. It also means the agent can start work you did not ask for at the moment it fires. The README documents the shape of a task definition but not the failure semantics: what happens to a scheduled run when the machine is asleep, or when the bound session no longer exists. Those are the questions to answer from the source before relying on the Harness for anything that touches a production repository.

Installation is one command, and the wizard does the rest

The README gives a single install invocation:

bash -o pipefail -c 'curl -fsSL https://avibe.bot/install.sh | bash -s -- --launch'

The pipefail flag makes the pipeline fail if the download fails, and --launch opens the browser after installation. The README states the short URL is a 307 redirect to install.sh in the repository, and invites you to read that script first. Do that. Piping a remote script into bash is the standard shortcut for this class of tool, and the only mitigation offered here is that the script is public and MIT-licensed.

After the browser opens, a short wizard runs and the machine becomes an Agent OS. Python 3.9 or above is the stated requirement. On Windows the README recommends WSL and points to docs/WINDOWS_WSL.md, which covers where to install WSL, which terminal to use, where to run the install command, and how to open the Web UI. The README does not list the config keys the wizard writes or the file paths it uses, so plan to inspect the generated configuration rather than assume it.

Vaults, Show Pages and the limits the README admits

Vaults are the secret-handling feature. You add a Standard secret once and approve Agent requests from the browser. The README makes a precise claim: Vault responses never include the secret value. It then adds the caveat that commands receiving the secret must still avoid printing it. That is an honest boundary. The Vault stops the secret from travelling back through the API, and it does not stop a command from echoing it into a log.

Protected, passkey-gated custody is described as pre-launch until sandbox integrity work is complete, so the stronger custody tier is not available now. The README does not state how the browser session or the chat transports are authenticated, which is the largest gap for a tool whose whole premise is reaching a machine from anywhere. Show Pages have a documented constraint of their own: the README points to docs/SHOW_PAGES.md for synchronous API timeout behaviour and guidance on longer background refreshes, which implies long-running page generation can time out and needs a different pattern.

How Avibe differs from a hosted agent platform

The obvious alternative is a hosted agent service that runs the model and the tools on the vendor's infrastructure and gives you a web UI. The difference is where execution and credentials live. In a hosted platform the repository is uploaded, the API keys sit with the vendor, and the session runs in their sandbox. Avibe inverts that: the CLIs execute on your machine, the keys stay with you, and the browser or chat app is only a control surface. The trade is operational. You supply the machine, the uptime, and the patching, and you own the exposure of whatever endpoint the browser and chat integrations connect to.

A second alternative is simply running the CLIs over SSH with tmux. That keeps everything local and adds no new component, and it fails at the specific thing Avibe is built for: reaching a running session from a phone through Slack, Discord, Telegram, WeChat or Lark. If your work never leaves the desk, SSH is fewer moving parts. If you want to approve a Vault request or comment on a Show Page from a phone, Avibe is addressing a gap SSH does not.

Release cadence, licence and what to verify before adopting

The repository is MIT-licensed and not archived, which permits commercial use and modification. The last push recorded is 2026-09-10, and the three most recent releases are all release candidates: gh-v3.0.15rc8, rc7 and rc6, published on consecutive days in September 2026. A rapid RC sequence on the default branch master means fixes are landing quickly and that master is not a stability guarantee. Pin a tag if you deploy this.

Upgrade cost is the part the material does not answer. The README does not describe a migration path between versions or state whether the install script upgrades an existing installation in place. Verify that from install.sh before you rely on the one-liner a second time. The same applies to uninstall: nothing in the README says how to remove the service or what it leaves behind. Those two gaps, not any feature, are what determine whether Avibe is cheap or expensive to keep running.

Editorial conclusion

Avibe is aimed at individual engineers or small teams who already run Claude Code, Codex or OpenCode locally and want to reach those same sessions from a browser or a phone without moving code and API keys to a hosted agent service. It is the wrong tool for anyone who needs a documented, auditable remote-access security model today, since the README does not state how the browser and chat transports are authenticated, and for anyone who cannot run WSL or a Linux-like environment. Before adopting it, read install.sh and docs/WINDOWS_WSL.md, confirm what the install wizard writes to disk, and check whether the Vault's Standard secret handling meets your own policy on secret exposure. Then pin a release tag rather than tracking master, because the project is still shipping release candidates.

Official sources

1. avibe-bot/avibe on GitHub
2. License: MIT
3. Project website
4. README
5. Releases