Interceptor v1.0.24

Interceptor v1.0.24

What is Interceptor?

Interceptor is an AI-agent control surface for the browser, desktop apps, and iPhone you already use. It works with your real signed-in sessions, so your cookies, accounts, tabs, and app state stay intact while an agent reads the interface and takes action.

Three surfaces, one CLI:

• Browser: drive your live Chrome, Brave, or Safari session from inside the page. Read the DOM and accessibility tree, click, type, navigate, observe network traffic without CDP, automate rich editors and canvas apps, capture client-side exports, and record workflows for replay.
• macOS: drive native apps through the Accessibility tree, trusted input, ScreenCaptureKit, and Apple's Vision, Speech, and Natural Language frameworks. Routine work stays in the background unless you explicitly ask the agent to show or focus an app.
• iOS: drive any installed app on an owned, unlocked, Developer Mode iPhone. The on-device XCUITest runner provides element trees, taps, text entry, scrolling, screenshots, and app control, while separate device-service and Instruments lanes expose logs, files, processes, telemetry, location, and WebKit inspection.

Interceptor ships as one interceptor CLI, a local daemon, a browser extension, an optional macOS Swift bridge, and an iPhone runner. It requires no API keys and does not launch a separate automation browser. It can also expose every surface to MCP clients such as Claude Code, Codex, Gemini CLI, Cursor, and Claude Desktop with one command:

interceptor mcp install

Most browser automation starts a clean browser and talks to it through DevTools. Interceptor starts from the opposite premise: let the agent work in the same authenticated browser and apps as the human, see the real interface state, and carry a workflow across web, desktop, and phone.

---

What's new in v1.0.24

Version 1.0.24 follows 1.0.19 directly and includes everything merged as 1.0.21. The headline: an agent can now click, type, and send keys to a window that is in the background, in native apps and in the browser, while you keep working in the app in front.

Native input reaches a background window

• interceptor macos click, drag, scroll, type, and keys with --app or --pid now reach a window that is in the background. The frontmost app and the cursor stay where they are. These verbs used to report success while a background app dropped the events.
• New --window <id> on those verbs names the exact window. interceptor macos windows lists the ids. A value that is not a number is an error instead of a silent fallback to the frontmost window.
• A click or drag aimed at a minimized window, a hidden app, a point outside the app's windows, or a ref that is not in the named window is refused, and the result says nothing was delivered.
• Two gestures addressed to different windows at the same time run one after the other, so one lane's keystrokes do not land in the other lane's window.

Trusted browser input without taking focus

• --trusted clicks, typing, and keys now work on a browser window that is not focused, on a Full install. The tab has to be the one showing in its window. The result says the input was delivered in the background.
• A --trusted click on an element inside an iframe now lands on that element. It used to click a different element in the top page. When the iframe cannot be located, nothing is clicked.
• Still refused, with a hint: a tab that is not the active tab of its window, a minimized window, pointer moves, and a Browser-only install. A failed background delivery returns that refusal and never falls back to the foreground path.

Your own background window

• interceptor window new moves your tab group into the new background window, so the new tab stays there and keeps painting. Its showing tab renders, plays media, and takes trusted clicks while the window is behind your work, and tab switch inside it does not change what you are looking at. On the shared default group the result carries a groupWarning.

Replay plans and skills stay in the background

• Replay plans from macos monitor export --plan no longer ask apps to come forward. An app change is written as interceptor macos open, and typed text is addressed to its app. An app that is not running is launched in the background, and macOS can still bring it forward while it starts.
• The bundled agent skills now put background work first: use a background verb, then tab keepalive, then your own window with window new, and take focus only when nothing else works.

Pages that check for the browser's own fetch

• Pages that check whether fetch is still the browser's own function now pass that check with Interceptor installed. Upwork's signed-in pages no longer stall on a Loading screen in a background tab, and net log keeps capturing their fetch requests. Thanks to @MerryEcho for tracking down the cause in #275.

Response overrides and network capture

• interceptor override can now change the response: --status, --body, and --content-type answer a matching fetch or XHR without sending it, and --delay holds the real request. key=value still rewrites query parameters, and status=500 now prints a note pointing to --status 500.
• net log, net headers, and sse log include requests made inside iframes. Failed and aborted requests are listed with status 0 and the error.
• --since on net log, net page-comm log, and network log takes a duration such as 30s or 5m, or an epoch-millisecond timestamp. A bare number like 30 is refused.
• sse tail waits for a stream to start, prints it through its final chunk, and exits 1 if none starts before --timeout.

