InvisiblePlaywrightTools toolkit (interest check)

[feder-cr]

hey, before fleshing out the full tool surface i wanted to check if there'd be interest in an InvisiblePlaywrightTools toolkit parallel to the existing FirecrawlTools, Crawl4aiTools, ScrapegraphTools, BrowserbaseTools. selected by the user when constructing the agent, no change to anything else.

three open issues seem to be asking for exactly this: #7943 (add Playwright browser automation tool), #7104 (anybrowse MCP for Cloudflare-bypass), #6997 (CloudflareBrowserRenderingTools). all useful for cases where Firecrawl / Crawl4ai / Scrapegraph hit Cloudflare, Akamai, Datadome, or hCaptcha walls.

the backend would wrap feder-cr/invisible_playwright, which drives a patched Firefox 150 binary (feder-cr/invisible_firefox, MPL-2.0, same license as Firefox upstream). fingerprint patches at the C++ source code level so there are no JS shims to detect. optional dependency, only imported when the toolkit is constructed. issues against the backend route to feder-cr/invisible_playwright.

also opened a draft PR #8129 with a stub toolkit file at libs/agno/agno/tools/invisible_playwright.py modeled after the FirecrawlTools shape, so the proposal has somewhere concrete to land.

[rehan243]

Yeah, I’d say there’s definitely interest in something like this, especially for dealing with those edge cases where tools like Firecrawl or Crawl4ai start tripping over aggressive bot protection. Sounds like you’re targeting exactly the right pain points with Cloudflare, Akamai, Datadome, etc., and tbh, patched browsers like invisible_firefox are solid for this niche. We’ve had to build similar “stealth” setups with patched Chromium in the past, so I can see the value in exposing feder-cr/invisible_playwright as a clean toolkit here.

One thing I’d be curious about though: since this depends on a heavily patched Firefox (and thus specific to feder-cr’s implementation), have you run into any challenges keeping the patches in sync with upstream Firefox updates? We’ve occasionally seen patched browsers fall out of date fast when new anti-bot measures roll out, and maintaining those patches can get gnarly. Do you see this as a long-term viable approach, or is it more of an interim solution until a more native way to bypass these walls emerges?

Also, re: the PR you mentioned, is the idea that users would just configure InvisiblePlaywrightTools exactly like the other toolkits with a similar API? Or do you see this needing extra config hooks (e.g., supplying custom patched binaries)? Would love to hear how you’re thinking about that abstraction layer since it’ll probably affect adoption.

[feder-cr]

@rehan243 thanks, three good questions.

upstream sync: fork is on FF 150, came from FF 140 with a ~1-2 day port per major bump. patches are ~30 C++ files plus a yaml of prefs, not a whole-codebase fork. rebases stay tractable.

long-term: i think yes. the patch points (canvas readback, webgl getParameter, font metrics, audio context, navigator.plugins/mimeTypes, system colors) are stable APIs mozilla has no incentive to instrument. chrome is heading toward integrity signals (UA-CH, attestation) that hit patched chromium harder over time; firefox doesn't go that way. the moving target is server-side scoring, true for any stealth approach.

api: same shape as the other toolkits. wrapper auto-downloads a pinned firefox binary from GH releases on first use, no manual provisioning. there's an executable_path knob to point at a self-built binary if someone wants, but optional. pip install + run, same as Firecrawl/Crawl4ai today.

[feder-cr]

quick status to close the loop here: the toolkit is complete and the PR (#8129) is ready for review.

@rehan243 your three questions are answered above (upstream-sync cadence, long-term viability, api/config shape). on the build side it is green locally: 33/33 pytest, ruff check + ruff format clean, mypy clean on the touched file, head b2dd7df. the only thing pending is the first-time-contributor CI approval on the PR.

happy to adjust the shape if you'd want changes before merge.