OpenCLI: turning logged-in websites into commands and adapters

The gap OpenCLI fills between a browser session and a shell

Most automation tools force a choice. Either you write a scraper that has to re-authenticate and re-derive page structure, or you keep a browser open and click through it by hand. OpenCLI takes a third position: it treats the browser you are already logged into as the execution environment, and wraps it in commands. The README describes the goal as turning websites, browser sessions, Electron apps, and local tools into deterministic interfaces for humans and AI agents. The audience is narrow but real. People who already run gh, docker or a local CLI and want the same ergonomics for a website. People who want an agent to fill a form or read a notification page using their existing session rather than a fresh login.

The project also positions itself as a hub. The README lists local tools such as gh, docker, longbridge, tg, discord, wx and ntn (Notion) that can be registered, plus desktop app adapters for Electron apps including Cursor, Trae CN, Codex, Antigravity, ChatGPT and Trae SOLO. That breadth is the interesting part and also the risk: every adapter is a surface that can break when the site or app changes.

How the browser bridge, daemon and adapters fit together

The architecture has three moving parts. A CLI installed through npm, a Browser Bridge extension loaded into Chrome or Chromium, and a small local daemon that the README says auto-starts when needed. The CLI does not talk to the page directly. It goes through the extension, which acts on the tabs in your logged-in profile. That is why the setup asks you to install an extension at all rather than just authenticate with cookies.

Above that transport layer sit two kinds of commands. Built-in adapters exist for sites such as Bilibili, Zhihu, Xiaohongshu, Reddit, HackerNews and Twitter/X, and the README points to a longer built-in command list. Generated adapters are the ones you or an agent write. The browser primitives are the lower-level layer that agents use: navigate, read page content through structured DOM snapshots rather than screenshots, click, fill forms, select options, press keys, extract data or intercept network API responses, and wait for elements, text or page transitions. The README is explicit that these browser commands are designed to be used by AI agents rather than run manually, which is a design statement worth taking at face value.

Profile handling is the detail that decides whether multi-profile setups work. Each Chrome profile runs its own OpenCLI extension instance. With one connected profile OpenCLI uses it automatically. With several connected profiles and no default, the README says OpenCLI asks you to choose instead of guessing. That is a sensible failure mode, and it is the opposite of the silent wrong-account behaviour you get from tools that just pick the first cookie jar they find.

Installing OpenCLI and running a first command

There are two install paths. The desktop app, OpenCLIApp, is recommended for macOS and Windows: download it from the project's download page, install it, open it once, then use its System page to install or repair the opencli command. The npm path is for CLI-only use, CI and servers, and it requires Node.js >= 20.18.1. Check the version before installing, because the engine constraint is enforced by the package manifest.

node --version
npm install -g @jackwener/opencli

After that, the extension has to be in place. The recommended route is the Chrome Web Store listing. The manual route is to download the latest opencli-extension-v{version}.zip from the releases page, unzip it, open chrome://extensions, enable Developer mode, click Load unpacked and select the unzipped folder. Either way, the CLI is useless until the extension is connected.

The verification step is a single command, and it is the one to run before anything else.

opencli doctor

If you use more than one Chrome profile, name them so you do not have to guess which one is being driven. The README gives this sequence, and the last line shows the --profile flag in use against a browser command.

opencli profile list
opencli profile rename <contextId> work
opencli profile use work
opencli --profile work browser main state

With the bridge up, discovery and a first real command are short. The README's own examples use HackerNews and Bilibili.

opencli list
opencli hackernews top --limit 5
opencli bilibili hot --limit 5

opencli list shows every registered command, which is the fastest way to see whether the site you care about already has an adapter. If it does not, the extending guide is where the README sends you for directory layout and install commands.

Writing adapters, plugins and wrapping local binaries

The README keeps extension short and pushes detail into a separate guide, but the table it does provide is the most useful part of the document because it maps intent to command. If you want personal website commands in your own Git repository, the path is opencli plugin create plus opencli plugin install file://... If you want to draft a private local adapter quickly, run opencli browser init <site>/<command> inside ~/.opencli/clis/. If you need to modify an official adapter locally, the pair is opencli adapter eject <site> followed by opencli adapter reset <site>. Third-party commands install with opencli plugin install github:user/repo. Wrapping an existing binary is opencli external register <name>, which is also how the CLI hub story works for gh, docker and the rest.

