Avibe: A Local-First Agent OS That Puts Claude Code, Codex and OpenCode in Your Browser

The problem Avibe targets: a capable agent with no remote control

Claude Code, Codex and OpenCode are good at editing code inside a terminal. The README frames the consequence bluntly: the agent is trapped on one machine, out of reach when you leave the desk, and every competing tool wants to be the whole stack, with its own app, cloud and subscription. Avibe's answer is to keep the CLIs where they are and add a control plane around them. The audience is narrow and specific: developers who already pay for or run one of those three agents, keep their source on a personal workstation or a self-managed box, and want to check on a long-running task from a phone without tunneling a terminal. If you are happy inside tmux, Avibe adds a browser UI, a scheduler and a chat bridge you did not ask for.

How the Agent OS is put together: registry, sessions, harness

The repository layout separates concerns in a way that is worth reading before you install anything. core/, modules/ and vibe/ hold the Python side; ui/ is a React and Vite front end that the Dockerfile builds in a separate stage and copies into the Python image. The package name is avibe-os, and its dependencies list the claude-agent-sdk alongside Slack, Discord and Lark SDKs, FastAPI, SQLAlchemy and Alembic, which tells you the shape of the thing: a FastAPI service with a relational store and migrations, plus one adapter per chat platform.

The Agent registry is the central abstraction. Each registered Agent points at one of the three supported backends, and the README says you choose models and reasoning per Agent and share Skills across backends. Sessions are the unit of work, and background Sessions can be started by other Sessions. Open Runs and the README says you get a graph showing who started each background Session and where it reports back. That parent-child session model is the part most chat wrappers do not have, and it is the reason the project calls itself an OS rather than a bot.

The Agent Harness: run, schedule, watch and inspect

The README's claim is that most AI tools only act when you type, and Avibe adds durable primitives so an agent can start work, wait for a moment, run in the background and return with results. The four verbs are run, schedule, watch and inspect. Tasks and watches expose their trigger, the Agent and session they are bound to, delivery configuration and run history. One detail matters more than the rest: standalone definitions can intentionally omit a conversation delivery target. In practice that means a scheduled job does not have to post into a chat channel, which is the difference between a reminder bot and a scheduler you can point at real work.

The scheduling stack is visible in pyproject.toml, which depends on APScheduler. That is a reasonable choice for in-process cron-style jobs and a poor one for work that must survive a host restart, because APScheduler keeps its job store wherever you configure it. The README does not document how task state is persisted or what happens to a running background Session when the host reboots. Treat long unattended schedules as something to verify on your own deployment rather than something the documentation promises.

Installing Avibe and reaching the Workbench for the first time

The README gives a single install command and notes that the short URL is a 307 redirect to install.sh in the repository, so you can read the script before running it. The --launch flag starts the service and opens the browser.

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

After that the README says the browser opens and a short wizard walks you through setup, after which the machine is reachable as an Agent OS. On Windows the project does not recommend the PowerShell path for first use; the README points at docs/WINDOWS_WSL.md and recommends WSL for compatibility. There is an install.ps1 in the repository root, but the README's guidance is WSL.

If you prefer containers, the Dockerfile exposes port 5123 and sets AVIBE_HOME to /data/avibe, and the entrypoint is scripts/docker-entrypoint.sh. That ENV line is the one to plan around: it is where the container expects persistent state, so a container run without a volume mounted at /data/avibe will lose whatever lives there.

ENV AVIBE_HOME=/data/avibe
ENV PYTHONUNBUFFERED=1
EXPOSE 5123

For a source install, pyproject.toml requires Python 3.10 or newer, and the repository root carries main.py plus a uv.lock, so uv is the likely intended workflow even though the README does not spell it out.

Vaults, secrets and the part that is not shipped yet

Avibe's Vault stores secret values and, per the README, Vault responses never include the secret value itself; commands that receive a secret still have to avoid printing it. That last clause is the honest limitation. Redacting a value from an API response does not stop an agent from echoing it into a chat message, a log file or a Show Page, and the README puts the burden on the command rather than claiming to solve it.

The second tier, Protected, is described as passkey-gated custody that remains pre-launch until sandbox integrity work is complete. So the stronger isolation model is announced but not available. If your threat model requires that an agent cannot read a credential even when instructed to, Avibe in its current state is the wrong tool, and the README says as much by labelling Protected pre-launch.

Show Pages and the synchronous timeout the docs warn about

Show Pages let an agent hand back a live web page, such as a flowchart, dashboard, diff or small app, and you comment on an element or a screenshot so the agent can rework exactly where you pointed. In Chat, the Visualize button switches the session to its Show Page; hovering opens it in a new window or tab, dragging it downward places a new app window at the pointer, and dropping it on Apps pins the page to the Dock.

The README's pointer to docs/SHOW_PAGES.md mentions synchronous API timeout behavior and guidance for longer background refreshes. That is a real constraint rather than a footnote: a page that renders by calling a synchronous API will fail once the work behind it takes longer than the request budget, and the documented path is to move that work into a background refresh. If you plan to build Show Pages that query slow systems, budget for that split from the start.

Avibe compared with running Claude Code in a terminal multiplexer

The obvious alternative is tmux plus SSH, which is what most people already do. The difference is not convenience, it is state. tmux gives you a live terminal attached to a process, and if the process ends, the session is gone; there is no registry of Agents, no scheduled task with a run history, and no parent-child graph of background Sessions. Avibe keeps those as records in a database with Alembic migrations, which is why it can show you who started a background Session and where it reports back.

What you give up is directness. A tmux session is a shell you fully understand; Avibe is a FastAPI service, a React UI and a set of chat adapters, each of which can fail independently. The project itself is evidence of the trade: the README states it was developed end-to-end using Avibe, steering the three CLIs from a browser and a phone. That is a credible dogfooding claim, not a benchmark, and the README offers no latency, throughput or reliability numbers.

Maintenance, licence and what upgrading looks like

The repository is not archived and the last push was on 2026-09-10. The most recent releases are gh-v3.0.15rc8, gh-v3.0.15rc7 and gh-v3.0.15rc6, published on 2026-09-09, 2026-09-08 and 2026-09-07. Three release candidates inside three days is a fast cadence, and it also means the 3.0.15 line has not settled into a final release. pyproject.toml classifies the project as Development Status :: 4 - Beta, which matches what the release names suggest.

The licence is MIT, declared both in pyproject.toml and in the LICENSE file at the repository root. MIT is permissive: you can use, modify and redistribute the code, including in commercial settings, provided the copyright notice and permission notice are preserved. That is a summary of the licence text, not legal advice, and if Avibe becomes part of a product you ship, have counsel read the actual LICENSE file.

Upgrade cost is where the layout starts to matter. Versioning is dynamic through hatch-vcs, so the version is derived from git metadata rather than written down; the Dockerfile works around this by passing SETUPTOOLS_SCM_PRETEND_VERSION because .git is excluded from the build context. Schema changes go through Alembic, so an upgrade can require a migration against whatever database AVIBE_HOME points at. The README does not document rollback, and no downgrade path is described. Back up the data directory before pulling a new release candidate.

Editorial conclusion

Adopt Avibe if you already run Claude Code, Codex or OpenCode locally and want to reach those sessions from a browser or a chat app without moving your code to someone else's cloud. Do not adopt it if you need a stable, versioned product: the newest releases are 3.0.15 release candidates, the package is classified as Beta, and Protected Vault custody is described as pre-launch. Before installing, read install.sh and confirm what AVIBE_HOME will point at, because the Dockerfile sets it to /data/avibe and that is where persistent state will land.

Frequently asked questions

Official sources

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