Electron apps

• macos cdp app attach refuses, without signaling the app, when another process holds the inspector port, and says how to relaunch on a free port. On attached Electron apps tabs, read, text, find, and click now work; eval, screenshot, and net say to use macos cdp connect.
• macos cdp launch now stops only the app's own process before relaunching it. It used to match the app's path anywhere in a command line, which could end an unrelated shell or script.
• contexts --verbose and diagnose show the Safari extension's version.

Source builds on Intel Macs

• The native macOS bridge now builds from source on Intel Macs, and CI builds it on an Intel runner so it stays that way. The macOS packages are still built for Apple silicon. On Intel, the interceptor macos vm commands that need Apple silicon say so, and a paused-state snapshot or restore is refused before a snapshot file is written or the VM's disk is replaced. Thanks to @kootik for the fix in #290.

Limits worth knowing

• Keyboard delivery to a background window is less reliable while you are actively switching apps. A result that says the input was delivered means the events were posted to that window, so read the target before sending the same text again. A click never went to a wrong window in testing.
• Two background windows that show the same page title in the same frame cannot be told apart and are refused as ambiguous.

Everything ships together

The CLI, daemon, Chromium MV3 extension, Electron MV2 extension, native macOS bridge, Safari extension, iPhone runner, Windows x64 and ARM64 installers, and Linux x64 and ARM64 archives all report 1.0.24.

---

Install

Choose the package for the computer and control surface you need:

Download	Platform	What it installs	When to pick it
Interceptor-Browser-1.0.24.pkg	macOS 11+	CLI, daemon, and browser extension	You want browser automation without macOS Accessibility or Screen Recording prompts.
Interceptor-Full-1.0.24.pkg	macOS 15+	Browser package plus the native macOS bridge and LaunchAgent	You also want to drive Finder, Mail, Slack, system dialogs, and other desktop apps.
Interceptor-Safari-1.0.24.pkg	macOS 14+	Safari containing app and Web Extension	Add Safari support after installing either core macOS package.
Interceptor-Browser-1.0.24-windows-x64.exe or windows-arm64.exe	Windows 11 24H2+	Signed per-user browser-only install	You want the browser surface on Windows.
Interceptor-Browser-1.0.24-linux-x64.tar.gz or linux-arm64.tar.gz	Linux	Browser-only archive	You want the browser surface on x64 or ARM64 Linux.

Start with Browser on macOS unless you need native app control. The Safari package is an add-on. Windows and Linux provide the browser surface. The macOS packages are built for Apple silicon; on an Intel Mac, build from source.

After installation:

interceptor status
interceptor open "https://example.com"
interceptor mcp install

For native macOS control with the Full package:

interceptor macos trust --walkthrough
interceptor macos tree

For an owned, unlocked, Developer Mode iPhone connected to a Mac with Xcode:

interceptor ios setup
interceptor ios status

Already installed? Run interceptor update.

The Chrome Web Store version may arrive after Google's review. The unpacked extension included with the macOS package matches the installed 1.0.24 CLI immediately.

Release verification

• 2,012 Bun tests passed, with 9 platform skips and 0 failures across 220 files. TypeScript type checking, the capability audit, the Intel bridge build, and GitHub CI passed.
• The macOS Browser, Full, and Safari packages passed Developer ID signing, Apple notarization, stapling, and Gatekeeper assessment. A byte scan of the staged payloads found no private checkout paths.
• The Full and Safari packages were installed with the macOS installer. The installed CLI and daemon are byte-identical to the release build, the bridge and the Safari app report 1.0.24, and one Safari extension is registered.
• On the installed build, with another app frontmost throughout: window new opened a page in a background window; a --trusted click, ten typed characters (ten of ten key events trusted), and a click on a button inside an iframe were delivered in the background; macos type addressed with --window typed into that window; a --window value that was not a number was refused; the page saw fetch as native code; override --status 503 --body answered a fetch without sending it and net log --since 30s listed it as mocked; a bare --since 30 was refused; tab keepalive turned on and off.
• Both Linux archives matched their SHA-256 checksums and contain the expected browser-only payload with x64 and ARM64 binaries. A Linux container install test was not run because no local container service was available.
• Windows x64 and ARM64 installers were built, signed, and attested by the release workflow, which also installed, repaired, and uninstalled the x64 package. All seven release payloads were downloaded again from this release and match the published SHA256SUMS file, and both installers pass attestation verification.

Implemented in #275, #297, and #290, with the Windows runner pin from #298.