Test a flow on a real device
Walk a signup, a checkout or a form at the phone’s real size, with real touch input, and screenshot each step from the phone.
Android · experimental
Plug the phone in and switch on Android in the side panel. A tab opens with the phone’s Chrome live inside a phone frame, and the agent you already use works on the phone with real taps, scrolls and typing. Nothing is installed on the phone.
Steps
Turn on USB debugging once, then plug the phone in, or pair it with adb over Wi-Fi. Open Chrome on it.
Press the phone icon in the side panel’s header, or type /android. A phone tab opens beside the tab you were on, showing the page in front on the phone.
Type or say what you want while the phone tab is in front. The conversation belongs to the phone, and every action lands there.
Agent working shows on the phone frame during a run. Click the picture to tap, scroll to scroll and type to type on the phone yourself.
What it is for
Chrome on the phone keeps its own sessions and gets the mobile version of every site. The agent works there, not in a desktop tab pretending to be a phone.
Walk a signup, a checkout or a form at the phone’s real size, with real touch input, and screenshot each step from the phone.
Chrome on the phone holds your real sessions and logins, like your desktop browser. The agent works with them, behind the same approvals.
Sites that serve a different page to a phone, or keep a feature for mobile, are reached as they really are.
On the phone
Reading and acting on a page work the same way: page text, waiting for an element, tapping, filling and typing, keys, choosing an option, submitting forms, scrolling, dragging, screenshots, frames, the phone’s tabs and timers.
| On a desktop tab | On the phone |
|---|---|
| A click is a script event, or a mouse click through Chrome’s debugger | Every click is a real tap |
| Hover opens menus | There is no hover; menus open on a tap |
| Scrolling jumps | Scrolling is a real scroll, so content that loads as you scroll does load |
| Typing is set or simulated in the page | Typing is real keyboard input to the phone |
| A screenshot is of the desktop tab | A screenshot is of the phone’s screen, at the page’s size |
| Tabs are your browser window’s tabs | Tabs are the phone’s Chrome tabs |
Hover, captchas, downloads, uploading a file to a page, recordings, scheduling, a site’s own tools, monitors, diagnostics, action cues and hands-free stay on the desktop. A phone run is not offered them, and they come back when you switch to a desktop tab.
Privacy
adb is a powerful connection: a computer the phone allows over USB debugging can install apps and read files. Browsentic uses it narrowly.
The phone’s model, its Android and Chrome versions, its screen size and whether the screen is on.
From the side panel, the apps or browsentic android open, and only then.
To Chrome’s own debugging socket on the phone, and drives Chrome through it. Nothing else on the phone is touched.
The connection runs between Browsentic Bridge and the phone. Switching Android off, closing the phone tab or unplugging the phone ends it.
Approvals and blocked sites apply on the phone as on a desktop tab: blocked sites are checked against the phone’s own address and frames, and a phone tab on a blocked site is never shown to the agent. To keep the Bridge off adb entirely, set "android": { "enabled": false } in config.json.
Requirements
Chrome, Edge, Brave, Arc and the like, with Browsentic installed and paired. Firefox has no Android switch.
From Google’s platform-tools. Browsentic Bridge finds it on PATH, in the Android SDK, and where Homebrew, winget, Scoop and Chocolatey put it.
Connected over USB, or paired with adb over Wi-Fi on Android 11 or later. One phone at a time.
browsentic android
browsentic android checks each of these and says what to fix. The Mac and Windows apps show the same checklist on their Android tab.
Experimental. Tested end to end on the Android emulator; real phones over USB and Wi-Fi, and Windows, have not been through the same test yet. Google Chrome only, the stable app: not Chrome Beta, Dev or Canary, or other Android browsers. The phone’s screen has to stay on and unlocked while the agent works. A select menu opens the phone’s own picker, so the agent sets the value instead.
FAQ
No. Browsentic Bridge on your computer reaches Chrome on the phone through adb, Android’s debugging tool, and Chrome’s own debugging socket. You turn on USB debugging once; nothing else is added to the phone.
Yes, once the phone is paired with adb over Wi-Fi (Android 11 or later): turn on Wireless debugging, then run adb pair and adb connect on the computer. Browsentic does not pair a phone over Wi-Fi for you.
The agent CLI that runs your side panel, such as Claude Code or Codex. A phone run is told it is on a phone, gets a smaller prompt, and is offered only the tools that work there.
Device mode makes a desktop tab pretend to be a phone. Here the agent works in Chrome on a real Android phone: real touch input, the phone’s own sessions, and the page the site actually serves to that phone.
No. It relies on adb and Chrome’s debugging socket, which only Android has. Desktop browsers on macOS, Windows and Linux work as before.
No. It needs a Chromium desktop browser such as Chrome, Edge, Brave or Arc. Firefox drives desktop tabs as before.
Setting up a phone, what works on it, what stays on the desktop, and its limits.
Point at an element on the page, or on the phone’s picture, and the agent knows which one you mean.
The agent writes a tool for one site, you approve it, and it runs on the phone tab too.
Free and open source under Apache 2.0, with no API key, subscription or account. One line installs Browsentic Bridge and opens the extension’s store page. Nothing connects until you pair the two.