Opera is turning its experimental Neon browser into something you can literally script from the command line, and it’s a bigger deal than it sounds at first glance. With the new “opera-browser-cli” tool, Neon stops being just a browser and becomes a controllable surface for local AI agents and terminal workflows.

At its core, opera-browser-cli is a command line interface that sits on your machine and talks directly to Opera’s devtools stack, letting you drive Opera Neon from a terminal window or from tools like Claude Code, Codex, Cursor and other CLI-based AI agents. Once it’s set up, you can do things like open sites, take snapshots, or even ask the browser to “make” something for you with simple commands instead of point-and-click. Opera’s own examples include commands such as opera-browser-cli open https://linkedin.com, opera-browser-cli snapshot, or opera-browser-cli make "create a web app showing my contact’s latest posts", all executed against a normal, logged-in Neon profile. Under the hood, the CLI is essentially a wrapper around Opera’s “opera-devtools-mcp” project, exposing a broader tool surface and Neon’s built-in AI agents to whatever is calling it.

Opera has been steadily moving in this direction for a while. In March, the company rolled out MCP Connector for Opera Neon, which lets external AI clients like Claude, ChatGPT, Lovable and others connect to your live browser session over the Model Context Protocol, access your current tabs and content, and then navigate or click around on your behalf. MCP Connector essentially turned Neon into an “AI execution layer” reachable over the network, with authentication handled by an MCP server URL and a proxy layer keeping connections reasonably stable even when the browser isn’t open. The new CLI tackles a different angle: instead of a cloud AI reaching into your browser over MCP, you get a local, low-latency bridge that your own tools and local AI agents can command from the terminal.

That local focus matters. Because opera-browser-cli runs on your machine and talks to the browser over a local port (by default 9224), it doesn’t need the extra OAuth dance or a remote proxy that MCP Connector relies on. Opera points out that this architecture cuts down on latency and token overhead, which is a real concern when you’re chaining many tool calls from an AI agent and every round-trip eats into your token budget. It also gets access to more of the devtools surface, including agentic commands that aren’t exposed through MCP Connector, making the CLI more capable for fine-grained automation and in-browser actions.

In practice, that means a local AI like Claude Code can use Neon almost like a robotic pair of hands with eyes: it can open a site, scroll, click buttons, fill forms, run checks on a live web app, and then report back — all through the CLI without you ever touching the mouse. Opera’s own demo shows Claude Code using the CLI to QA a live web app, starting from installation and setup, then driving Neon step by step via command-line commands issued from inside the AI coding environment. For developers, that’s a neat bridge between code and browser: your test suite or AI assistant can spin up Neon, hit your staging site, run through a scenario, grab screenshots and log results, all as scripted steps.

From a user’s perspective, the setup is surprisingly straightforward compared to most “automation stack” stories. Opera Neon has to be installed and you need to be logged into the browser, but beyond that it’s essentially one line in a terminal: npm install -g opera-browser-cli, followed by opera-browser-cli setup to walk through the initial configuration. You do need a relatively modern Node.js environment (version 20 or above) and npm, and Opera calls out that on Windows you should be running PowerShell 7 or later before pasting in the install command. Once the script finishes, Claude Code integration is basically wired up by default, and any tool with access to a shell, from coding agents to custom scripts, can start calling the CLI.

Opera is deliberately positioning opera-browser-cli as complementary to MCP Connector, not a replacement. MCP Connector is still the answer if you want a cloud-hosted AI client running somewhere else to attach to your Neon session over the internet and act inside your browser. The CLI, on the other hand, is for when the AI (or script) is running on the same machine as Neon and you care about speed, tool breadth and local control rather than remote access. Opera even notes that MCP-style use cases are largely covered by the CLI except those where a hosted client actually needs to reach Neon over the network; because the CLI binds to a local port and does not open itself to the public internet, it’s not reachable from cloud-hosted MCP clients.

There are some subtle behavior differences that matter if you’re doing serious automation. opera-browser-cli sets automation flags by default, which lets visited pages know they’re being driven by automation, something websites may use to adapt behavior or detect bots. Those flags can be disabled via environment variables if you want traffic that looks more like a regular human session, and Opera clarifies that some Neon agent paths like “Do” and “Research” run without that flag anyway because they go through internal agent routes rather than the Chrome DevTools Protocol. MCP Connector, by contrast, doesn’t set those automation flags, which can be a differentiator in environments that are sensitive to automated access.

What really stands out here is the direction Opera is taking Neon overall. Between MCP Connector and opera-browser-cli, Neon begins to look less like a traditional consumer browser and more like an “agentic browser” — a runtime built for AI systems to inhabit. Instead of assuming a human is always at the wheel, the product is being rethought around the idea that AI assistants will open tabs, read content, click through flows and build things on your behalf, while you supervise from a higher level. Neon isn’t just exposing APIs for extensions anymore; it’s opening the full live-browser experience — cookies, sessions, logged-in accounts — to controlled use by external tools and agents.

That’s a meaningful shift from the broader browser market, where automation has mostly lived in developer-only tools like Selenium, Playwright, or Puppeteer. Those frameworks work brilliantly for scripted tests, but they’re not always ergonomic for AI agents and non-developers. With a CLI that’s purpose-built for AI workflows and wired directly into Neon’s native agents, Opera is betting that a browser that plays nicely with AIs will be more appealing than one that just bolts on a chatbot sidebar. It also potentially opens up new use cases: non-technical teams could lean on AI to routinely pull data from internal dashboards, generate reports, or run sanity checks on web apps, all through a higher-level natural-language layer that talks to the CLI under the hood.

For now, the project lives in the open on GitHub, with repositories for both opera-browser-cli itself and the underlying opera-devtools-mcp integration. That means developers can inspect how the bridge works, open issues, and even extend the tool with new capabilities as it matures. Trend-tracking sites are already picking up on the repos, reflecting early interest from the automation and AI tooling community, and forum threads show people experimenting with combinations of Neon, Claude Code, and the CLI to stress-test real-world workflows.

If you zoom out, Opera’s latest move turns a somewhat niche experimental browser into a testbed for what “AI-native” browsing could look like in the next few years. Instead of you manually copying links and context into your AI tools, Neon is being wired so that your tools can just live inside the browser and act directly. opera-browser-cli is the command-line key that unlocks that behavior for local agents, giving them a first-class way to open, inspect, and manipulate the web the same way a human user would — only faster, more repeatable and fully scriptable.