The OpenTabs image installs every published plugin from a registry search

The container binds to every interface while the page says it runs locally

One line in the security list is that it runs locally, with no cloud. The container image is where that gets interesting. The build file sets the host environment variable to all interfaces, sets the port to 9515, exposes it, and the usage comment in the same file is a run command that publishes that port without a loopback restriction, so the default container invocation puts a server on the host's network rather than on the loopback interface. What that server is for is the point: it is the thing that lets a model act as the person running it, making API calls through their authenticated session. The npm route is genuinely local, a server on your machine that a browser extension bridges to. The container route is the same server with a wider bind, and the page's statement about running locally describes the first of those two.

A build that installs the extension and rebuilds two published packages

The build script is a chain of nine steps, and the last four are not compilation. Installation starts with two commands:

npm install -g @opentabs-dev/cli
opentabs start

After that, a build does more than compile. After the type build and the browser-tools catalogue generation and the extension bundle and side panel builds, it generates icons, computes an extension hash, installs the extension into the local profile, runs a rebuild against the CLI and the plugin-tools packages, and makes the executable. So a contributor running a build writes into their own extension directory and forces a rebuild of two packages that already exist on the public registry. There is a forced variant of the same chain, which differs only in asking the compiler to ignore previous output. The hash step is almost certainly the mechanism behind the security claim that permissions reset when a plugin updates, and the install step is the one to know about before running a build on a machine with a live profile.

The image's tool surface is whatever a registry search returned

The runtime stage of the container image, after installing production dependencies and putting the CLI on the path, reaches out to the npm registry. It queries the public search endpoint for the plugin keyword with a large page size, pipes the JSON response through a short inline script that keeps package names containing the plugin marker while dropping the SDK and tooling packages, and installs the surviving list globally. The stated reason is that the tools should show up in introspection. The consequence is that an image built today has a different tool surface from one built last month, at versions nobody pinned, and the admission test is a substring check against a package name. For a project whose argument is that a model acting as you should be constrained, that is a constraint applied at the wrong layer, since the image is where the tools are enumerated.

The reviewing model and the acting model are the same model

Following that with a permission change is the part the page treats as ordinary, and a plugin install is one command:

opentabs plugin install <plugin-name>

Plugins take effect immediately with no restart. So the security list is mostly good and one entry is circular. Everything starts off and nothing executes until you enable it. There are three permission levels, off, ask with a confirmation dialog, and auto, set per plugin or per tool. Permissions reset when a plugin updates, which is the strongest property in the list because it converts a stale approval into a new one. And then there is code review: the page says your AI reviews the plugin source before you enable it. So the review step is performed by the same kind of system that is about to act, reading a package it did not choose and that it will then be asked to justify. The plugin source is a file you can read yourself, and nothing on the page says the review is advisory rather than gating, which is the distinction that decides how much weight it carries.

Three descriptions, and the root package is not the published one

The project describes itself three times. The repository summary is a contrast: browser automation clicks buttons, this calls APIs. The readme makes the same point in prose, that your AI calls real web APIs through your browser session with no screenshots and no DOM scraping. The manifest says something shorter and vaguer, that it turns tabs into tools. The manifest also declares the root package private while registering a workspace of directories under platform, which means nothing called opentabs is published from the root; the artefacts are the workspace packages, and the readme's install command names a scoped CLI. The npm entry a user sees is therefore a different package from the repository they cloned, which is ordinary for a monorepo and worth knowing before you go looking for the manifest you thought you were reading.

Screenshot and click tools ship alongside the no-screenshot claim

The feature list includes built-in browser tools, described as screenshots, clicking, typing and network capture, working on any tab with no plugin needed. The first line of the readme is a promise of no screenshots and no DOM scraping. Both can be true, because the plugin path is meant to replace the browser path for services that have an API, and the built-in tools are the fallback for the ones that do not. But the fallback is not hidden: it is in the same list as the plugins, and the catalogue of those tools is itself a build artefact, generated by a script that runs as part of every build. So the capability the project argues against is also the capability it ships, and the argument only holds if a plugin exists for the site in front of you.

Point the model at a site and it writes the plugin

The plugin story has two halves. One is ordinary: scaffold a plugin in one command, publish it to npm, and anyone can install it, with an install that works immediately and needs no restart. The other is that you can point your AI at any website and it discovers the APIs and builds the plugin for you. That is the interesting capability, and it is also the one that feeds the review question in a loop, because a machine-generated plugin is exactly the kind of source you would want an independent reader to look at before enabling. The catalogue of more than a hundred plugins and around two thousand tools, covering services from Slack and Discord through GitHub, Jira, Notion, Figma, AWS and Stripe, gives no indication of which of those are hand-written and which came out of the other path.

Four agent configurations, five TypeScript configs, no root source directory

The root of the repository is configuration. There are directories for two assistant tools, a separate file for each of two more conventions, a directory named after one of the tools credited at the bottom of the readme, and a configuration file for an automated review bot. The TypeScript side is four config files, a root one, a base one, one collecting the others and one for scripts. Linting and formatting run through a single tool with a config at the root, dead code is checked by a dedicated script, git hooks are managed by a lefthook configuration, and there are two test layers with separate configs, one for the unit runner and one for browser automation. There is no source directory at the top level: the code lives in the platform workspace, which is also what the manifest publishes, and alongside it sit directories for plugins, end-to-end tests, documentation and marketing.

Editorial conclusion

The design decision with real teeth here is that permissions reset when a plugin updates, which turns a stale approval into a fresh one. The two decisions to look at are that the same model reviews the plugin it is about to run, and that the container path binds to every interface while the local path does not. If you use the npm route on your own machine with permissions left on Ask, the risk profile is modest; if you publish a Docker image, the tool surface is whatever a registry search returned on build day.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. opentabs-dev/opentabs on GitHub
4. Project website
5. README