OpenCLI: A Command Line Front End for Your Logged-In Chrome Session

What OpenCLI Actually Solves

The project bundles three distinct capabilities under one command. First, built-in adapters for sites like Bilibili, Zhihu, Xiaohongshu, Reddit, HackerNews, Twitter/X. Second, a browser skill that lets AI agents operate any page through your logged-in Chrome. Third, a way to write your own adapters end-to-end. It also acts as a CLI hub for local binaries like `gh`, `docker`, and `tg`. That breadth is both the appeal and the risk: you get one tool for many jobs, but each job has its own failure modes.

The Architecture: Browser Bridge, Daemon, and DOM Snapshots

OpenCLI's mechanism is visible in the setup steps. It connects to Chrome through a Browser Bridge extension plus a small local daemon that auto-starts when needed. The extension, installed from the Chrome Web Store or loaded unpacked, is what gives OpenCLI access to your logged-in session. The daemon likely communicates with the extension over a local channel, and the `opencli` command talks to the daemon. The README stresses that the agent reads page content via structured DOM snapshots, not screenshots. That is a deliberate design choice. Screenshots require vision models and are fragile; DOM snapshots are text and can be fed directly into an LLM's context window. The trade-off is that DOM snapshots fail on canvas-rendered content or pages that rely heavily on shadow DOM, though the README does not mention those limits. The `opencli browser` primitives let an agent navigate, click, type, extract, and wait for elements or page transitions. The agent handles those commands internally, so the human only describes the goal in natural language.

Installation and First Commands: Real Steps from the README

The README gives two installation paths. For desktop use on macOS or Windows, the recommended route is OpenCLIApp, downloaded from opencli.info/download. That app bundles the runtime, keeps the `opencli` command installed, and adds a system tray UI for setup, diagnostics, and updates. For CLI-only use, CI, or servers, you install via npm: `npm install -g @jackwener/opencli`. The npm path requires Node.js >= 20.18.1, so check `node --version` first. After installation, you need the Browser Bridge extension. The recommended path is the Chrome Web Store listing, but there is a manual fallback: download the extension zip from GitHub Releases, unzip it, open `chrome://extensions`, enable Developer mode, and load the unpacked folder. Then run `opencli doctor` to verify connectivity. The README also covers multi-profile handling: `opencli profile list`, `opencli profile rename <contextId> work`, and `opencli profile use work`. If you have multiple connected profiles and no default, OpenCLI asks you to choose rather than guessing. That is a sensible safety measure, but it means your automation scripts must set a profile explicitly or they will stall on a prompt.

The Skill System: How AI Agents Get Their Instructions

The AI agent integration relies on a set of skills installed via `npx skills add jackwener/opencli`. The README lists six skills: `opencli-adapter-author`, `opencli-autofix`, `opencli-browser`, `opencli-browser-sitemap`, `opencli-sitemap-author`, and `opencli-usage`. Each skill maps to a different task. `opencli-browser` is the core one for ad-hoc driving of a page. `opencli-adapter-author` guides writing a reusable adapter for a new site. `opencli-autofix` repairs a broken adapter when a built-in command returns empty. The sitemap skills let an agent consume site sitemap context to avoid blind clicking. This is a thoughtful split: the browser skill handles the generic case, while the sitemap and author skills handle the long tail of site-specific quirks. The system is designed so the agent, not the human, invokes the `opencli browser` commands. The human just says something like "Help me check my Xiaohongshu notifications." That division of labor is practical, but it also means the quality of the result depends heavily on the agent's ability to follow the skill instructions. If the agent misuses the primitives, you get the same kind of flaky automation that OpenCLI claims to avoid.

Extending OpenCLI: Adapters, Plugins, and Ejected Commands

