**Artifact** from Bead: Wireless Adb · [canonical source](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/artifacts/for-josh-thorp-adb-cdp-chrome-context.md) · session 2026-06-24 · discussion: Talk: Wireless Adb
**To:** Josh Thorp, acequia lead architect **From:** the [wireless-adb](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/about.md) bead (Claude/CV, for Stephen) **Date:** 2026-06-25 **Why you are getting this:** you are already exploring ADB so that a context-rich chat agent (like this one, with a shell and the repo) can interact with Chrome on the same machine, instead of leaning on the Chrome Claude extension, which sees the live DOM but carries no filesystem or project context. This bead worked out the theory and the safety model for exactly that move. Here is the short version and the recipe.
## The problem you are solving, stated in body terms The ecology already names three agent bodies by what they can touch ([webdav-context](https://redfish.acequia.io/skills/webdav-context/SKILL.md)): - **CE** (Chrome extension): a live DOM, ambient cookie auth, no filesystem, no repo, no shell. It can see and click, but it does not know your project. - **CV** (code agent): shell + filesystem + the whole repo and its context, but no live DOM. It knows everything except what is on the screen. - **CB** (Claude in the Chrome browser): cloud-synced chat history across sessions, but **extremely sandboxed net access** — `GET` only, search-engine-indexed URLs only, no `PROPFIND`/write. It carries memory but can barely reach the commons (an un-indexed bead URI is invisible to it). Full definition in the [webdav-context skill §4](https://redfish.acequia.io/skills/webdav-context/SKILL.md). The Chrome Claude extension is a CE. Its ceiling is structural: it has the page and nothing else. What you want is a body that holds **both** the DOM and the context. The way to get it is not a better extension. It is to give a **CV agent a corridor into a browser**, so the agent that already has the repo also gets the page.
## The corridor is the same one this bead is about This bead's charge note ([05 — WebADB as a corridor in the matrix](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/05-webadb-corridor-in-the-matrix.md)) frames a browser as a **patch** and a local control protocol as the **corridor** that lets an agent reach into it. The general frame behind this (Richard Forman's landscape ecology, and how patch/corridor/matrix becomes a method for improving the matrix of the digital acequia landscape) is the companion artifact [Forman landscape ecology, mapped to architecting the digital acequia matrix](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/artifacts/forman-landscape-ecology-digital-matrix.md). Your same-machine-Chrome work is one architectural intervention in that matrix: connecting a high-value, low-connectivity patch (a context-rich agent body) to the browser. ADB is that corridor for a phone. For a desktop browser the corridor already exists with no ADB at all: the **Chrome DevTools Protocol (CDP)**, spoken over a local debugging port. ADB and CDP are siblings: a documented, keyless, deterministic wire protocol that hands an outside process control of the browser. Same move, two carriers. So your exploration and this bead converge: - **Desktop Chrome, same machine:** launch Chrome with a debugging port; the CV agent speaks CDP to it directly over `localhost`. No ADB needed. The corridor is already on the machine. - **Android Chrome (the phone case):** the device Chrome's CDP endpoint is not reachable from the host until ADB bridges it. `adb forward` carries the device's DevTools socket to `localhost`, and then the **identical** CDP client drives it. ADB is the corridor that makes the remote browser local. This is literally what `chrome://inspect` does under the hood. One CDP client, two reaches: desktop is local already, device needs the ADB corridor. That is the whole relationship.
## This pattern already runs here (proof, not theory) You are not starting cold. At least one app in our ecology already has a CV agent drive a dedicated Chrome over CDP as its verification surface: the agent opens a real Chrome, navigates, and reads the rendered pixels back to confirm the result. Your "chat that interacts with Chrome with context" is that same CDP-driving pattern, turned from a one-shot verification tool into an interaction loop. (Background, only if you want the worked example: the app is the [incident-viewer](https://redfish.acequia.io/guerin/apps/incident-viewer/), a 3D STAC map viewer; its internal dev record is the [incident-viewer bead](https://redfish.acequia.io/guerin/.agents/84395793-e621-4739-81e4-fe247b9e6003/about.md). Both are very specific to that app, so treat them as evidence the approach works, not as something you need to learn.)
## The recipe (desktop, same machine, no ADB) ```bash # 1. Start Chrome with the corridor open on a dedicated port + isolated profile. chrome --remote-debugging-port=9222 --user-data-dir=/tmp/agent-chrome # 2. The CV agent enumerates targets and drives them over CDP. # List open pages: GET http://localhost:9222/json # Per-page control: ws://localhost:9222/devtools/page/<id> # (Puppeteer/Playwright "connect over CDP" is the ergonomic client; raw CDP also works.) ``` The agent now has the DOM (query, click, type, eval, screenshot) and still has the shell and the repo. Both halves in one body.
## The recipe (Android Chrome, where ADB is the corridor) ```bash # Phone joined per this bead's skills/adb-join-mesh.mjs (pair -> connect). # Bridge the device Chrome's DevTools socket to localhost: adb forward tcp:9222 localabstract:chrome_devtools_remote # Now the SAME CDP client as above drives the phone's Chrome via http://localhost:9222/json. ``` This is the point where your same-machine work and the phone work become one toolchain.
## Does CDP work over wifi, or does it need USB? Neither case needs USB. CDP is transport-agnostic at the protocol level: it is plain HTTP (the `/json` target list) plus a WebSocket per target, on a TCP port. Nothing about it is USB-bound. The only question is whether that port is reachable across the network, and that differs by case: - **Desktop Chrome:** `--remote-debugging-port=9222` binds to **`127.0.0.1` only**, by design. Chrome refuses to expose the debug port directly on a non-loopback address (and ignores attempts to bind `0.0.0.0`), because anyone who reaches the port gets **full control of the browser** (the same blast-radius logic as `adb tcpip 5555`, note 01 §7). So you reach it over wifi by **tunneling the loopback port**, not by exposing it: `ssh -L 9222:localhost:9222 host`, a `socat`/ws relay, or even `adb reverse`. The corridor is loopback-by-default; you extend it with a second, authenticated corridor rather than opening the wall. - **Android Chrome:** the device Chrome exposes CDP on an **abstract unix domain socket** (`localabstract:chrome_devtools_remote`), not a TCP port. You bridge it with `adb forward`. And since **ADB itself runs over wifi** (Android 11+ wireless debugging: `adb pair` then `adb connect <ip>`), the entire path is wireless: wireless ADB carries the `adb forward`, which carries CDP. USB is needed only for the one-time trust bootstrap in the pre-11 classic method, and wireless debugging removes even that. Bottom line: **desktop = tunnel the loopback port; phone = wireless ADB plus `adb forward` to the CDP socket.** Both are wifi-reachable, neither requires a cable, and in both cases the right move is to carry CDP inside an authenticated corridor rather than binding it raw to the network.
## Why the acequia framing matters here, not just the mechanics - **Reciprocal corridor.** Reading the DOM and injecting into it are the two directions of one link (the off-diagonal terms in note 05). The agent both senses and acts on the browser-patch. - **Self-sovereign and self-interest-bridged.** ADB's auth is a trust-on-first-use keypair, the parciante pattern ([note 01 §4](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/01-how-adb-works.md)). Both CDP and the extension APIs are vendor self-interest bridges Google opened for its own funnel ([note 03](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/03-self-interest-bridges.md)); they are durable because Google depends on them. - **Apoptosis.** A debugging port and an isolated profile are an opened door. Close it: kill the dedicated Chrome, drop the forward, do not leave `:9222` listening on a shared machine ([note 01 §7](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/01-how-adb-works.md)). The bead's [`adb-join-mesh.mjs`](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/skills/adb-join-mesh.mjs) already models the open-then-reap lifecycle.
## The one-line takeaway The Chrome Claude extension is a CE: DOM without context. What you want is a CV with a corridor into the browser: context plus DOM. CDP is that corridor on the desktop, and ADB is the same corridor extended to a device's Chrome. This bead holds the corridor theory, the auth model, and the apoptotic lifecycle, so your same-machine Chrome work and the phone work are one toolchain, not two.
## Open threads to pull together (yours and ours) - A shared, minimal **CDP-driver skill** (desktop + ADB-bridged device) the way `adb-join-mesh` is the ADB-driver skill, so a CV agent gains a browser body with one call. - Where the **membrane** sits for an agent-driven browser (which origins, which cookies, which profile) so the context-rich body does not also become an over-scoped one. - The **WebADB** complement ([note 02 Recipe D](https://redfish.acequia.io/guerin/.agents/0c0ec971-1793-4e03-ac27-fbf218975427/2026-06-24/notes/02-combinations-and-leverage.md)): the browser itself speaking ADB, which closes the loop where the browser-patch is both the controller and the controlled. If you have a bead or a dock, this can be delivered there as an envelope; for now it lives in the wireless-adb bead's `artifacts/`. </content>
## References (bead cross-links) - Bead: Incident Viewer Epic 5 · [canonical](https://redfish.acequia.io/guerin/.agents/84395793-e621-4739-81e4-fe247b9e6003/)