OpenTabs: calling web APIs through your own logged-in Chrome session
Browser automation clicks buttons. OpenTabs calls APIs.
At a glance
- What is it?
- OpenTabs is an MIT-licensed TypeScript project that pairs a Chrome extension with a local MCP server so an AI agent can call site APIs inside an authenticated browser session. The appeal is skipping API keys and OAuth setup; the cost is that the whole thing depends on a browser you keep open and a plugin you have to trust.
- Who is it for?
- OpenTabs fits engineers who already automate through Claude Code or another MCP client and want Slack, Discord, GitHub or Jira actions without minting tokens for each service. It does not fit headless CI, unattended servers, or any workflow where nobody is sitting in front of Chrome, because the extension bridge and the authenticated session are the transport.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem OpenTabs targets: agents that need a session, not a scraper
Most browser automation for AI agents drives the page: find an element, click it, read the DOM. That works until a site renders differently, adds a modal, or moves a button. OpenTabs takes the opposite position, stated in its own README: "Browser automation clicks buttons. OpenTabs calls APIs." The project's claim is that the AI should issue the same HTTP requests the web app itself issues, carrying the cookies and tokens already present in your Chrome profile. The audience is narrow and specific. It is for people who already have an MCP-capable client (the README names Claude Code and OpenCode among the tools it was built with) and who want that client to act on services they are already signed into. The README's framing is blunt: "No API keys. No OAuth setup. If you're logged in, your AI can use it." That is the entire value proposition, and it also defines the boundary of the tool.
Architecture: a Chrome extension bridging to a local MCP server
The README describes three steps. You install the CLI and load the Chrome extension. The extension then "bridges your browser to a local server." Finally the AI calls web APIs through your authenticated session. So the data path runs agent to local MCP server to extension to the target site, with the extension supplying the browser context that makes the request look like it came from the logged-in tab. The repository topics confirm the shape of the stack: chrome-extension, mcp-server, plugins, typescript, ai-agents. Two capabilities sit on top of that transport. The first is the plugin catalogue, described as 100+ plugins and roughly 2,000 tools covering Slack, Discord, GitHub, Jira, Notion, Figma, AWS and Stripe. The second is a set of built-in browser tools (screenshots, clicking, typing, network capture) that the README says work on any tab without a plugin. That second set matters: it means OpenTabs is not purely an API-call tool, and the browser-automation fallback is still there when no plugin exists for a site.
Installing it: two commands, one manual extension load
The Quick Start is short. Node.js 22+ and Chrome are required. Then:
npm install -g @opentabs-dev/cli opentabs start
After that you load the extension manually. The README gives the path and the exact procedure: load from ~/.opentabs/extension in chrome://extensions/, with Developer mode enabled and Load unpacked selected. Plugins are installed with a second command:
opentabs plugin install <plugin-name>
The README claims a plugin becomes usable immediately with no restart, illustrated by a demo installing a Reddit plugin and creating a post. For contributors, the repository offers a different path: clone, npm install, npm run build, then npm run dev for a tsc watch process alongside the MCP server and extension. A single npm run check runs build, type-check, lint, knip and test. The README also states you can skip MCP entirely and use CLI mode instead, linking to the MCP server reference for details. The extension load is the one step that cannot be scripted away, and it is the step most likely to be forgotten when someone reinstalls Chrome or moves to a new machine.
The permission model is the part worth reading closely
OpenTabs ships with a security section that is more specific than most projects of this type. Everything starts off, and no tool executes until you explicitly enable it. There are three permission levels: Off, Ask (a confirmation dialog), and Auto, configurable per-plugin or per-tool. Permissions reset when a plugin updates, which is a deliberate choice: a version bump forces you to re-grant rather than inheriting trust granted to older code. The README also describes a code review step in which your AI reviews the plugin source before you enable it. Treat that as a prompt, not a guarantee. An AI reading plugin source is a second opinion, not an audit, and the review is only as good as the model doing it. The genuinely load-bearing controls are the per-tool permission levels and the reset-on-update behaviour, because those are enforced by the system rather than by judgement. The README states the software runs locally with no cloud component and a full audit log, and that anonymous telemetry is opt-out.
Where the design breaks: sessions, headless machines and plugin trust
The dependency on an open, authenticated Chrome session is not an implementation detail. It is the architecture, and it rules out whole categories of use. There is no headless path described in the README, so a CI runner, a cron job on a server, or any unattended environment has nothing to bridge to. Session expiry is a related failure mode: when a site logs you out, the plugin's calls stop working, and the failure surfaces as a request that returns an auth error rather than a clean signal that you need to re-authenticate in the browser. Plugin quality is the other exposure. The catalogue is large, and the README's own plugin-development guide encourages publishing to npm so anyone can install a plugin. A plugin is code that runs with access to your authenticated sessions, which is a meaningfully different risk profile from a library that only touches its own process. The Off-by-default setting and the update-triggered permission reset are the right mitigations, but they only help if you leave plugins on Ask. Leaving a plugin on Auto after installing it from npm is the failure mode to avoid.
How this differs from Playwright and from direct API clients
Playwright drives a browser through its own automation protocol, launching or attaching to a browser instance you control. It is deterministic, scriptable and runs headless in CI. What it does not give you is your existing logged-in profile by default, and its unit of work is a page interaction rather than a typed API call. OpenTabs inverts both: the unit of work is a plugin tool call, and the browser is your browser, already signed in. Against a direct API client (a Slack SDK with a bot token, for example), the difference is credential management. A bot token is scoped, revocable and independent of any human session. An OpenTabs plugin call acts as you, with your permissions and your visibility, which is simpler to set up and harder to reason about when something goes wrong. The README also notes that OpenTabs is not affiliated with or endorsed by any third-party service and points to a full disclaimer, which is worth reading before pointing it at anything with a terms-of-service clause about automated access.
Maintenance, licence and what to verify before adopting
The project is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and licence text are preserved. That is a permissive baseline, and it is not legal advice: the disclaimer file and each third-party service's own terms are separate questions from the code licence. Maintenance has two layers. The CLI and MCP server are one moving part; the plugin catalogue is another, and plugins that target third-party web APIs will drift whenever those services change their endpoints. The permission reset on plugin update is a sensible response to that drift, but it also means plugin updates interrupt configured workflows until you re-grant. There are no releases retrieved for this repository, so version cadence cannot be judged from the material here. Before adopting, verify three things: that the extension at ~/.opentabs/extension loads and reconnects after a Chrome restart, that a plugin you care about is set to Ask rather than Auto, and that the plugin source you are asked to review is the source actually installed. Those are checks you run, not claims the README makes for you.
Editorial conclusion
OpenTabs fits engineers who already automate through Claude Code or another MCP client and want Slack, Discord, GitHub or Jira actions without minting tokens for each service. It does not fit headless CI, unattended servers, or any workflow where nobody is sitting in front of Chrome, because the extension bridge and the authenticated session are the transport. Before enabling anything, read the plugin source the AI is asked to review, set the plugin to Ask rather than Auto, and confirm the extension loaded from ~/.opentabs/extension survives a Chrome restart.
Community notes