That eject and reset pair deserves attention. Ejecting an official adapter gives you a local copy you can edit, and reset restores the official version. It is a clean way to test a fix without forking the project, but it also means your local edits live outside version control unless you move them. The README does not describe how to upstream an ejected change, so treat eject as a debugging tool rather than a contribution workflow.

For agents, skills are installed with npx skills add jackwener/opencli, or individually with a --skill flag. The README lists opencli-adapter-author, opencli-autofix, opencli-browser, opencli-browser-sitemap, opencli-sitemap-author and opencli-usage, and gives a when-to-use table. The split matters: opencli-browser is for ad-hoc driving of a page, opencli-adapter-author is for producing a reusable command, and opencli-autofix is for repairing a built-in command that has stopped working. The README even gives the repair prompt as an example: telling the agent that opencli zhihu hot is returning empty and asking it to fix the command.

Where OpenCLI is the wrong tool

The dependency on a logged-in browser is the central constraint, and it rules out whole categories of use. A server or CI job has no interactive Chrome profile with your sessions in it, so the npm install path being labelled for CI does not mean the browser-driven adapters work there. Built-in adapters that read a site you are signed into need that session. If your pipeline runs on a clean container, this is not the tool.

Adapter fragility is the second limitation, and the project's own design admits it. The existence of opencli-autofix, described as the skill for repairing a broken adapter when a built-in command fails, tells you that breakage is expected rather than exceptional. Sites change their markup and their endpoints. An adapter is a contract with a page you do not control. The README does not document a deprecation policy for built-in adapters, nor does it say how quickly a broken one is fixed.

Profile ambiguity is a smaller but sharper failure mode. If you have several Chrome profiles connected and no default set, the README says OpenCLI asks you to choose. That is correct behaviour, but it means an unattended agent run can stall on a prompt. Set a default with opencli profile use before handing the CLI to anything non-interactive. The README also does not document what happens when the daemon fails to auto-start, beyond pointing at opencli doctor for diagnosis.

How this differs from Playwright and Puppeteer

Playwright and Puppeteer are the obvious comparison, and the difference is not features but where the browser comes from. Those libraries launch or connect to a browser you control programmatically, usually a clean one, and you script it in code. OpenCLI attaches to the Chrome you already use, with your logins, through an extension and a daemon. That inverts the authentication problem: you do not script a login flow because you are already logged in.

The trade is portability. A Playwright script is a file you can run anywhere the browser binaries exist, and it is deterministic in a way a live profile is not. OpenCLI commands are shorter to write and closer to the user's real session, but they depend on a running desktop browser, an installed extension and a daemon. If your task is to test your own application in a controlled environment, Playwright is the better fit. If your task is to read a page that only shows its content to a signed-in human, the bridge approach removes an entire class of work. The two are not substitutes so much as answers to different questions.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-23, which is recent enough that the project is being worked on. The release history shows v1.8.7 on 2026-08-23, v1.8.6 on 2026-07-03 and ext-v1.0.21 on 2026-06-28. Note the two version lines: the CLI and the extension are released separately, so upgrading one does not automatically upgrade the other. The package.json in the repository lists version 1.8.8, one ahead of the latest release noted above, which suggests the manifest tracks unreleased work.

The upgrade cost sits mostly in the extension. The manual install path asks you to download an opencli-extension-v{version}.zip and load it unpacked, which means re-downloading and reloading when the extension version moves. The Chrome Web Store route avoids that, at the cost of depending on store review timing. The desktop app bundle is the third path and handles updates through its own UI.

Licensing is Apache-2.0. That is a permissive licence with an explicit patent grant, and it permits commercial use and modification provided the licence and notices are preserved. Nothing here is legal advice, and the PRIVACY.md file in the repository is worth reading on its own if you plan to point an agent at pages containing personal data, since the whole model depends on your logged-in session.

Editorial conclusion

Adopt OpenCLI if you want deterministic commands over sites you are already logged into and you accept that a Chrome profile and a running daemon are part of the setup. Skip it if you need headless CI scraping, since the whole design leans on a logged-in browser. Verify first with opencli doctor, then check that opencli profile list sees the profile you intend to use before you install any skill into an agent.

Frequently asked questions

Official sources

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