CLI tool
Hacker-Valley-Media/Interceptor avatar
Hacker-Valley-Media/Interceptor

Interceptor: an agent CLI that drives your logged-in browser instead of a headless one

Agent-driven Chrome extension for full browser control via CLI

412 stars54 forksTypeScriptNOASSERTION

At a glance

What is it?
Interceptor is a macOS CLI plus WebExtension that lets an agent act inside your real Chrome, Brave or Safari session, with an optional Swift daemon for native apps. The interesting decision is architectural: no DevTools protocol, no throwaway browser profile, and a licence you have to read yourself.
Who is it for?
Adopt Interceptor if your agent has to work inside an authenticated session you already own, on macOS 11 or later, and you can accept a CLI-driven loop rather than a library you import. Do not adopt it if you need a headless Linux runner, a stable public API surface, or a licence you can classify from the repository metadata alone.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
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 is the authenticated session, not the clicking

Most browser automation starts a browser. Playwright, Puppeteer and the CDP-first tools in the README's own comparison table launch a fresh instance and talk to it over the DevTools protocol. That works until the site you care about needs a login you already have, or notices the automation, or your agent has to repeat a workflow it learned yesterday. Interceptor takes the opposite premise, stated in the README as using 'the browser and apps the human is already using.' It ships as a WebExtension inside your Chrome, Brave or Safari session, so cookies, logins and open tabs stay where they are. The audience is narrow and specific: engineers on macOS who want an agent to operate web apps and, optionally, native desktop apps, and who are willing to drive it through a CLI rather than a language SDK. The README is explicit that no MCP server and no API keys are required.

Two surfaces, one CLI, and a Swift bridge you may never install

Interceptor Browser is the extension surface. According to the README it reads passive fetch, XHR, SSE, WebSocket, sendBeacon and BroadcastChannel traffic using only standard Web APIs, without the DevTools protocol. It dispatches synthetic clicks and keys, and it patches `URL.createObjectURL` to capture client-side PNG, PDF and SVG exports while suppressing the save dialog. It also claims to drive canvas-rendered editors such as Docs, Slides and Sheets by dispatching events directly on the canvas rather than falling back to OS-level keyboard input. Interceptor macOS is a separate Swift bridge daemon, installed only by the Full package, that exposes structured accessibility trees and OS-level trusted input for apps like Finder, Slack and Notes. Interceptor iOS is a third surface: an on-device XCUITest runner dials into the daemon over the network, and `interceptor ios status` reports the address as `dialBack` or `dialBackVia`. That last detail is worth pausing on. It implies the phone has to reach your machine, which is why the README prefers a VPN address and notes that LAN works only after the runner is allowed under Settings, Privacy & Security, Local Network.

The agent loop is a command and a read, not a callback

There is no library to import. The README describes the loop plainly: the agent calls `interceptor` CLI commands, reads the output, and decides what to do next. That is a deliberate constraint. It means the integration surface is stdout and exit codes, which any agent framework can consume, and it means the project does not have to maintain bindings for each language. The cost is that structured results have to survive a text boundary. The v0.24.10 release notes mention 'honest eval, click and act results' and 'durable verified task state', which reads like an acknowledgement that earlier versions reported success too readily. If your agent needs typed return values rather than parsed text, that is friction you will feel immediately. The README also points to an ARCHITECTURE.md file that was not included in the material supplied here, so the internal data flow between extension and CLI cannot be confirmed from what is available.

Installation is a signed package, and the choice of package matters

