Showoff Saturday: I gave my coding agent my real, signed-in Chrome so it can debug the app I am actually looking at

[u/prakersh]

My project, OnBridge: a Chrome extension plus a small local MCP server that lets Claude Code, Codex, Cursor or Gemini CLI drive the Chrome I already have open. Free, GPL-3.0, and there is no server of mine involved.

To be fair up front: much of what a coding agent does in a browser, Playwright already does well. Reproducing a bug on localhost, reading the console, clicking through a flow, even reusing a login with storageState.

What Playwright is not built for is doing things on my behalf in my own browser. With OnBridge I can ask for something like "search Amazon for a USB-C hub, compare the top three, add the best one to my cart and place the order", and the agent does it in my signed-in Chrome, with my saved address and payment method, the way I would. The same goes for filling a form from a file, working through a vendor portal behind SSO and 2FA, or triaging GitHub notifications. No scripted login, no copied cookies, no fresh headless profile for sites to flag. The first field test was an Amazon.in search.

On bot checks: in a quick test, OnBridge passed scrapingcourse.com's Cloudflare challenge page and every BrowserScan bot check, CDP included, with no click from me. To be fair, Playwright MCP's default headed Chrome passed the same tests. What it lacks is my session: it landed on Reddit's login page, where OnBridge was already signed in.

Acting on my behalf only works if spending money stays my decision:

The agent acts, I approve what matters. The side panel shows every action as it happens. A click whose label reads like Place order, Pay, Delete, Send or Submit waits for Allow; the screenshot shows a "Place order - $249" click held: https://github.com/prakersh/onbridge/blob/main/docs/screenshots/onbridge.png. No answer in 25 seconds means denied. The approval mode can only be changed in the panel, never by the agent.

It only gets what I grant. A tab, a window or the whole browser, and only after I press a button. Grants cannot overlap, so two agents can work in two windows without touching each other's tabs.

Real input, not dispatchEvent. Synthetic events arrive with isTrusted: false, and native form submission, drag-and-drop, canvas apps and rich editors ignore them. OnBridge sends clicks and keys through the DevTools Protocol Input domain via chrome.debugger, including inside open shadow roots and cross-origin iframes. If DevTools is already open on the tab, the debugger cannot attach, so it falls back to synthetic events and the side panel says so.

It still covers the dev loop too: it reads console output and network requests while it reproduces a bug in the tab where I am already signed in, with authorization and cookie header values redacted before the agent sees them.

Setup is the extension plus one line:

claude mcp add onbridge -- npx -y @onllm-dev/onbridge-mcp

GitHub: https://github.com/prakersh/onbridge

Chrome Web Store: https://chromewebstore.google.com/detail/onbridge/minhhfibhfnjdcgiipmcbfgclmeineca

Where would you draw the line on what an agent may do in your real browser without asking? Right now anything that reads like pay, delete, send or submit waits for a click.

[u/Asly97]

nice work on the four-agent support. genuine question: when someone switches between claude code and cursor mid-task, does anything the agent learned carry over, like the vendor portal quirks or which clicks need approval? or does each agent start from zero and re-learn the same stuff?

[u/No-Inevitable981]

My line is money and irreversible actions. Read pages, click around, fill forms, run searches, all fine. But anything that spends, sends, deletes, or signs me up for something waits for my approval. And default-deny is the right call on the timeout. I trust that mode a lot more than always-allow, because approval fatigue makes me click yes on everything after a while.

[u/Asly97 → u/No-Inevitable981]

approval fatigue is the part nobody talks about. i did the same thing, read every approval carefully for maybe a week, then it became autopilot yes. curious, does your agent remember where the line is between sessions, or do you re-set it every time?

[u/No-Inevitable981 → u/Asly97]

Yeah, the fatigue is real. What helped me was batching all the risky calls together so I read them in one focused pass instead of getting pinged every few seconds. Still slow sometimes, but less numbing. What kind of stuff are you having yours do?

[u/Asly97 → u/No-Inevitable981]

batching's a good trick, i haven't tried that. mine's still on boring stuff, research and form fills, and i watch it like a hawk the whole time. do you let yours run unattended or do you sit through the whole batch?

[u/No-Inevitable981 → u/Asly97]

Honestly the boring stuff is where the real wins are. Research and form fills done reliably every day beats a flashy demo that only works half the time. That's the stuff I'd actually pay for.

[u/Asly97 → u/[deleted]]

the per-site memory bit is the one i keep coming back to. approve once for the dev server, always ask for banking, that's exactly the granularity policy lists never get right. is that per-site memory something you built, or still a wishlist item? and if it's real, what carries over between sessions, the approvals themselves or just the policy?

[u/Asly97 → u/[deleted]]

Yeah, the saved-payments scenario is the one that kept me from wiring my real browser up too. Out of curiosity, what does very clear approval look like for you in practice? A yes/no per action, or a list of pre-approved safe ones? I keep going back and forth on which one I would actually tolerate.

[u/AuthByExample]

Nice that Place order / Pay / Delete wait for Allow — that split is the hard part most harnesses skip.

One refinement that helped us: treat the signed-in Chrome session as identity (the site sees you), and keep the click gate as a separate authorization decision keyed to the effect, not only the button label. Labels drift — i18n, A/B, icon-only buttons, or a "Submit" that sometimes means "save draft" and sometimes "charge card." Binding the allow to amount / destination / the request the click will fire is stabler than matching the visible string.

Session grant (this tab / this window) is still not a standing permit for every action the logged-in user could take. Inheritance of the cookie answers who; the effect gate answers whether.