OpenCLI provides several extension paths, each with a different scope. For personal website commands kept in your own Git repo, the README suggests `opencli plugin create` followed by `opencli plugin install file://...`. For a quick private draft, you can run `opencli browser init <site>/<command>` inside `~/.opencli/clis/`. To modify an official adapter, you eject it with `opencli adapter eject <site>` and later reset it with `opencli adapter reset <site>`. Third-party commands install via `opencli plugin install github:user/repo`. Local binaries register with `opencli external register <name>`. The eject/reset cycle is a notable design point: it acknowledges that official adapters will break when sites change, and gives you a way to patch them locally without forking the whole project. But ejected adapters become your responsibility. When the site markup changes again, you own the fix. The README points to a separate guide for the directory layout and source-control model, which suggests the extension system is non-trivial and not fully documented in the main README.

Limitations and Failure Modes

The most obvious limitation is the hard dependency on a live Chrome session. OpenCLI is not a headless scraper. It needs the Browser Bridge extension installed and a Chrome profile connected. If you run it in a CI environment without a display, you will need to arrange for a Chrome instance with the extension loaded, which is a significant operational burden. The README explicitly positions the npm install as suitable for CI and servers, but it does not explain how to run Chrome in that context. A second limitation is the adapter fragility. The README includes `opencli-autofix` as a skill for repairing broken adapters, which is an admission that built-in commands will fail. When a site changes its HTML structure or API responses, the adapter breaks. The autofix skill presumably helps, but it still requires an agent to diagnose and patch the adapter. A third limitation is the multi-profile ambiguity. With multiple Chrome profiles connected and no default, OpenCLI asks you to choose. That is safe, but it breaks unattended automation unless you explicitly set a profile. Finally, DOM snapshots will not work on sites that render content in canvas or rely on complex shadow DOM; the README does not address those cases.

Alternatives: Browser Use and Site-Specific Scrapers

The README itself mentions "Browser Use" as a concept, and there is a separate open-source project called Browser Use that provides a Python library for AI agents to control a browser. The difference in approach is significant. Browser Use typically runs its own browser instance, often headless or with a dedicated profile, and it uses computer vision or DOM extraction depending on the configuration. OpenCLI instead insists on your logged-in Chrome and uses DOM snapshots exclusively. That means OpenCLI can access sites that require your existing authentication, while Browser Use would need you to handle login separately. On the other hand, Browser Use is a general-purpose library with a larger ecosystem of integrations, whereas OpenCLI is a self-contained CLI with its own skill system. For simple site-specific tasks, a dedicated scraper like `youtube-dl` or a custom script using `curl` and `jq` might be lighter than installing OpenCLI and running a Chrome extension. OpenCLI's value only appears when you want a uniform interface across many sites or when you want your AI agent to act on your behalf in a real browser session.

Maintenance and License

The repository is licensed under Apache-2.0, which means you can use, modify, and distribute it, including for commercial purposes, as long as you preserve the license notice and state changes. The project is not archived, and the last push was August 2026 with a recent release v1.8.7. That suggests active maintenance, but the maintenance burden is uneven. The core CLI and adapter system need updates to keep up with Node.js and Chrome changes. The browser extension must track Chrome's extension API changes. The built-in adapters must track each site's markup. The README's own `opencli-autofix` skill is a response to that ongoing cost. Upgrading OpenCLI is not a one-time event; it is a recurring chore for anyone relying on the built-in adapters. The npm package is named `@jackwener/opencli`, and the extension has its own release line (`ext-v1.0.21`), so you have two components to keep in sync. Verify the extension version matches the CLI version before assuming a feature works.

Editorial conclusion

Adopt OpenCLI if you want a deterministic, scriptable interface for sites you already log into, or if your AI agent needs a browser bridge that uses your existing session instead of a separate automation profile. Skip it if you need headless scraping at scale, because the project explicitly depends on a live Chrome profile and a browser extension. Before adopting, verify your Node.js version is at least 20.18.1, confirm the Chrome Web Store extension works with your Chrome channel, and check whether the built-in adapters cover the sites you actually use. The project is Apache-2.0 licensed, so you can fork it, but the maintenance cost depends on the browser extension staying compatible with Chrome updates and on the adapter set staying current with site markup changes.

Official sources

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