Three installers ship per release. `Interceptor-Browser-<version>.pkg` is the recommended default: CLI, daemon and extension, with no macOS TCC prompts at all, targeting macOS 11 and later. `Interceptor-Full-<version>.pkg` adds `interceptor-bridge.app` and a LaunchAgent, and triggers Screen Recording, Accessibility and per-app Apple Events consents, targeting macOS 14 and later. `Interceptor-Safari-<version>.pkg` is an add-on containing app plus Safari Web Extension, and the README states it requires one of the core packages for the CLI and daemon. Upgrades are handled by `interceptor update`, which the README says waits briefly for Sparkle and reports either the selected version, a no-update reason, or the real error. If the feed is slow it returns `checking`, and `interceptor update status` then shows the latest outcome, selected version, lifecycle phase, feed and schedule. Moving from Browser to Full is a single command: `interceptor upgrade --full`. The README's advice is to start with Browser unless you already know you need native macOS commands, which is sound given the consent prompts the Full package introduces.

Where the design choices cost you something

The extension approach depends on a browser you have open and logged in. That is the selling point and the failure mode at once. A CI runner with no session, no profile and no display is the wrong environment; the README's comparison table lists 'avoids a separate automated browser by default' as an advantage, but it also means there is no clean ephemeral profile to throw away between runs. The Full package asks for Screen Recording, Accessibility and Apple Events permissions, which is a meaningful grant for a tool that then hands control to an agent. The README's own warning says to treat it 'like an agent, not a toy script runner.' The synthetic-input mechanism deserves scrutiny too: the README describes a `userActivation` override plus a `__interceptor_trust` event marker so that handlers gated on `isTrusted` will fire. That is a deliberate bypass of a browser security signal, and any site or security review that checks for it will see it. Finally, the licence field reads NOASSERTION, which means the repository metadata does not resolve to a recognised SPDX identifier. Nothing here tells you what the terms actually are.

Playwright is the honest alternative, and the difference is the profile

The README compares itself to Playwright, Puppeteer and CDP-first tooling directly. The real difference is not features, it is where the browser comes from. Playwright launches and manages its own browser binaries, which gives you reproducible versions, headless operation on Linux, and a documented API you can pin in a lockfile. Interceptor attaches to the browser you are already using, which gives you the session but takes away the reproducibility. The README's table claims Playwright requires the DevTools protocol for passive network reading and often needs `--os` or OS-level CGEvent for canvas editors, while Interceptor does both with standard Web APIs and dispatched events. Those are specific, checkable claims, and they are the ones to verify against your own target sites before committing. Record-and-replay is the other gap the README highlights: Interceptor records real human sessions and exports replay plans, and the table says competing tools do not build this in. If you never need an authenticated profile, Playwright is the simpler dependency.

Release cadence, upgrade cost, and the licence question

The release history shows a fast cadence. v0.24.10, v0.24.11 and v0.24.13 landed within four days of each other in September 2026, and the notes cover narrow items: new tabs staying with Interceptor groups, filling saved logins from any installed Chromium browser, iPhone RemoteXPC keepalives and dial-back addressing. Patch-level churn at that rate means two things for adopters. First, `interceptor update` is not optional housekeeping; it is how you stay on a version where the reported behaviour matches the code. Second, an agent that parses CLI output is coupled to output that can change between patches, so pinning a version and reading the release notes before upgrading is the cheaper path. On licensing, the repository carries NOASSERTION as its licence identifier. That is a metadata state, not a licence grant, and it is not something to interpret from a README. If you need to redistribute Interceptor, bundle it into a product, or run it under a corporate compliance policy, resolve the actual terms from the repository's licence file before you install anything.

Editorial conclusion

Adopt Interceptor if your agent has to work inside an authenticated session you already own, on macOS 11 or later, and you can accept a CLI-driven loop rather than a library you import. Do not adopt it if you need a headless Linux runner, a stable public API surface, or a licence you can classify from the repository metadata alone. Before installing, verify three things: which of the three installers matches your machine (Browser, Full, or the Safari add-on), whether the NOASSERTION licence identifier resolves to terms your organisation accepts, and whether the commands you actually need are documented in `interceptor ios help` or the ARCHITECTURE.md file rather than only in the README.

Official sources

  1. Hacker-Valley-Media/Interceptor on GitHub
  2. Issues
  3. README
  4. Releases
Community notes

Community notes