Justy: You're listening to Exploring Next, episode 322. Today we're looking at OpenTabs—an open-source tool that lets AI agents call real web APIs through your browser session instead of guessing from screenshots. Cody thinks there's a trust problem lurking here.
Cody: I don't think the trust problem is lurking—I think it's the entire premise. You're downloading a Chrome extension that sits between your browser and a local server, and then you're telling it to run plugins that call APIs on your behalf. Even if the security model is solid on paper, the plugin ecosystem is the attack surface. A hundred plugins from a community means a hundred opportunities for someone to slip in a malicious one or just a badly written one that leaks your sess
Justy: Fair, but Cody, let me push back. Right now, if I want an AI agent to interact with my Slack or GitHub, I either screenshot everything and hope the model guesses right, or I go through OAuth hell for every single service. This approach says: if you're already logged in, your AI can just use it. That's actually less friction than the status quo.
Cody: Less friction, yeah, but friction exists for a reason. The OAuth hell you're talking about—that's a security boundary. It forces you to think about what you're giving away. Here, you install a plugin and immediately it can do things on your behalf. [sighs] I get the appeal, I really do. But the code-review-before-enable flow assumes you're actually going to read the source of every plugin, and most people won't.
Justy: Most people won't, you're right. But the people who would use this—developers, ops teams, power users—they kind of have to care about that stuff anyway. They're already managing API keys and permissions in a hundred other places. OpenTabs at least gives them an audit log and version-aware permission resets. That's more visibility than they have with, say, a Zapier integration.
Cody: Okay, that's a fair comparison. Zapier is a black box. Here, at least the extension is local, the plugins are versioned, and you can see what ran. I can live with that. But here's what I actually think is the bottleneck: is the plugin ecosystem going to exist? The README says 100+ plugins, but I don't know how many of those are actively maintained or if they're just listed as possible.
Justy: That's the real question, isn't it? The tool itself is solid—the architecture makes sense, the UX is clean. But it only matters if people actually build plugins for the services they use. If you need Slack, Discord, GitHub, and Notion, great. If you need something more niche, you're writing your own or waiting for someone else to.
Cody: Exactly. And writing your own isn't trivial. You need to understand how to scaffold a plugin, test it locally, publish to npm, manage versions. For a developer, that's fine. For a product manager or a non-technical user, that's a wall.
Justy: But the README actually hints at something interesting—they mention the ability to point the AI at a website and let it reverse-engineer the APIs and build the plugin for you. I don't know if that's fully baked, but if it is, that changes the calculus. You don't need to write the plugin yourself; you just need to know it's possible.
Cody: [chuckles] That's a big 'if it is.' API reverse-engineering is hard, especially if the site uses obfuscation or requires specific headers. But yeah, if they pulled that off, it's clever. It would mean the barrier to adding a new service is just pointing the system at it and letting it figure it out.
Justy: Which brings us to who actually uses this. I think the answer is pretty narrow: developers building AI workflows, maybe some ops teams automating cross-tool processes. Not general consumers. Not even most product teams.
Cody: Agreed. This is a power-user tool. The value prop is 'I have a complex workflow that spans five different tools, and I want my AI to handle it without me writing a backend.' That's real. That's a real problem. But you have to actively want that problem solved badly enough to set up a local server and load a Chrome extension.
Justy: So where do we land? Is this overhyped or is it actually solving something?
Cody: I think it's solving something real for a specific audience. The security model is thoughtful. The architecture is clean. My concern isn't the tool—it's whether the ecosystem builds out and whether trust scales. If you're the kind of person who already maintains a dozen npm packages and runs custom scripts, this is useful today. If you're waiting for OpenTabs to have plugins for every service you use, you're going to wait a while.
Justy: Okay, so Build Next. Cody, if someone wants to test this claim, what should they actually do?
Cody: Two things. First, start with the built-in browser tools—screenshots, clicking, typing. No plugins needed. Use those to automate something simple, like filling out a form or extracting data from a page. Get comfortable with the model before you layer in plugin complexity. Second, if you have a service you use daily that doesn't have a plugin yet, scaffold one. The command is right there: `opentabs plugin scaffold my-service`. You'll learn what's actually possible and what's m
Justy: And for someone without the dev background?
Cody: Pick a workflow you do by hand across three or four tools—maybe create a GitHub issue, add it to Notion, and post to Slack. Use OpenTabs with the existing plugins to automate that end-to-end. You'll feel whether it saves you time or if it's just moving the friction around.
Justy: That's a solid test. Exploring Next, episode 322. If you're already living in your terminal and you're building AI workflows, OpenTabs is worth a serious look. Everyone else: wait for the plugin library to grow. Thanks for listening.