advai-cli: managing skills, browser sessions and terminal AI chat from one CLI

What it pulls together

advai-cli puts four jobs behind one advai command. It inspects and updates its own installation, manages locally installed agent skills, drives browser automation through a Chrome extension, and runs a terminal chat interface against an OpenAI-compatible backend. The README describes a unified command-line interface with a lightweight Python-first core, where the npm and Homebrew routes exist for distribution rather than as separate implementations.

The audience is a developer who already uses several agent tools and wants one place to install skills, move them between platforms, and script a browser without standing up a full automation stack.

Three installers over one Python core

The requirement is Python 3.10 or newer. Node.js 14 or newer is needed only if you install through npm, and even then a local Python runtime is still required, because the npm package creates a private Python virtual environment during postinstall and installs the matching advai-cli version from PyPI into it. opencli is required only for external CLI discovery, install and passthrough execution. A compatible browser extension is required only for advai browser.

The architecture diagram in the README shows the three distribution channels, meaning the PyPI package, the npm wrapper and the Homebrew formula, converging on the same Python CLI core. That core branches into a local skills manager, a browser bridge, an OpenCLI bridge, a terminal TUI and runtime inspection. Skill state lives under ~/.advai/skills and browser bridge state under ~/.advai/browser.

Installing it and running a first session

From PyPI:

pip install advai-cli

From npm, for teams that prefer JavaScript distribution:

npm install -g advai-cli

From Homebrew on macOS:

brew tap Advai-X/tap
brew install advai-cli

The repository also carries a bootstrap script, ./install.sh.

Verify the install and inspect the runtime:

advai --help
advai info

The README lists advai info as the way to see the current installation, the runtime and the recommended update command, which pairs with advai update. AI access is configured with one environment variable:

export ADVAI_API_KEY=your_api_key

Then launch the terminal chat:

advai tui

The TUI takes a configurable model, base URL and system prompt, and can export the transcript.

The browser bridge and the extension it depends on

advai browser is the part with the most setup. It is a Chrome extension-backed automation layer for opening pages, executing JavaScript, waiting for selectors, interacting with inputs, reading network events and taking screenshots. advai-cli supplies the command surface, the browser bridge client and a built-in local daemon; a compatible browser extension supplies the live connection. Bridge state is stored under ~/.advai/browser, and the current release uses a fixed internal extension context for browser routing.

Setup runs in five steps: install the Chrome extension from the Chrome Web Store, make sure the local browser runtime is available, open the extension once in Chrome to finish first-run setup, sign in to any sites you want to automate inside that browser context, then run advai browser doctor to confirm the daemon and extension are reachable. If the daemon is not already running, browser commands can auto-start the built-in one.

advai browser doctor
advai browser open demo https://example.com
advai browser wait demo --selector "h1"
advai browser exec demo "document.title"
advai browser type demo "#search" "advai browser"
advai browser click demo "button[type=submit]"
advai browser screenshot demo --output page.png

The doctor line prints daemon status, the selected context and connected extensions. Passing --replace to advai browser open reuses the current tab instead of opening a new one, a flag added in v1.0.10.

Skills, sync targets and the skills.sh source

Skills are managed with install, list, info, update and uninstall commands, and installed skills can be synced into platform-specific agent directories such as Cursor, Claude Code, Codex and TRAE. The repository keeps sources under advai/skill_sources, with github.py, skills_sh.py, a registry and a base module, so the source model is pluggable rather than hardcoded.

Release v1.0.10, published on 2026-07-21, added provider-based skill installs and skills.sh support for discovery and installation:

advai skill search
advai skill list

The same release notes document URL installs, skills.sh owner/repo/skill specs, advai skill install with the --source skills_sh option, an API-first lookup with HTML fallback for skills.sh, and interactive disambiguation when a search returns several candidates.

Knowledge bases, external CLI passthrough and chat

Two more surfaces sit behind the same entrypoint. Knowledge bases can be created locally, filled with documents, searched, and resynced from source files. External CLIs are discovered and installed through the OpenCLI ecosystem and then proxied, so a supported third-party tool runs as advai cli followed by its name and arguments:

advai cli list

That command lists what is discoverable. opencli is only needed if you want discovery, installation or passthrough execution, so the rest of the tool works without it.

The TUI is the AI surface, and it talks to an OpenAI-compatible API. That is why the base URL is configurable and why ADVAI_API_KEY is the only credential the README mentions.

Where it is the wrong tool

The browser layer is the first constraint. This is not a headless automation framework: it needs a real browser, a specific Chrome extension installed from the Chrome Web Store, a first-run click inside that extension, and a local daemon, and the current release routes through a fixed internal extension context. On a server or in CI with no desktop browser, the browser commands have nothing to attach to.

The skill layer depends on where you want skills to land. Syncing into Cursor, Claude Code, Codex and TRAE directories makes the tool useful mainly if you use one of those. Otherwise it is a package manager for files nothing is consuming.

There is also a distribution wrinkle worth knowing before you pick a channel. Installing through npm still requires a local Python runtime, since the npm package builds its own virtual environment in postinstall. Choosing npm for a Python tool buys JavaScript-style distribution and nothing else.

Licence, dependencies and maintenance

The project is MIT licensed. The Python package is advai-cli version 1.0.12, requires Python 3.10 or newer, and declares two runtime dependencies: aiohttp 3.9 or newer and click 8.1 or newer. The npm package carries the same version, declares the advai binary at ./bin/advai.js, and runs ./bin/install-python.js as its postinstall hook.

The last push was on 2026-09-09. The three most recent releases, v1.0.10, v1.0.11 and v1.0.12, were published between 2026-07-21 and 2026-07-22, and the two later ones carry only a changelog comparison link rather than written release notes, so v1.0.10 is the last release that describes what actually changed.

Editorial conclusion

Adopt advai-cli if you already use Cursor, Claude Code, Codex or TRAE and want one command to install skills, sync them into those directories, and script a browser you are signed in to. Skip it if you need browser automation without a desktop browser and a Chrome extension, since the bridge needs both. Verify the bridge before you write any automation: run advai browser doctor, then advai info to see the runtime and the update command it recommends.

Frequently asked questions

Official sources

1. Advai-X/advai-cli on GitHub
2. License: MIT
3. Project website
4. README
5. Releases